Tag Archives: agile

DORA and Agile – a bake off of delivery pipeline measurement techniques

Posted on by
Reply

Today’s post is inspired by Matt Shuster, who asked about my opinion on DORA vs Agile pipelines. So, let’s see the basics first; measuring the performance of an agile delivery pipeline requires a combination of metrics that focus on both efficiency and effectiveness. Here are a few metrics that are commonly used for this purpose:

  • Lead time: The time from when a feature is requested to when it is delivered to the customer.
  • Cycle time: The time it takes to complete a specific task or feature from start to finish.
  • Throughput: The number of features delivered per unit of time.
  • Defect density: The number of defects per unit of delivered code.
  • Deployment frequency: The frequency of code releases to production.
  • Time to restore service: The time it takes to restore service after a production failure.
  • User satisfaction: Feedback from users on the quality and functionality of the delivered features.

As with all metrics, these metrics should be regularly monitored and used to continuously improve the delivery pipeline by identifying bottlenecks, optimizing workflows, and reducing waste. Additionally, as Agile is not one-size-fits-all, it’s important to regularly reassess and adjust the metrics used to ensure they accurately reflect the goals and priorities of the organization.

On the other hand, let’s quickly look at DORA. The DORA (Accelerate) framework is a set of four metrics that provide a comprehensive view of the performance of an organization’s software delivery process. The four metrics are:

  • Lead time: The time it takes to go from code committed to code successfully running in production.
  • Deployment frequency: The number of times per day that code is successfully deployed to production.
  • Mean time to recovery: The average time it takes to restore service after an incident.
  • Change failure rate: The percentage of changes that result in a production failure.

These metrics align well with the metrics commonly used to measure the performance of an agile delivery pipeline and can be used in a complementary manner to validate the software architecture. For example, a low lead time and high deployment frequency indicate that the delivery pipeline is efficient and streamlined, while a low change failure rate and mean time to recovery indicate that the architecture is robust and reliable.

I promised a bake off, so, here we are 🙂 The comparison between using metrics to validate a software architecture and using the DORA framework is that both provide different but complementary perspectives on the performance of an organization’s software delivery process.

On one hand, metrics such as lead time, cycle time, throughput, and defect density focus on efficiency and effectiveness of the delivery pipeline. They help to measure the time taken to complete a task, the speed at which features are delivered, and the quality of the delivered code. These metrics provide insight into the processes and workflows used in the delivery pipeline and help identify areas for improvement.

On the other hand, the DORA framework provides a comprehensive view of the performance of an organization’s software delivery process by focusing on four key metrics: lead time, deployment frequency, mean time to recovery, and change failure rate. These metrics help to measure the speed and reliability of the delivery pipeline and provide insight into the resilience and stability of the software architecture.

So, which of them to use? By using both sets of metrics together, organizations can get a complete picture of their delivery pipeline performance and identify areas for improvement in both architecture and processes. This can help ensure that the architecture supports the needs of the organization and the goals of the delivery pipeline, while also providing a way to continually assess and optimize performance over time. For example, metrics such as lead time and cycle time can highlight bottlenecks and inefficiencies in the delivery pipeline, while metrics such as change failure rate and mean time to recovery can highlight weaknesses in the architecture that may be contributing to production failures.

In summary, using metrics to validate a software architecture and using the DORA framework together provides a comprehensive view of the performance of an organization’s software delivery process and helps to identify areas for improvement in both architecture and processes. As probably you figured out, I like case studies and tools, so… here we are 🙂

  • Netflix: Netflix uses a combination of metrics, including lead time and cycle time, to measure the performance of its delivery pipeline. They use this data to continuously optimize their processes and improve their architecture, resulting in a highly efficient and effective delivery pipeline.
  • Amazon: Amazon uses a combination of metrics, including deployment frequency and mean time to recovery, to measure the performance of its delivery pipeline. By regularly monitoring these metrics, Amazon has been able to achieve a high level of reliability and stability in its software architecture, allowing them to quickly and effectively respond to incidents and restore service.
  • Spotify: Spotify uses a combination of metrics, including lead time and throughput, to measure the performance of its delivery pipeline. By using these metrics to continuously optimize their processes and improve their architecture, Spotify has been able to increase the speed and efficiency of its delivery pipeline, allowing them to deliver high-quality features to users faster.
  • Google: Google uses a combination of metrics, including lead time, deployment frequency, and mean time to recovery, to measure the performance of its delivery pipeline. By using these metrics to continuously improve its processes and architecture, Google has been able to achieve a high level of reliability and stability in its delivery pipeline, allowing it to deliver high-quality features and updates to users quickly and efficiently.
  • Microsoft: Microsoft uses a combination of metrics, including lead time and cycle time, to measure the performance of its delivery pipeline. By using these metrics to continuously optimize its processes and improve its architecture, Microsoft has been able to increase the speed and efficiency of its delivery pipeline, allowing it to deliver high-quality features and updates to users faster.
  • Shopify: Shopify uses a combination of metrics, including deployment frequency, mean time to recovery, and change failure rate, to measure the performance of its delivery pipeline. By using these metrics to continuously improve its processes and architecture, Shopify has been able to achieve a high level of reliability and stability in its delivery pipeline, allowing it to deliver high-quality features and updates to users quickly and efficiently.
  • Airbnb: Airbnb uses a combination of metrics, including lead time, deployment frequency, and mean time to recovery, to measure the performance of its delivery pipeline. By using these metrics to continuously improve its processes and architecture, Airbnb has been able to achieve a high level of reliability and stability in its delivery pipeline, allowing it to deliver high-quality features and updates to users quickly and efficiently.

These case studies demonstrate the importance of regularly measuring and analyzing performance metrics to validate a software architecture and improve the delivery pipeline. By using a combination of metrics and regularly reassessing and adjusting their approach, organizations can continuously improve their delivery pipeline and ensure that their architecture supports the needs of the organization and the goals of the delivery pipeline. And speaking of tools – there are various tools and software that can be used to measure the DORA framework measures. Some popular options include:

  • Datadog: Datadog provides real-time monitoring and analytics for cloud-scale infrastructure, applications, and logs. It can be used to track key performance indicators, including lead time, deployment frequency, mean time to recovery, and change failure rate, and generate reports and alerts based on that data.
  • New Relic: New Relic is a performance management platform that provides real-time visibility into application performance. It can be used to track and analyze key performance indicators, such as lead time, deployment frequency, and mean time to recovery, and generate reports and alerts based on that data.
  • Splunk: Splunk is a software platform for searching, analyzing, and visualizing machine-generated big data. It can be used to track and analyze key performance indicators, such as lead time, deployment frequency, and mean time to recovery, and generate reports and alerts based on that data.
  • AppDynamics: AppDynamics is an application performance management solution that provides real-time visibility into the performance of applications and infrastructure. It can be used to track and analyze key performance indicators, such as lead time, deployment frequency, and mean time to recovery, and generate reports and alerts based on that data.
  • Prometheus: Prometheus is an open-source systems monitoring and alerting toolkit. It can be used to track and analyze key performance indicators, such as lead time, deployment frequency, and mean time to recovery, and generate reports and alerts based on that data.
  • InfluxDB: InfluxDB is an open-source time series database. It can be used to track and analyze key performance indicators, such as lead time, deployment frequency, and mean time to recovery, and generate reports and alerts based on that data.
  • Grafana: Grafana is an open-source data visualization and analysis platform. It can be used to track and analyze key performance indicators, such as lead time, deployment frequency, and mean time to recovery, and generate reports and alerts based on that data.
  • Nagios: Nagios is an open-source IT infrastructure monitoring solution. It can be used to track and analyze key performance indicators, such as lead time, deployment frequency, and mean time to recovery, and generate reports and alerts based on that data.
  • JIRA: JIRA is a project and issue tracking software. It can be used to track the lead time and cycle time of the delivery pipeline by monitoring the time it takes for work items to move through the various stages of the development process.

These are just a few examples of software tools that can be used to measure and track DORA framework metrics. The specific tool or combination of tools used will depend on the needs of the organization and the size and complexity of the delivery pipeline. For agile, we have our set of tools too, I picked only some of them (and yes, JIRA is on both lists):

  • Trello: Trello is a visual project management tool that can be used to track and visualize the progress of work items through the different stages of the development process.
  • Asana: Asana is a team collaboration tool that can be used to track and visualize the progress of work items through the different stages of the development process.
  • JIRA: JIRA is a project and issue tracking software that can be used to track and visualize the progress of work items through the different stages of the development process.
  • Clubhouse: Clubhouse is a project management tool specifically designed for agile teams. It can be used to track the progress of work items through the different stages of the development process and visualize the flow of work through the delivery pipeline.
  • Pivotal Tracker: Pivotal Tracker is an agile project management tool that can be used to track and visualize the progress of work items through the different stages of the development process.

I hope this helped answering the DORA vs Agile metrics question, with the answer being:

The value equation for new digital products

Posted on by
Reply

Short update regarding the blog – I added some small new features based on suggestions, these are: share buttons at the bottom of the posts and the ability to subscribe to updates using the sidebar on the main page. Feel free to suggest other features!

As I have been embracing some new projects, and believing in Agile, figured, it would be valuable to be able to effectively calculate the Value of it, as this can be part of a KPI. I have seen some recent discussions on the value equation for new digital products. Some of them were based on the following:

Value = (Benefits – Costs) + (Ease of Use – Complexity) + (Trust – Risk)

Whereas:

  • Benefits: The value the product provides to the user, such as improved efficiency, convenience, or new capabilities.
  • Costs: The cost to the user to obtain and use the product, including monetary costs, time, and effort.
  • Ease of Use: The simplicity and intuitive nature of the product’s interface and functionality.
  • Complexity: The difficulty of using and understanding the product, as well as any necessary training or support.
  • Trust: The level of confidence the user has in the product, including its security, reliability, and reputation.
  • Risk: The potential negative consequences of using the product, such as loss of data, privacy breaches, or security vulnerabilities.

So, how to use this equation? Let’s take an example of a new digital product, a personal finance management app.

  • Benefits: The app helps the user track their expenses, set budgets, and manage their finances more effectively.
  • Costs: The app is free to download and use, but it has in-app purchases and subscriptions.
  • Ease of Use: The app has a user-friendly interface, easy navigation and simple to understand financial reports.
  • Complexity: The app is easy to set up and use, with minimal training required.
  • Trust: The app uses bank-level security measures to protect user data and has positive reviews and reputation in the market.
  • Risk: There is minimal risk associated with using the app, as user data is securely stored and there are no reported security breaches.

Which would translate to:

Value = (Effective financial management – In-app purchases and subscriptions) + (User-friendly interface – Minimal training) + (Secure and reputable – Minimal Risk)

Therefore, the value of this app is high as it provides a lot of benefits such as effective financial management, easy to use, secure and reputable with minimal costs, complexity and risk.

If I were to replace the equation pieces with the usual items (branding, marketing, UX, onboarding and price), this would translate to (continuing the example of the personal finance management app):

  • Branding: The app has a strong brand that is easily recognizable and associated with financial management.
  • Marketing: The app is marketed effectively, with clear messaging that highlights its key features and benefits.
  • User Experience (UX): The app has a user-friendly interface and easy navigation that makes it simple to use.
  • Onboarding: The app has a smooth onboarding process that guides users through setting up and using the app effectively.
  • Price: The app is free to download, with in-app purchases and subscriptions available.

Value = (Strong brand + clear messaging + user-friendly interface + smooth onboarding) – In-app purchases and subscriptions

The value of this app is high as it has a strong brand, clear messaging, user-friendly interface, smooth onboarding and a reasonable pricing model, despite having in-app purchases and subscriptions.

As the first equation seems to be more balanced for me, I tend to use that, but I figured the second equation is what is more generally used. How do you calculate the value of a digital product?

Agile Estimation. Or #NoEstimation. Who knows?

Posted on by
Reply

I already wrote about Agile earlier, but it is a rather important topic for me (I was involved with Agile Alliance very early on). And one of my favorite discussions on the topic is the value of estimation. Whether you are aiming to estimate for the hour, or doing only TShirt estimation, you do know, that estimation is an important part of agile processes because it helps teams plan and manage their work effectively. Estimations are used to determine the amount of time and effort required to complete a task or project, which helps teams prioritize their work and make informed decisions about how to allocate resources. Additionally, estimations help teams set realistic expectations and deadlines for themselves and their stakeholders. In agile methodologies like Scrum and Kanban, estimations are done using techniques such as story points, which are relative measures of complexity rather than absolute measures of time or effort. This allows teams to adapt to changes and uncertainty more easily.

On the other hand, there is a tribe of #NoEstimation practitioners, who say that the value of “no estimation” is that it can eliminate the need for time-consuming and potentially inaccurate estimation efforts, allowing teams to focus on delivering working software and satisfying customer needs. It also promotes a culture of continuous improvement, where teams focus on delivering small, incremental changes and learning from them, rather than trying to predict the future. In “no estimation” approach, the team focuses on delivering smaller chunks of work, called “Minimum viable products” (MVP) which provides the maximum value with minimum effort. This approach is based on the assumption that the customer or stakeholders don’t know exactly what they want, and the team should deliver small increments to gather feedback and iterate on the product. This way, the team can deliver the product with more accuracy and customer satisfaction. This approach is more suitable for companies that have a high degree of uncertainty and volatility in their environment and for projects that have a high degree of innovation.

A quick overview of the pros and cons for this:

ProsCons
Estimation
  • Helps teams plan and manage their work effectively
  • Allows teams to prioritize their work and make informed decisions about resource allocation
  • Helps teams set realistic expectations and deadlines for themselves and their stakeholders
  • Useful for making decisions about project scope and feasibility
  • Can be time-consuming and potentially inaccurate
  • Can lead to unrealistic expectations and deadlines
  • Can be difficult to adapt to changes and uncertainty
  • Can lead to over-engineering or gold-plating
No Estimation
  • Eliminates the need for time-consuming and potentially inaccurate estimation efforts
  • Promotes a culture of continuous improvement and learning
  • Suitable for projects with a high degree of innovation and uncertainty
  • Focuses on delivering smaller chunks of work, called “Minimum viable products” (MVP)
  • May not be suitable for projects with well-defined requirements and constraints
  • May require a significant change in mindset and approach for some teams
  • May result in a lack of long-term planning or goals
  • May lead to delays if the customer or stakeholders need specific features or functionalities

So, where can the ideas of Estimation vs #NoEstimation applied to?

  • Estimation in a software development project: A software development team is tasked with building a new application for a client. The team uses agile methodologies such as Scrum, and they estimate the amount of time and effort required to complete each user story using story points. This allows them to prioritize their work, set realistic deadlines, and manage their resources effectively. However, this process can be time-consuming and may not always be accurate, especially if the requirements change or new information comes to light.
  • No Estimation in a product development project: A product development team is working on a new IoT device. They are using “no estimation” approach. They are focused on delivering small, incremental changes and gathering feedback from customers and stakeholders. They deliver Minimum Viable Product (MVP) that provides the maximum value with minimum effort. They are not trying to predict the future and are continuously improving their product based on customer feedback. This approach allows them to adapt to changes and uncertainty more easily, but it may not be suitable if the project has well-defined requirements and constraints.
  • Estimation in a construction project: A construction company is building a new skyscraper. They use estimation to determine the amount of time and resources required to complete the project. They use Gantt chart and critical path method to plan and manage their work. However, this approach can be difficult to adapt to changes in weather, materials, or other factors, and it may lead to unrealistic expectations and deadlines.
  • No estimation in a research project: A research team is working on a new medical treatment. They use “no estimation” approach and focused on conducting small experiments and gathering data. They are not trying to predict the outcome, instead they are continuously learning and improving their research based on the data they gather. This approach allows them to adapt to new information and uncertainty more easily, but it may not be suitable if the project has specific deliverables and deadlines.

So, no, I haven’t given a straight answer on Estimations, as there isn’t one. Agile is what you make of it, it is NOT one size fits all 🙂

Agile vNext (in 2023+)

Posted on by
1

In 2023, we still speak about how to introduce Agile? That seems to be pretty slow with today’s standards, everyone is already doing agile 😀 So, what the future of Agile looks like?

Future of Agile in a diagram

The future of Agile development methodologies is likely to involve increased focus on collaboration and communication among team members, as well as continued evolution of Agile practices to better support remote and distributed teams. Additionally, it is possible that we will see a greater emphasis on integrating Agile principles with other methodologies, such as Design Thinking, to create more holistic and effective approaches to software development. Additionally, with more and more companies adopting Agile methodologies, Agile is becoming a part of mainstream. Next to Agile itself, Design Thinking is the big other technology getting to mainstream.

Agile and Design Thinking are both iterative, user-centered approaches that prioritize flexibility and collaboration. Agile focuses on the rapid development and delivery of working software through the use of cross-functional teams and incremental, iterative development cycles. Design Thinking, on the other hand, is a problem-solving approach that emphasizes empathy for the user, rapid prototyping, and iterative testing to arrive at innovative solutions.

While Agile and Design Thinking have different origins and are used in different contexts, they share many common principles and can be used together to create a more holistic approach to software development. For example, a Design Thinking-inspired approach can be used to generate ideas for new features or functionality, which can then be rapidly developed and tested using an Agile methodology.

Combining Agile and Design Thinking can also be beneficial for creating a more seamless and efficient workflow, as well as ensuring that the end product is not only functional but also user-friendly and satisfying. However, Agile and Design Thinking both have their own set of potential drawbacks.

One potential drawback of Agile is that it can be difficult to plan and budget for longer-term projects, as the focus is on delivering working software in short, incremental cycles. This can also make it challenging to accurately predict when a project will be completed, as requirements and priorities may change during the course of development. Additionally, Agile methodologies can be challenging to implement in organizations that are not used to working in a highly collaborative and adaptive way.

Design Thinking can also have its own set of drawbacks. One of the most significant challenges is that it can be time-consuming and resource-intensive, as it requires a lot of user research, prototyping, and testing. Additionally, Design Thinking can be difficult to integrate with more traditional, linear development processes, such as Waterfall, which can create challenges for organizations that are trying to adopt Design Thinking practices.

Furthermore, Design Thinking-inspired approaches can also be criticized for being too focused on the user and neglecting other important stakeholders or factors such as budget, timeline, and feasibility of the solution.

Overall, Agile and Design Thinking are powerful approaches that can help organizations to develop innovative solutions and create better products, however, careful consideration of the potential drawbacks and a good understanding of the context of the project is required to make sure they are implemented effectively.

Speaking about Agile, we cannot walk past the question, how to choose a framework among Scrum, Kanban, etc. Choosing an Agile framework can be a complex process, as there are many different options available, each with its own set of benefits and drawbacks. Here are a few key factors to consider when choosing an Agile framework:

Kanban VS Scrum
  • Team size and composition: Different Agile frameworks are better suited to different team sizes and compositions. For example, Scrum is often used by small, co-located teams, while Kanban is better suited to larger, more distributed teams.
  • Project complexity: Some Agile frameworks, such as Scrum, are better suited to handling complex projects with multiple dependencies and rapidly changing requirements. Others, such as Kanban, are better suited to more straightforward projects with well-defined requirements.
  • Organizational culture: The Agile framework you choose should be compatible with the culture and values of your organization. For example, if your organization values predictability and stability, Scrum may not be the best choice.
  • Prior experience: If your team has prior experience with a particular Agile framework, it may be a good idea to stick with it, as it can take time to fully understand and implement a new framework.
  • Goals and priorities: Different Agile frameworks have different strengths and weaknesses, so it’s essential to choose a framework that aligns with your project goals and priorities. For example, if you’re looking to improve team collaboration, Scrum might be a better choice than Kanban.

It’s important to remember that Agile is not a one-size-fits-all solution, and there’s no perfect Agile framework. The best framework for you will depend on your specific situation and context. It’s also important to note that Agile frameworks are meant to be flexible and adaptable to the needs of the team and project, so even if you choose one framework, it’s important to keep an open mind to adjust and adapt as needed. And same goes for choosing Agile and/or Design Thinking – it might be not the best fit for your team.