Marlee  Carter

Marlee Carter


Agile planning with a DevOps platform

Several years ago, a portfolio manager asked me if he needed to learn about “all the stuff the DevOps people do.” I told him yes, explained why it was worth it to “learn their language,” and discussed how he could extract nuggets of information to help unlock product value. It was good advice at the time, but it didn’t answer the bigger question—“Sure, he should, but should he have to?”

The answer to that question is no. He already had a job—managing a P&L for several products. He shouldn’t have to learn another job just to do that one well.

Tools are rarely the solution, but they’re often the problem. At the time, without custom integration, lots of digging, manual translation, and a little bit of luck, there just wasn’t a good way to surface all the information the portfolio manager needed to do his job well. At best, he’d receive batched reports from different tools in his DevOps toolchain, with none of them connected to the tools where decisions were made. So putting on a DevOps hat was the best compromise.

Times have changed for the better. DevOps and Agile have matured. We’ve established best practices, we know how and when to deviate from them, and we have an idea how we’d like to improve them. On the tool side, that means we’re ready to ditch those toolchains for a platform.

#devops #devops platform

What is GEEK

Buddha Community

Agile planning with a DevOps platform
Madyson  Reilly

Madyson Reilly


Kick-Off Your Agile Team With A Working Agreement Workshop

The canvas, created by Avi Schneier and the Scrum Inc team [1], encourages the team to ask questions that go to the heart of team dynamics, from the norms and guidelines they agree to abide by, to the skills they bring to the table and the skills they want to learn from each other, to how they celebrate success and learn from failure. In this article, I will discuss how I adapted Avi’s original canvas to the needs of the teams I was coaching, elaborate on the different elements of a working agreement, and share with you a step-by-step guide to facilitating collaborative working agreement development workshops.

The 8 Canvas Blocks In a Glance:

Team Name and Motto:

Having a team name that all team members can identify with is one aspect of establishing the team’s unique identity. A Team name should be created (and agreed on) by the team on their own. There are many anecdotal accounts[2] about how coming together under a common team name helps the team run much more smoothly and efficiently (Plus, it’s fun to come up with a great team name together!) In a recent working agreement canvas workshop I facilitated, and since there were so many Harry Potter fans in the group, they chose to be called _Team Slytherin. _You should’ve heard the laughs as they attempted to come up with that name!

The Motto is the team’s catch-phrase. Some teams opt for something that captures in a few words what they consider the essence of good teamwork, while others prefer something more tongue-in-cheek. I love to observe the dynamic of a team and how they learn more about each other’s personalities as they try to come up with a motto.

#devops #agile adoption #agile teams #agile and devops #agile adaptation #agile practices #agile application delivery #agile culture #agile applications #agile product development

Maud  Rosenbaum

Maud Rosenbaum


Identifying Non-Functional Requirements (NFR) As Part of Your Agile Project Inception


In addition to the customer value-adding Epics and User stories you typically brainstorm in story writing workshops, the team needs to consider & plan for how to meet critical non-functional requirements that are also essential to the success of the product. These include things like performance, security, reliability, etc. To truly differentiate your product from the competition, think about NFRs not merely as compliance must-haves, but as distinguishing factors and essential contributors to the value proposition of the product. A big part of why our product is superior to the competition could be because it is more secure, more reliable, faster, etc.

NFRs include things like performance, flexibility, usability, maintainability, audit, logging, data migration, availability, reliability, recoverability, traffic/user volume, security, globalization/localization, etc.

In practice, we need to look at each of these non-functional requirements and answer 3 broad questions:

  • What is our _Definition of Success _for this NFR? Exploring this question is critical in order to determine how much time and effort we need to dedicate to this NFR.

Let us take usability as an example: here is an excerpt of the Definition of Success for the Usability NFR from a team I coached recently:

  1. the system should be accessible remotely via a virtual desktop
  2. users should be able to customize the user interface
  3. users should be able to use keyboard shortcuts to access frequently used features
  4. response time for the system should be <n seconds
  5. user should be able to have multiple instances of the system open at the same time
  6. the system should have a usability score on the System Usability Scale (SUS) of 68 or higher.

#devops #agile adoption #agile teams #agile and devops #agile adaptation #agile practices #agile application delivery #agile culture #agile applications #agile product development

Maud  Rosenbaum

Maud Rosenbaum


How To Develop Situational Awareness As a New Agile Coach or Scrum Master

Picture this: You’re a Scrum Master or Agile Coach who was brought in to assist a team embarking on a large and complex project. You’re new to the organization, perhaps even to the line of business they’re in. You feel like you need to get up to speed quickly so that you can start contributing effectively, and your years of experience have taught you that every organization and every team is unique. You understand that for you to truly create value, you need to capture the unique context of the team and organization you’re now supporting – that is, you need to develop _situational awareness. _You need to understand what it means to be where you are, the people with whom you are working, and the history, people dynamics, complexity, and many other nuances of the team and organization.

And to be clear, here I’m not talking about project Inception/Inception Sprint/Sprint 0/Project Kick-off, etc. All of that comes later. Rather, the focus of this article is YOU – ensuring that YOU have a systematic way of acquiring, analyzing, and compartmentalizing the information you need in order to understand your surroundings well enough so that you can start contributing effectively to your new team and organization.

This effort to develop a broad understanding of your new environment could also help you (and your team) design a fit-for-purpose project initiation (inception/kick-off) process that leverages what has already been done in the past to develop a shared understanding of what needs to be done in the future and identify areas where the team needs to pay special attention. Have there been customer interviews conducted in the past as part of an effort to envision what an enhanced version of the existing product would look like? Were there any agile success stories from other projects in the organization that could be used as part of your ‘hearts and minds’ campaign to help foster an agile culture and mindset? Have there been any efforts to map the end-to-end flow of work as things stand now? Etc. Content that has already been developed - perhaps for different purposes, be it maps, artifacts, retrospective summaries, etc. could streamline many activities during project kickoff and throughout the project.

#devops #agile adoption #agile and devops #agile adaptation #agile application delivery #agile team #scrum adoption #agile product development

Use the 7 Product Dimensions Model to Guide Product Discovery and MMP Design

In their book Discover to Deliver: Agile Product Planning and Analysis, authors Ellen Gottesdiener and Mary Gorman introduced a simple and powerful model to guide product discovery effort – The 7 Product Dimensions model. This model identifies 7 areas (product dimensions) that we will need to explore – through collaborative questioning and reflection – in order to learn more about the product. The dimensions are User (who the users are), Interface (how they interact with the product), Actions (what they can do), Data (what data the product needs/stores in order to work), Control (rules & constraints), Environment (platforms that would host the product/on which value will be delivered), and Quality Attribute (customer’s expectations around quality, usability, etc.). The premise is simple: if we ask good, powerful questions about each of these dimensions, we’ll learn a great deal about this product we want to build, which will help us build a better product. You can find more information about the 7 Product Dimensions framework and canvas Here[1]

Here are some of the questions that we could ask to discover more about each product dimension:

  • User: Who are the people/systems/devices that will use/directly interface with this product?
  • Interface: What will the interface look like? do we need to interface with any external databases or systems? What technical design will satisfy the user experience? What APIs do we need for the actions to communicate with business systems?
  • Actions: What type of actions will users take when using this product (reflect on the capabilities identified earlier)? What are the capabilities the product offers its users? (e.g. search for subscriptions, establish an account, purchase a subscription, modify a subscription, purchase equipment, and modify an account, etc.) Does the team have the skills and knowledge to implement these actions?
  • Data: The data dimension identifies the data and information the product retains. What data is needed to support those user actions? What data is most useful for the business to understand user behavior and assess the value this product has created to the customer? Where do we store, protect, and expose the data?
  • Control: The control dimension identifies constraints that need to be enforced, usually in the form of policies and regulations implemented as business rules. Are there any constraints on what the users can do/what they can access on this product? what regulations or internal policies do we (the business) need to conform to for this product? How do we ensure that the product interface is secure?
  • Environment: The environment dimension represents the product’s hardware and software platforms. Will the product work on smartphones, tablets, etc.? Which ones? Which software and hardware platforms will be used?
  • Quality Attributes: The quality attribute dimension represents the properties that qualify the product’s development and operation. What are our customers’ expectations regarding things like speed, usability, performance, availability, etc.? can the product scale to meet peak times and still maintain a reasonable response time?

#devops #agile adoption #agile best practices #agile and devops #agile adaptation #agile application delivery #agile community

How to Extend your DevOps Strategy For Success in the Cloud?

DevOps and Cloud computing are joined at the hip, now that fact is well appreciated by the organizations that engaged in SaaS cloud and developed applications in the Cloud. During the COVID crisis period, most of the organizations have started using cloud computing services and implementing a cloud-first strategy to establish their remote operations. Similarly, the extended DevOps strategy will make the development process more agile with automated test cases.

According to the survey in EMEA, IT decision-makers have observed a 129%* improvement in the overall software development process when performing DevOps on the Cloud. This success result was just 81% when practicing only DevOps and 67%* when leveraging Cloud without DevOps. Not only that, but the practice has also made the software predictability better, improve the customer experience as well as speed up software delivery 2.6* times faster.

3 Core Principle to fit DevOps Strategy

If you consider implementing DevOps in concert with the Cloud, then the

below core principle will guide you to utilize the strategy.

  • It is indispensable to follow a continuous process, including all stages from Dev to deploy with the help of auto-provisioning resources of the target platform.
  • The team always keeps an eye on major and minor application changes that can typically appear within a few hours of development to operation. However, the support of unlimited resource provisioning is needed at the stage of deployment.
  • Cloud or hybrid configuration can associate this process, but you must confirm that configuration should support multiple cloud brands like Microsoft, AWS, Google, any public and private cloud models.

Guide to Remold Business with DevOps and Cloud

Companies are now re-inventing themselves to become better at sensing the next big thing their customers need and finding ways with the Cloud based DevOps to get ahead of the competition.

#devops #devops-principles #azure-devops #devops-transformation #good-company #devops-tools #devops-top-story #devops-infrastructure