Revamping SAFe’s Program Level PI Metrics Part 1/6 – Overview

Whilst the Scaled Agile Framework (SAFe) has evolved significantly over the years since inception, one area that has lagged is that of metrics. Since the Agile Release Train (ART) is the key value-producing vehicle in SAFe, I have a particular interest in Program Metrics – especially those produced on the PI boundaries. Continue reading “Revamping SAFe’s Program Level PI Metrics Part 1/6 – Overview”

Do Product Owners Need Technical Skills?

How can you tell if you would benefit from having technical skills as a product owner? To answer this question, I find it helpful to look at how the role is applied. If you manage a digital product that end users employ, such as a web or mobile app, then you usually do not require in-depth technical skills, such as, being able to program in Java, write SQL code, or know which machine learning frameworks there are and if, say, TensorFlow is the right choice for your product. Continue reading “Do Product Owners Need Technical Skills?”

The SAFe Bet Over Agile Scrum for Enterprise Applications

Last summer, I changed companies. I had changed jobs before, but this time was different. Not only was I leaving a life of knowing everything (well, almost everything), but I also was leaving a product (LISA) I had invested the past 10 years of my life in supporting (like breaking up with a longtime girlfriend). Little did I realize then that I was about to start my Agile journey all over again. As a product manager, this journey was to take developers who were implementing cowboy methodologies to Agile Scrum. Along the way, we moved from JIRA and Grasshopper to IBM Rational and then to Rally (CA Agile Central) and managed not to lose all the stories and to keep some history of stories to source control for supported versions. The learning and the journey were amazing; there’s nothing like supporting a test product that drives Agile transformation but also helps your own development team adopt and understand Agile transformation. Continue reading “The SAFe Bet Over Agile Scrum for Enterprise Applications”

CapEx and OpEx

Lean-Agile Leaders need to understand an Enterprise’s current software development capitalization practice, as well as how to apply these principles in Agile development. Otherwise, the transformation to Agile may be blocked or, alternately, the company may not be able to correctly account for development expense.
—SAFe advice

Capital Expenses (CapEx) and Operating Expenses (OpEx) describe Lean-Agile financial tracking practices in a Value Stream budget. In some cases, CapEx may include capitalized labor associated with the development of intangible assets—such as software, intellectual property, and patents.

Enterprises provide funding to a SAFe portfolio to support development of the technical Solutions that allow the company to meet its business and financial objectives. These Lean Budgets may include both Capital Expense (CapEx) and Operating Expense (OpEx) elements. In accordance with accounting standards, some enterprises may capitalize (CapEx) some percentage of the labor involved in creating software for sale or internal use. Continue reading “CapEx and OpEx”

Defining “Scaling” Agile, Part 6: Creating the Agile Organization

We might start to think about Agile approaches as a project change. However, if you want to “scale” Agile, the entire culture changes. Here is a list of the series and how everything changes the organization’s culture:
• Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams. Without feature teams, I don’t see how you can have the necessary collaboration for Agile approaches to succeed. This is the beginning of moving from functional silos to product delivery.
• Defining “Scaling” Agile, Part 2: Program Management for Product Development. Program teams allow you to move from projects to programs with just enough organization. This is the extension of moving from small silos to involving much more of the organization to deliver value in the form of products.
• Defining “Scaling” Agile, Part 3: Creating Agile Product Development Capabilities. Adaptive and iterative planning at multiple levels provides the organization the ability to commit for now and not forever. This creates the beginning of a resilient organization.
• Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development. Workgroups require a different way to think about Agile approaches. Once workgroups realize how they contribute to the rest of the organization, they provide the organization the ability to deliver value more often.
• Defining “Scaling” Agile, Part 5: Agile Management. Management creates and nurtures a culture of collaboration and optimizing “up” wherever possible. Moving from resource efficiency (and finances) to flow efficiency has the possibility of changing everything. Managers hold the keys to creating a resilient organization.
All of these “scaling” ideas require change.
Agile organizations become very good at small changes all the time. They are adaptive and resilient. They understand how change works and they embrace it (big changes are quite difficult for almost everyone. Small changes tend to be much easier).

Here is a picture of the Satir change model. We start off in Old Status Quo with some level of performance. Some Foreign Element arrives and we have uneven performance while we are in Chaos, searching for that Transforming Idea. We discover that TI and practice can integrate that idea into our work until we reach a New Status Quo, hopefully at a higher level of performance.
The change model works for each human and for the entire organization. In fact, I don’t see how you can have an agile organization until people become comfortable with small and large changes on a regular basis. This is one of the reasons I say we should take an agile approach to Agile. (See Agile is Not a Silver Bullet.)
Do you need to be a fully adaptive and resilient organization? Only you can answer that question. Maybe you start from teams and the project portfolio. Maybe you look for incentives that don’t create optimization “up” (I need a new word for this! Do you have suggestions for me? Please comment if so).
You do not have to have a fully Agile organization to recognize benefits at the team and project portfolio levels. Agile is Not for Everyone.
Decide how much change your organization needs to be successful. Practice change, as often as you can. That will help you more than an Agile label will.
One last comment: I’m not sure “scaling” is the right way to think about this. For me, the scaling idea still has roots in silo thinking, not flow thinking. That could be just me. I wish I had a better way to explain it.
My ideas of scaling Agile are about creating a culture based on our ability to change:
• How do we treat each other? Do we/can we see each other as an intrinsic part of a whole?
• What do we discuss? Do we discuss “failures” or learning opportunities?
• What do we reward? How do we move to rewarding non-silo work? That is, work to deliver products (in either projects or programs) or other work that rewards collaboration and flow efficiency.
I hope you enjoyed this series. Please do comment on any of the posts. I am curious about what you think. I will learn from your comments.

Defining “Scaling” Agile, Part 5: Agile Management

Discover how to build scalable and maintainable UI tests to optimize your Agile workflow. Brought to you in partnership with TestComplete by SmartBear.
One of the challenges I see in organizations is how managers can use Agile approaches. One of the biggest problems is that the entire organization is organized for resource efficiency (think silos of functional experts). Agile approaches use flow efficiency. Thinking in flow efficiency changes everything.

Many people in organizations believe that dividing up the work among specialists will get the work done faster. That’s the case in manufacturing (think piece work.) Manufacturing processes use resource efficiency to reasonable effect. However, manufacturing does not account for innovation or learning (design of manufacturing processes is innovative and requires learning. That’s why manufacturing processes often prototype (iterate on their work) when they develop the process).

Organizations who need to optimize for innovation or learning realize that people work collaboratively. Collaborative work—including management work—demands flow efficiency instead of resource efficiency.
Flow efficiency helps people optimize “up” for lack of a better term.(if you have not yet read This is Lean: Resolving the Efficiency Paradox, I recommend you do so).
Once you start to think about flow efficiency, you might start to think about throughput (and maybe cycle time and cumulative flow). That changes the data the managers need to make decisions.
Now, it doesn’t matter what anyone’s utilization is. What matters is the Cost of Delay (or Cost of Delay/Duration). It might even matter where the bottlenecks are and who can unwedge those bottlenecks.
An organization might still need to track the run rate for a project, program, or even a workgroup, such as Customer Support. The run rate might not mean as much when you can measure revenue, customer acquisition and retention, and how often you can get the customer to return and buy more (the more often you deliver value, the more you can acquire customers who pay).
One manager learned about flow efficiency. She was managing the team working on the “most important” project in the company. She decided to stop tracking utilization. She told her team, “I want to track your throughput as a team. I want to know what I can do improve the flow of work through your team. Please bring me your impediments to flow and I’ll address them.”
The team told her about build time (too slow), insufficient test automation (not enough and too slow). She built the case using Cost of Delay/Duration to get other teams to help this team reduce build time and increase test automation.
The teams together took eight weeks to make what they called infrastructure improvements. After the first two of those eight weeks, the team finished twice as many stories (2 instead of 1) as they had before all the improvements started. The team continued to increase their throughput. By the end of the eight weeks, the team was able to finish anywhere from 8-12 stories. The team continued their now-higher level of throughput. After three months, the organization had attracted many more customers. They decided to move to a subscription model for their product, and recognize much more revenue.
Yes, a team’s ability to deliver value fast created feedback loops for management: product management, project portfolio management.
(I’m still reading about Agile-useful metrics, so I’m sure there is more here.)
If managers worry about flow efficiency, they ask the teams, “What can I do to help your throughput?” The managers manage the project portfolio. Workflows through teams, not through people.
That changes what managers do. Top-level managers (and maybe product managers) define the strategy and talk to customers to see what customers need so they can refine the strategy. Top managers also consider new options for entirely new products—changes in strategy.
Middle managers plan and replan the project portfolio to implement the strategy. First-level managers remove impediments to collaboration.
Let me summarize a little:
Agile managers have a very different role than more traditional managers. They manage differently. Agile managers might use the two pillars of Lean, respect for people and continuous improvement, as a basis for their management style. To me, that means building relationships with each person the manager “manages,” the willingness to question all assumptions and to look at the whole. What does it take for us to succeed as an organization? The idea of one function succeeding instead of all of us vanishes.
Flow efficiency changes the corporate culture: managers change what they discuss. Managers change what they reward. Managers change how they treat people and how they expect people to be treated because it’s not about the individual “resource.” It’s about the system of work.
Here are the posts so far:
I think I need another part about Agile management and then I can talk about an Agile business. I’m enjoying the rigor of my thinking. I hope you do, too.
Overcome the weakest link in your automated testing cycle to increase test speed and coverage. Brought to you in partnership with TestComplete by SmartBear.

Automating the Automation Tools at Capital One

Listening to his talk, it seems like George Parris and his team at Capital One aren’t keeping “banker’s hours.” George is a Master Software Engineer, Retail Bank DevOps at Capital One. At the All Day DevOps conference, George gave a talk, entitled Meta Infrastructure as Code: How Capital One Automates our Automation Tools with an Immutable Jenkins, describing how they automated the DevOps pipeline for their online account opening project for Capital One, a major bank in the United States. Of course, there is a lot to learn from their experience.

George started by pointing out that software development has evolved – coming a long way even in just the last few years. Developers now design, build, test, and deploy, and they no longer build out physical infrastructure – they live in the cloud. Waterfall development is rapidly being replaced by Agile, infrastructure as code, and DevOps practices.
Where we see these technologies and methodologies implemented, IT Operations teams are acting more like developers, designing how we launch our applications. At the same time, development teams are more responsible for uptime, performance, and usability. And, operations and development work within the same tribe.
George used the Capital One Online Account Opening project to discuss how they automate their automation tools – now a standard practices within their implementation methodology.

For starters, George discussed how Capital One deploys code (hint: they aren’t building new data centers). They are primarily on AWS, they use configuration management systems to install and run their applications, and they, “TEST, TEST, TEST, at all levels.” Pervasive throughout the system is immutability – that is, once created, the state of an object cannot change. As an example, if you need new server configurations, you create a new server and test it outside of production first.
They use the continuous integration/continuous delivery model, so anyone working on code can contribute to the repositories that, in turn, initiate testing. Deployments are moved away from the scheduled release pattern. George noted that, because they are a bank, regulations prevent their developers from initiating a production change. They use APIs with the product owners to automatically create tickets, and then product owners accept tickets, making the change in the production code. While this won’t apply to most environments, he brought it up to demonstrate how you can implement continuous delivery within these rules.
Within all of this is the importance of automation. George outlined their four basic principles of automation and the key aspects of each:
Principle #1 – Infrastructure as Code. They use AWS for hosting and everything is in a Cloud Formation Template, which is a way to describe your infrastructure using code. AWS now allows you to use CFTs to pass variable between stacks. Using code, every change can be tested first, and they can easily spin-up environments.
Principle #2 – Configuration as Code. This is also known as configuration management systems (they use Chef and Ansible). There are no central servers, changes are version controlled, and they use “innersourcing” for changes. For instance, if someone needs a change to a plugin, they can branch, update, and create a pull request.
Principle #3 – Immutability. Not allowing changes to servers once deployed prevents “special snowflakes” and regressions. Any changes are made in code and traverse a testing pipeline and code review before being deployed. This avoids what we all have experienced – the server that someone, who is no longer around, set up and tweaked differently than anything else and didn’t document what was done.
Principle #4 – Backup and Restore Strategy. A backup is only as good as your restore strategy. You know the rest.
George also dives into how they do continuous delivery/continuous integration in his talk, which you can watch online here.
If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free-of-charge here. Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed). It’s all free, online on October 24th.
• Like0

• Share


“Agile at Scale” Doesn’t Mean What You Think It Does

The Agile Zone is brought to you in partnership with Techtown Training. Understand how your role fits into your organization’s DevOps transformation with our DevOps eBook.
Enterprises have many IT projects that are moving concurrently and interdependently. Some of these projects are huge in size and scale. While Agile may be in place for a company in typical small team situations, the need exists for it to also be used on a much larger scale, encompassing many teams. So, the question arises: How do you use Agile so that the small teams are not working in isolation but, rather, in coordination with each other in a large enterprise? The answer to this question requires Agile to scale up and work in a way that all small teams on a large project are coordinated and integrated.
Though the title of our webinar “’Agile at Scale’ Doesn’t Mean What You Think It Does” may be a bit presumptuous (since we don’t really know what you think “Agile at scale” is), we think the topic is important and one that is relevant to what is working in corporations today. Agile, as it was original created, doesn’t address this need to scale up for larger projects and organizations, but there are many frameworks that do.
One of the most widely used frameworks to achieve this scale is SAFe. Our webinar gives you an introduction to SAFe and how it can be used in a large environment to coordinate smaller Agile teams. The webinar is packed full of information you can use, but in this article, we wanted to give you some of the highlights in the form of these 5 key takeaways:
1. SAFe is a framework for scaling Agile in a large organization.
2. SAFe allows the enterprise level to work in an Agile way.
3. Only implement the pieces of SAFe that you need.
4. You must invest in overhead in order to coordinate teams.
5. Restructure systems into a service-oriented architecture.
SAFe Is a Framework for Scaling Agile in a Large Organization
SAFe is one of the most widely used frameworks for scaling Agile in a large organization with situations that are larger than having a few smaller, Agile teams. A typical Agile team is usually 6-12 people. Scaled teams can be dozens, or even hundreds, of workers. When a small team isn’t sufficient for a project, you need to scale Agile.
SAFe Allows the Enterprise Level to Work in an Agile Way
SAFe uses layers in its framework that build from the team level up to the portfolio level. The layers are (from bottom up):
• Team
• Program
• Value Stream
• Portfolio
Team Layer
The team layer is at the bottom of the SAFe framework because it is the basic core where the actual IT work is done. These are normal Agile teams structured with up to 12 workers, a product owner, a Scrum Master, a backlog, and so forth. These teams are not working in isolation in the SAFe framework; the other layers enable the teams to coordinate and work in parallel with each other.
Program Layer
The Program layer adds the structure that is necessary to coordinate teams for the large project. This is the layer where the project work of the individual teams comes together. This layer sets up the integration of the work by pulling the pieces together, guiding, and coordinating all the teams.
The key players in this layer are the RTE (Release Train Engineer), the System Architect/Engineer, and Product Management. The RTE coordinates the logistics of the overall project. The role of the System Architect/Engineer is to design the system and put the pieces together, addressing whatever technical issues are appropriate given the technologies being used and the type of product that is being built. Many times, this role also addresses the integration testing at the program level as the pieces of the teams are put together.
Product Management is made up of the product owners of the small teams. The product owners work in concert with each other and should be in sync from a logical product perspective.
Value Stream Layer
The Value Stream layer is a higher level that meets the enterprise needs for very large projects. This layer is coordinating multiple release trains. Questions that are answered on this level are:
• What do we need?
• When do we need it?
• How do we deliver value?
• How do all of the programs work together?
The Value Stream Engineer “conducts” and coordinates the work. The Solution Architect/Engineer and the Solution Managers provide the context for the roles being performed in the Program layer.
Portfolio Layer
The Portfolio layer is designed for true Agile enterprise management. Many organizations are stuck in traditional approaches, which can be a common challenge for teams that are working in an Agile way. Historically, organizations have worked in a waterfall, and it is very difficult to break this habit. The Portfolio layer addresses this challenge by allowing the Portfolio Management, at the enterprise level, to be done in an Agile way. SAFe provides a set of guidelines for looking at the entire portfolio of the work being done, thereby enabling Agile from the value stream engineering down to the Agile team development processes.
Only Implement the Pieces of SAFe That You Need
The SAFe framework is designed so that you only use the pieces that are appropriate for your particular situation. SAFe is flexible in allowing you to use as much or as little as your business needs. For example, a small organization may only need to use the Team and Program layers. Maybe your business only needs the Portfolio and Program levels. Maybe you don’t need the Value Stream level if you don’t have very many programs. Use critical thinking in implementing the roles and layers that will be helpful as you coordinate the product teams in your organization.
You Must Invest in Overhead in Order to Coordinate Teams
In scaling Agile for an enterprise you need additional roles, and this means an investment must be made for the additional overhead and time that is required. Essentially, the top 3 layers of the SAFe framework diagram are overhead. But, in order to move forward and scale Agile, an organization must make an investment, keeping the long-term goal in mind. This is especially true for organizations with old monolithic systems that have many structural issues. An investment in money and time is necessary in the short-term so that the business can become competitive and succeed in the long-term.
Restructure Systems Into Service-Oriented Architecture
A lot of organizations have difficulty staying out of the waterfall and, therefore, are not able to sync their projects. A solution is to deconstruct large projects into smaller pieces of work that are service-oriented. By restructuring large systems into more service-, object-oriented architecture, you can decrease interdependencies. DevOps is a helpful approach in providing techniques you can use to decrease interdependencies and allowing the development of a modular architecture.
Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap, brought to you in partnership with Techtown Training.

Accept Work to Deliver: The “WHAT” Factor

Being ‘Agile’ is the buzzword in IT these days. I will not be overstating it if I say that all industries are leveraging the benefits of Agile.
In complex projects, it is not possible to gather all the requirements upfront at once, due to extreme uncertainties. Therefore, we use Agile methodologies to divide user requirements into short independent requirements, each of which is called a ‘user story.’ These user stories are given to the team for implementation.
It is important that requirements in a user story are well understood and well documented. Moreover, you need to ensure that the team is complying with the delivery standards. To ensure that all the above aspects are fulfilled, the following standards processes have been devised:
1. Definition of Ready: What Does It Mean?
It means that a user story should be written correctly and explained to the team in detail. In a Sprint which lasts for 2-4 weeks, the requirements can’t be discussed for days/weeks. Hence, it is important to consider following points while a user story gets accepted by the team to be worked upon in the Sprint:
a. It should be well worded and explained to the team.
b. All open queries which the team has raised during grooming sessions must be closed/resolved.
c. All dependencies must be resolved.
d. It should follow INVEST criteria, i.e. Independent, Negotiable, Valuable, Estimable, Small, and Testable.
e. Each user story should be small enough to be completed within the Sprint.
2. Definition of Done: What Does It Mean?
It means that once the team has agreed to work on a user story, the following things should be considered as completion factors for each user story:
a. Code review is done and review comments have been incorporated.
b. Testing done in the specified environment and not on a development machine.
c. Automation test scripts in place.
d. All raised defects have been resolved and closed.
e. Tool (JIRA/Rally/RTC) being used by the team has been updated with the actual hours and correct status of the story and all the tasks.
f. Sign-off from PO.

Leadership in Agile Project Management

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies.
Agile Project Management is revered as one of the prominent methodologies introduced to practice modern day Project Management. It is also one of the recent and value-driven project management strategies has been widely applied to software development practices to deliver high priority and high-quality work. Therefore, it is best suited to relate software development processes to Agile project management methodologies for better understanding and enhanced leadership.
With the advancement in software development, requirements and technologies, traditional models like the Waterfall model are not robust enough to cater to the ever changing demands of clients. In order to address the agility of the requirements, the need was recognized to build a more flexible and robust alternative. As a result, Agile software development models were developed. Since the Agile development models are different from the traditional models, Agile project management is a specialized area in project management.
Leadership in Agile Project Management
In the traditional Waterfall model, the Project Manager is burdened with improvising and adapting the requirements of change and maintaining the project quality, scope, reporting, risks, etc. Whereas in Agile project management, these roles are divided among the entire team and it is not just the manager’s responsibility.
It is divided into following Agile leadership roles:
• The Product Manager: Sets project goals, adapts to the changing requirements, balances the scope versus schedule, acts on and sets the priorities for product features.

• The Scrum Master or Iteration Manager: Guides the team and removes the obstructions by prioritizing and monitoring their tasks.

• Team Members: Handle the assigned tasks, development, process reporting, and the product quality control.

It is very evident that the entire team is responsible for managing the affairs and unlike the Waterfall model, it is not just the project manager’s responsibility. The right person at the right place and division of labor ensures that things can progress at a faster rate and there is no time lapse in decision making.
With that said, many of you might be wondering who is supervising the Agile development projects.
The simple answer to this question is ‘not an individual but the entire team.’ The principles of the Agile Manifesto call for self-motivated and directed professionals to work on the projects as self-organizing teams. Team members handle the specified tasks as per their capabilities and project requirements, and the entire team is collectively responsible for the successful completion of the project. The Agile Manifesto believes in spreading the management tasks across the team, so as to empower all team members and spur productivity and innovation.
Enhancing Leadership
If you are responsible for the team working to attain a common objective, then I believe you are a Supervisor or Leader. In this blog, I’ll be discussing the ways to enhance the leadership capabilities of certain roles, especially for Project Managers and Scrum Masters.
Here are a couple of recommendations:
1. Maintain Focus and Perform Your Duties

2. Some people believe that Agile environment offers as little the Project Management as possible. With all due respect, I completely disagree with this statement. The Agile process is very fast paced and disciplined. To accommodate change and to stay on track, the Agile approach demands constant attention to the team, processes, and results. Easy to understand and implement Agile methodologies suggests a number of practices that assist us with the basics of software development and project management in the Agile model. But what’s essential and equally important is to alter the leadership style to reap the maximum number of benefits while adopting the Agile methodologies.
Some novice Project Managers follow the ‘hands off’ approach, and because of this their team struggles through the initial maturity phases, and Agile appears to fail. It is essential for the success of the project that the team members find ways to interact, have good debates, and solve problems together. An ideal leader will encourage and facilitate these processes throughout the various project steps.
As a Project Manager or Iteration Master, you should:
◦ Plan and improvise the activities.

◦ Conduct informal social events.

◦ Conduct team building activities.

◦ Conduct Retrospective sessions.

3. Understand Your Team Members

4. Understand your team and identify the outliers, if any. During Scrum sessions, if you find missing characteristics of hard work and self -discipline in an individual, then you should do whatever it takes to counsel those professionals as much as you can.
Self-discipline can be measured by following characteristics:
◦ Accepting accountability.

◦ Engaging in debates and interactions.

◦ Willingness to work.

5. Make team members trust each other. How do you do that? You must trust them first!
To operate effectively with your team members, you must facilitate knowledge sharing with the entire team. As a leader, you should be open to learning so as to build an amiable working environment and strong professional relationships.
6. Learn to Use Collective Wisdom

7. In an Agile project management, there are many questions that are to be answered and decisions to be made. Prioritizing the functionality, estimates of work, work allotment, requirements, etc. How do you decide on these factors? Are you making the decisions unilaterally? You are not supposed to do that and should learn to utilize the ‘Collective Wisdom’ effectively. It is expected that under the ideal conditions, a group will collectively make a better decision than one specialist.
Ideal conditions for using Collective Wisdom effectively include:
◦ Member independence.

◦ The diversity of opinions.

◦ Decentralization.

◦ The accumulation of opinions.

In the end, there are many challenges that lie ahead for the Agile project leader. These leaders have to follow and innovate different leadership approaches on the Agile projects than they would on Waterfall or any traditional style projects. What leadership approach do you follow while managing an Agile project?
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
Opinions expressed by DZone contributors are their own.

Defining “Scaling” Agile, Part 2: Program Management for Product Development

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies.
The first post was about scaling functions to working as collaborative Agile teams. See Defining “Scaling” Agile, Part 1: Creating Cross-Functional Teams. Now, let’s talk about moving to multiple teams working together, a program.
The good news is that you have a few cross-functional teams. They’ve been delivering as project teams. And, now you have a program, a collection of several projects with one business objective.
Programs come in a wide variety of shapes and sizes. Here are some kinds of programs:
• You might have just one feature team and need people from Marketing or Legal to release the product. You need to bring those people into the program somehow, so they can accomplish their deliverables so the organization can release the product.
• The project is larger than one or two feature teams. You may have several feature sets and need people from Marketing, or Legal, or Finance (or someone else) to be able to release the product.
• You might be managing the software program, and have several feature teams or programs within the larger program. You might have the Engine program, and the Admin and Diagnostics programs. Each feature set has several teams collaborating on the code in their feature set(s). And, you probably need people across the organization to finish the work for the product. Those are the people from Marketing, Legal, Finance, or others that I keep talking about.
Programs exist when you need a little structure to organize the feature teams and/or organize the deliverables across the organization. Agile programs especially don’t need too much structure. The key is to create something that helps the people collaborate and visualize the work they need to complete.
Here’s a way to think about scaling to a program:
Scale the collaboration across product development to release products.
Here’s how I think about scaling collaboration across product development:
• Each team thinks about how fast they can release their work to the rest of the program (BTW, fast isn’t useful unless the work is great).
• Each team manages its WIP (Work in Progress) so they aren’t bottlenecking themselves or anyone else.
• The POs work as a team so the feature teams always work on the most valuable work for the program. Sometimes, feature teams move from one feature set to another because that work is more valuable. If you’re worried about interdependencies, you might not have feature teams. Or, the POs aren’t working together. See Understand Your Project Interdependencies.
• Teams use the power of their small-world networks (and possibly Communities of Practice) to solve problems at the team level. Teams often don’t need help from anyone with “manager” or “master” in their titles.
Aside from trusting the teams to deliver and asking them to let you know if they can’t, I also suggest these ideas:
• Scale the visualization of the work. How do people see what other teams or people are doing? (I have plenty of images of kanban boards so you can see if any of those work for you).
• Keep the hierarchy as flat as possible so problems don’t have to go up a hierarchy, over and down, and then follow their path back before someone gets the answer they need.
• Consider a cadence of meetings that solve problems. These meetings are not standups. Standups might expose problems but they don’t solve them.
I recommend teams decide if they need to organize as small programs (such as above with the Engine, Admin, and Diagnostics programs). That allows a cadence of limited-participation program team meetings to solve problems the teams can’t solve.
In addition, measure at the program level. Sure, the teams need to measure their cycle time and velocity, whatever they choose. In addition, measure the features complete at the program level, program level WIP, and any other program measures that make sense to you (see Velocity is Not Acceleration for two of these charts).
Agile program management helps product development use Agile approaches to release products. Next up is how to scale Agile from product development to other parts of the organization.
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.

Agile – For the Sake of Being Agile

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.
In the last few weeks, I have been approached by corporations wanting to talk about implementing the Scaled Agile Framework (SAFe). When faced with this scenario, I often ask three questions to get the conversation started:
1. What is your current level of Agile Adoption?

2. What does SAFe mean to you?

3. Why do you feel like SAFe is the answer?

I found myself a bit surprised with the similarities I have experienced with the answers received by my questions.
Across the board, when I asked the current level of Agile adoption, I was given an answer that little (if any) Agile was in place. It almost made me wonder if the individuals asking me believed SAFe was something new and not built upon the Agile methodology. More than anything else, it felt like some publication focused on C-Level executives created a short article on SAFe and it sparked heavy interest for those working in the higher levels of Information Technology (IT).
Those I talked to gave me the impression that SAFe was going to be a silver bullet for solving problems with their organization. The whole “silver bullet” thought process continues to surprise me – since this metaphor has remained a lesson unlearned for decades within IT.
My Thoughts
I consider myself an advocate of the Agile methodology, but I always make sure there is an asterisk next to my statement. My biggest clarification is to make sure Agile is being adopted in a manner that best suits the organization. Too many times, I feel like organizations are participants in some type of Agile competition – where the one to adopt the most concepts wins a huge prize. I have no idea who is judging this competition or what reward would be received.
This is not to say that aspects of the Agile lifecycle are not important, but to say if something is not working for an organization – for whatever reason – consideration should be taken to explore alternatives. One of the alternatives is to just not do it. I mean, it is not like some Agile police department is going to show up and cite you for an Agile infraction.
I’ve seen this where things like daily standup meetings have been re-tooled to provide the better value while keeping the team members abreast of the progress of the team. I’ve seen where retrospectives are held at longer intervals because the teams realize it takes longer to truly see aspects that need to be addressed.
I have similar thoughts on SAFe. I mean, SAFe by specification is quite an involved endeavor to implement and maintain – both versions 3.0 and 4.0. In the conversations I noted above, I pushed the “walk before trying to run” ideal to my clients and to avoid doing more Agile just for the sake of doing more Agile. To me, this is no different than writing music.
With music, there are all kinds of music styles to choose from. Composers have a variety of options to explore and tools to use when being creative with their music. It is rare for a musician to incorporate every style of music in a single album – let alone a single song. While some styles of music complement each other, some just do not make sense to combine. Trying to implement SAFe in a single effort feels like a musician trying to compose an album that includes every music style. Instead, musicians pick the music styles that work for them, for a given release.
So, when you find yourself trying to push deeper into the world of Agile, make sure to avoid falling into the trap of doing more Agile just for the sake of being Agile. Agile is no different than the process it is managing … if something is not working, learn from it, find a better way, and move on.
Have a really great day!
The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.
Like This Article? Read More From DZone
Opinions expressed by DZone contributors are their own.

How to Sell Your Boss on Roadmaps Without Timelines

I wonder what it is about feature roadmaps that is comforting to the C-suite. Is it the false sense of security that you’re setting yourself up to deliver a list of features based on untested assumptions and educated guesses? Is it the delusion that locking your organisation into a plan a year in advance equals a competitive edge?
As product managers, we instinctively know that planning things out in advance is impossible, because our work depends on a constant stream of testing, data and feedback.
Our bosses don’t. Or maybe they do, but they’re not ready to accept it yet. Cody Simms of Techstars is convinced that everyone already knows that feature roadmaps are nothing more than a comfort blanket: “Whether you are a CEO, board member, investor, or employee…EVERYONE knows that the roadmaps that are published in these documents are a joke. And yet, there they are. Every time. A random list of features with monthly or quarterly delivery dates assigned to them,” he says.
For bosses, I think there’s a perceived risk in moving from a safe and predictable feature roadmap to an experiment-based lean product roadmap.
They want answers. They want predictability. They want you to know exactly what to take to market, they want customers to know exactly what they’re getting and they don’t want any surprises along the way. Minimising risk feels good.
But it doesn’t square up at all with your reality: that if you get your predictions wrong, it’s nearly impossible to course correct. Imagine having to build out phase 2 of something your customers rejected last month.
Feature roadmaps communicate those features you plan to build, even if they’re the wrong ones.

Imagine trying to casually change this roadmap at a 500-person organisation.
So how do you break in the idea of lean roadmapping with a boss who finds anything less than a feature roadmap to be an unnecessary risk?
By convincing them that it opens up your business to an even greater risk: that by sticking to the plan they risk losing customers and market share.
How would you convince your seniors to try out this new approach? Here’s how you do it:
Show Them Problems You’re Solving
Features and timelines make bosses feel comfortable – and you can give them some of that comfort without making huge commitments on your roadmap.
First of all, bosses are usually only interested in upcoming initiatives. That’s an opportunity for you to explain dates wherever it’s important to do so, but also use it to explain the bigger picture in a way that still lets you be flexible.
For example, here’s a lean product roadmap split into three time horizons: Current, Near Term and Future.

Current might mean “next two weeks”, Near Term might mean “next two months” and Future might mean “six months or so, if we’re still in business!”.
Typically, you can get agreed dates (at least roughly) with your team for Current term projects, because you’re working on them already. You can note these dates on the card themselves. If there are specific milestones that are business critical, note those on the cards too.
As the company and the product vision grows, these horizons naturally expand – as if you’re able to see further and think bigger. A complex mature product might have a roadmap that stretches five years in the future, where current is “next six months” or more.
It makes sense that you can provide more certainty on the stuff you’re currently working on over the stuff that’s way out in the future. It’s intuitive to understand and easy to explain, and your bosses will be on board with this.
Show Them What You Lose When You Give Up Validation and Testing
The best example I can think of when a product veered dangerously off track from what customers want is Juicero. Juicero used their $120 million investment to the solve the following problem:
“Juicero’s mission is to make it dramatically easier and more enjoyable to consume more fresh, raw fruits and vegetables.”
This seemed like a pretty ambitious goal with a pretty big market value. Fair enough. But the public fallout/outcry after the company introduced a $400 juicer that was, according to one product designer “easily in the top 5% on the complexity scale” was no doubt incredibly painful and expensive for everyone involved.
The team engineered a beautiful and intricate product, but ostensibly did not test their assumptions along the way.
• Who was in the market for a $400 juicer?
• Did the product they were building match up to their vision and mission?
• What value or problems were they solving for customers?
• Would people maybe realise that they could squeeze the juice bags faster by hand and more cheaply than a $400 juicer?

Obviously this is a somewhat extreme example in terms of money and stakes, but this happens all the time at companies that rely on a feature roadmap.
There’s little leeway to test and validate assumptions, and though that may keep you on track, what if it’s the wrong track? If you’re slow to adapt to market reality, reality isn’t going to wait for you to start over and get it right.
Keep Them In The Loop On How Your Product Strategy Is Changing Through Testing
Problems that are valid now might not be valid down the line. Instinctively, we all know that, including your boss.
Just as the prototype of your product evolves and changes as you learn from your users, your roadmap should be open to evolution too.
When you learn something new, you remove irrelevant items and add in new things as you learn.
The roadmap you created six months ago isn’t meant to be valid today. If it were, it would mean that either you were 100% correct in all of your assumptions (unlikely!) or that you haven’t been learning along the way.
Revisit your roadmap every month or so, or whenever you learn something that changes your view on what should be built. Whenever you update your bosses about your product roadmap, emphasize what you’ve learned and how that’s guiding your product decisions.
The great thing about this format is that it allows you to add to the roadmap, stick to the format, but evolve your thinking around the product planning as you grow.
You’re not just adding a longer and longer timeline with more features, you’re actually evolving the contents of the roadmap to better tell the story of how you’re going to reach your vision.
When you present your roadmap, make sure to explain the rough timelines you’re talking about, but also point out that these are subject to change and shift as you all as a team learn and develop the product.
Remind Them It’s What Leading Businesses Are Doing
When Slack first introduced its platform roadmap last year, it was clear its vision was bigger than communicating features and its launch dates: “We are building for a future where Slack is dwarfed by the aggregate value of the companies built on top of it. This is our success as a platform — when the value of the businesses built on top of us is, in sum, larger than we can ever be.”
Leading product companies like Slack, Foursquare, Intercom and ProdPad are doing their product planning without timelines because there’s a bigger endgame in sight.

Slack invites developers into its product management process with its product roadmap.
The benefits of a product roadmap extend far beyond communicating a set of features on a timeline.
A roadmap can be used to share upcoming plans with your customers, communicate the exciting future of your product and build an ongoing dialogue with the stakeholders that matter to your business.
Roadmapping without a timeline is not a leap into the unknown. Quite the opposite, actually. It’s control over the future of your product like you’ve never had before.

How to Scale Agile and DevOps Together 

Agile, DevOps, continuous delivery—and all of it at scale. How do these things come together? Businesses want to do more with the technical advances that DevOps and agile have conferred, but when it comes to next steps, those who advocate “scaled agility” seem to talk past those who discuss “the DevOps enterprise.

Are they talking about the same thing? Can scaled agile frameworks help businesses push DevOps capability to new levels of competitiveness? Or is DevOps, finally, what scaled agile frameworks such as SAFe, DAD, Nexus, and LeSS need, in order to lift those enterprise-scale practices to levels where they can truly make a difference?

Given the huge popularity of both agile and DevOps, I asked several experts what they think of the interplay between these modes of software development, and how agile and DevOps complement each other at scale. Here are the key takeaways from those discussions—things that often don’t come up specifically as teams start to organize their efforts around DevOps and continuous delivery.

Continuous testing: A practical guide

Talking agile vs. DevOps: Separate conversations?

The most productive way to understand the relationship of agile and DevOps is not as an intersection, but as a progression of capability. So you’re not necessarily having separate conversations. You can place them along a continuum, with agile on the left, DevOps to the right of center, and continuous delivery on the far right, as the ultimate goal. That’s a progression that organizations can move through, in stages, with some teams progressing faster than others.

This is also a progression that loosely describes the history of where we are today:

Most organizations working to apply agile methods at scale today began small. (You and your team can probably relate.) They got to the point where more teams and more projects were adopting Scrum or XP. By the time DevOps entered the discussion, experienced teams were ready to expand agile beyond the boundaries of development and QA.

If you feel that this continuum and brief history is an over-simplification, you may be right in many cases.

Special coverageAll DevOps Enterprise Summit 2016 posts

Improve your flow: Get teams working together

“Our goal was to put more effective working relationships in place to improve the flow of work, as well as the quality and speed of that work,” say Scott Prugh, Chief Architect and Vice President of Software Development Operations for CSG International, a company that operates customer billing systems for the telecommunications industry. Over the past few years, CSG has been exploring DevOps as a way to examine its own technology culture and organization, and to improve its techniques for managing operations.

“We found that it doesn’t matter which framework you adopt. The key thing agile did for us was helping teams manage much more of the development lifecycle.”

This includes operations, infrastructure, and sysadmin roles, as well as design, architecture and quality, Prugh says. “Those responsibilities used to exist in separate organizations, and that separation wasn’t good for an optimal flow of work. Teams couldn’t learn from each other, and the separation magnified the problems with hand-offs between one specialty and the next.”

Scaled frameworks for agile offer a more cross-functional approach to the roles in the development lifecycle.

“Teams can now learn at a faster rate, so they can build and deliver to customers a lot more efficiently.”

Add Ops guidance to your agile framework

Teams working towards continuous delivery through a scaled DevOps approach shouldn’t wait for their agile frameworks to provide detailed guidance. “What we’ve taken to the next level is going further with those frameworks, and embedding more operations components so that teams can deliver the entire service,” Prugh says. “That has included designing and developing new functional features for customers, as well as developing operational features to make the software more efficient.”

That means these teams now own much more of the operations concern within the entire lifecycle. “Dev and Ops are much less at odds with each other in a management and organizational sense.”

Adopt a build-and-run teams concept

A general consensus has evolved among organizations that have adopted DevOps at the project level, what Amazon calls “build and run” teams. The idea is that teams that build and run their own software can improve systems faster. They’re accountable for more of the software delivery chain. Before that, accountability lay with a completely different organization. These teams also have a more general understanding of the issues that, when addressed, will make the software run well.

“At a basic level, you need to fold the components of the operational concerns into the teams that build and run the software,” says Prugh. “At CSG we call them productivity teams. You just can’t transfer accountability, assuming another group is going to take over your operational concerns.”

Move away from process thinking

Much of operations has traditionally been viewed as a process activity. While ITIL is a well-regarded process framework, Prugh’s team accrued additional benefits by folding some ITIL processes into the teams that have the engineering expertise. “You can engineer those processes so that they’re highly efficient—whether that’s brute-force automation around those processes, or changing your software so those processes are effectively built into your delivery mechanisms,” he says.

Build-and-run teams solve the problem of the agile development-to-operations handoff. Typically, there’s little continuity.

“[If] we can fold operational processes such as ITIL into the dev framework, and improve team structures, along with the skills and roles that need to be on those teams, then we’ve got much more cross-functional capability to deliver great features.”

Get specific: Use DevOps to improve SAFe

While  Prugh says it doesn’t matter which scaled framework for agile you adopt, it helps to see the infusion of DevOps principles in terms of one specific framework. In this case, I’ll use the Scaled Agile Framework, or SAFe, since it’s well-known, and since it should be relatively easy for readers to see how these principles can be applied to other frameworks.

Topo Pal, Director and Platform Engineering Fellow at financial services firm Capital One, describes how DevOps principles aid SAFe in his organization. “SAFe doesn’t explicitly say you have to automate everything,” he says. “Early versions of SAFe suggested that some functions could be done in an automated way. But in my experience of DevOps you can do automation at any level, and you may not need the ‘system team’ described in the SAFe framework.”

System teams in SAFe are all about the operational aspects of a release, especially continuous integration, infrastructure, and automated builds. But SAFe does not stress that these things have to be automated, although automation can add considerable benefits. “With DevOps practices, automation adds another level of capability to SAFe,” says Pal.

“If I’m a developer, I should be able to build and run my test cases, but if I have to rely on another team, I’m faced with the same old bottlenecks that plagued waterfall methods.”

Isn’t DevOps already included in SAFe?

Yes… if you take a look at Scaled Agile Inc’s SAFe diagram, you’ll see that DevOps represented in the big picture in the upper left corner, and in the accompanying article. The confusion, if there is any, has to do with where you are in the agile/DevOps discussion.

When people think about DevOps, SAFe—or any scaled agile framework, for that matter—won’t be the first thing that springs to mind, because frameworks like SAFe have more recognition on the development side of things. Currently, DevOps appears to be an afterthought in the SAFe model. Which isn’t to say that will always be the case.

“SAFe is really focused on getting the enterprise to consider how it delivers value,” says Steve Mayner, senior program consultant at SAFe Inc. “That value is critical to a company’s customer base, to its monetization model. The principles and practices are about identifying the full ecosystem, regardless of existing silos and skill sets that it takes to go from concept to cash, to get the value out the door.”

Move more people under your umbrella

In the SAFe conception, the agile release train requires roughly 50 to 150 people to deliver that value, “and that isn’t just about developers,” says Prugh. “It includes a huge number of people associated with operations, whether they’re sysadmins, security, infrastructure, help desk…all of those functions outside development have to be on board. They have to meet together regularly, to integrate, to demonstrate what they’re building iteratively.”

“If you take the operations players off the train, all you’re doing is moving the bottleneck.”

Mayner agrees: “You can develop things really fast, all the way to the point of release. But without the folks in charge of the release process, or moving things into production, or supporting the release for the user community, you only get partial benefit. Of course, SAFe didn’t grow up in the center of the DevOps conversation, but it has always been part of the core assumption that the full ecosystem has to be end-to-end.”

Important software delivery practices—such as consistency in platform configuration, from the developer machine to the test environment, to staging and production systems—can be adjusted for continuous delivery, Mayner says.

“All of these practices in a DevOps approach can be automated for change management and configuration control to allow the kind of quality that supports a continuous delivery model.”

Next steps in the move to enterprise DevOps

Invariably, the agile conversation comes first, and it’s likely that your own organization is beyond simply having that conversation. Now, if you’re exploring DevOps, especially as a way to do more with what you’ve learned, you may be ready to apply agile principles to multiple teams, and full programs. This is a good place to be, because “development practices tend to be on the same page,” says Mayner. “Larger teams are saying ‘Wait… this isn’t going out the door unless our folks in production, support, and maintenance are also on board.’”

That’s DevOps.

Here are the five steps you should take as you begin this conversation.

  1. Identify inefficiencies in your current flow. What can be automated for improved consistency and repeatability?
  2. Determine what inefficiencies are the result of hand-offs from one team to the next.
  3. Adopt a build-and-run team approach to your next project.
  4. Whether or not you’ve begun using one of the scaled agile frameworks—SAFe, DAD, LeSS, and Nexus are among the most popular—take the time to study these diagrams and learn which of the practices described map to your own, or might help you improve your own practices at scale.
  5. Consider ways that you might expand your current agile practices to include operations concerns. That might include, for example, moving configuration management into the team that was formerly just “dev.”

Expanding to a DevOps mindset is “a major result of our training sessionsn [in his SAFe consultancy,]” Mayner says. “We stress the need to have all of the ecosystem working together so that all the operation teams are participating in the release train and the continuous integration planning event.”

With larger customers who have only just begun to work in an agile manner, the progression from agile to continuous delivery might be greatly collapsed, says Mayner.

Organizations that are behind the curve, but which wake up and see how their practices need to evolve, and whose leaders educate themselves in both agile and DevOps, are now getting it. These teams don’t want to start at agile and later move to DevOps, Mayner says. “They want to start with what’s state-of-the art today. They tend to jump in with both feet, with a flow-based awareness, and suddenly everybody’s on the train together.”

Agile Metrics — The Good, the Bad, and the Ugly

Suitable agile metrics reflect either a team’s progress in becoming agile, or your organization’s progress in becoming a learning organization.

To address the team level, qualitative agile metrics typically work better than quantitative metrics. At the organizational level this is reversed: quantitative agile metrics provide better insights than qualitative ones.

Good Agile Metrics

Generally speaking, metrics are used to better understand the current situation as well as to gain insight on change over time. Without metrics, assessing any effort or development will be open to gut feeling and bias based interpretation.

A metric should therefore be a leading indicator for a pattern change, providing an opportunity to analyze the cause in time.The following three general rules for agile metrics have proven to be useful:

  1. The first rule of tracking meaningful metrics is only to track those that apply to the team. Ignore those that measure the individual.
  2. The second rule of tracking metrics is not to measure parameters just because they are easy to follow. This practices often is a consequence of using various agile tools that offer out-of-the-box reports.
  3. The third rule of tracking metrics is to record context as well. Data without context, for example, the number of the available team member, or the intensity of incidents during a sprint, maybe turn out to be nothing more than noise.

For example, if the (average) sentiment on the technical debt metric (see below) is slowly but steadily decreasing, it may indicate that the team:

  • May have started sacrificing code quality to meet deadlines or
  • May have deliberately built some temporary solution to speed up experimentation.

While the latter probably is a good thing, the first interpretation is worrying. (You would need to analyze this with the team during a retrospective.)

Good Qualitative Agile Metrics: Self-Assessment Tests

If you like to track a team’s progress in adopting agile techniques and processes, self-assessment tests are well-suited for that purpose. For example, I like to use the Scrum Checklist by Henrik Kniberg.

All you have to do, is to run the questionnaire every four to six weeks during a retrospective, record the results, and aggregate them:

In this example, we were using a kind of estimation poker to answer each question with one of the three values green, orange, and red. The colors were coded as follows:

  • Green: It worked for the team.
  • Orange: It sort of worked for the team but there was room for improvement.
  • Red: It either didn’t apply, for example the team wasn’t using burn down charts, or the practice was still failing.

If the resulting Scrum practices map is getting greener over time, the team is on the right track. Otherwise, you have to dig deeper to understand the reasons why there is no continuous improvement, and adapt accordingly.

In addition to this exercise, I also like to run an anonymous poll at the end of every 2-week-sprint. The poll is comprising of three questions that are each answered on a scale from 1 to 10:

  1. What value did the team deliver last sprint? (1: we didn’t deliver any value, 10: we delivered the maximum value possible.)
  2. How has the level of technical debt developed during the last sprint? (1: rewrite the application from scratch, 10: there is no technical debt.)
  3. Are you happy working with your teammates? (1: I am looking for a new job, 10: I cannot wait to get back to the office on Monday mornings.)

The poll takes less than 30 seconds of each team member’s time, and the results are of course available to everyone. Again, tracking the development of the three qualitative metrics provides insight into trends that otherwise might go unnoticed.

Good Quantitative Agile Metrics: Lead Time and Cycle Time

Ultimately, the purpose of any agile transition is to become a learning organization, thus gaining a competitive advantage over the competition. The following metrics apply to the (software) product delivery process but can be adapted to various other processes accordingly.

In the long run, this will not only require to restructure the organization from functional silos to more or less cross-functional teams, where applicable. It will also require to analyze the system itself, for example, to figure out where value creation is impeded by queues.

To effectively identify the existing queues in the product delivery process, you start recording five dates:

  1. The date when a previously validated idea, for example a user story for a new feature, becomes a product backlog item.
  2. The date when this product backlog item becomes a sprint backlog item.
  3. The date when development starts on this sprint backlog item.
  4. The date when the sprint backlog item meets the team’s ‘Definition of Done’.
  5. The date when the sprint backlog item is released to customers.

The lead time is the time elapsed between first and the fifth date, the cycle time the time elapsed between third and the fourth date.

The objective is to reduce both lead time and cycle time to improve the organization’s capability to deliver value to customers. This is accomplished by eliminating dependencies and hand-overs between teams within the product delivery process.

Helpful practices in this respect are:

  • Creating cross-functional and co-located teams
  • Having feature teams instead of component teams
  • Furthering a whole-product perspective, and systems thinking among all team members.

Measuring lead time and cycle time does not require a fancy agile tool or business intelligence software. A simple spreadsheet will do, if all teams stick to a simple rule: note the date once you move a ticket. This even works with index cards.

Other Good Agile Metrics

Esther Derby suggests in her article Metrics for Agile to also measure the ratio of fixing work to feature work, and the number of defects escaping to production.

Bad Agile Metrics

A bad, yet popular agile metric is team velocity. Team velocity is a notoriously volatile metric, and hence actually only usable by the team itself.

Some of the many factors that make even intra-team sprint comparisons so difficult are:

  • The team onboards new members,
  • Veteran team members are leaving,
  • Seniority levels of team members change,
  • The team is working in unchartered territory,
  • The team is working on legacy code,
  • The team is running into unexpected technical debt,
  • Holiday & sick leave reduce capacity during the sprint,
  • The team had to deal with serious bugs.

Actually, you would need to normalize a team’s performance each sprint to derive a value of at least some comparable value. (Which usually is not done.)

Additionally, velocity is a metric that can be easily manipulated. I usually include an exercise in how to cook the “agile books” when coaching new teams. And I have never worked with a team that did not manage to come up with suitable ideas how make to sure that it would meet any reporting requirements based on its velocity. You should not be surprised by this — it is referred to as the Hawthorne effect:

The Hawthorne effect (also referred to as the observer effect) is a type of reactivity in which individuals modify or improve an aspect of their behavior in response to their awareness of being observed.

To make things worse, you cannot compare velocities between different teams since all of them are estimating differently. Which is totally fine as estimates are not pursued for reporting purposes. They are a side-effect of the attempt to create a shared understanding among team members on the why, how, and what of a user story.

So, don’t use velocity as an agile metric.

Read more on velocity here: Scrum: The Obsession with Commitment Matching Velocity.

Ugly Agile Metrics

The ugliest agile metric I have encountered so far is “story points per developer per time interval”. This is basically the equivalent of “lines of code” or “hours spent” from a traditional project reporting approach. The metric is completely useless, as it doesn’t provide any context for interpretation or comparison.

Equally useless “agile metrics” are, for example, the number of certified team members, or number of team members that accomplished workshops on agile practices.


If you can only record a few data points, go with start and end dates to measure lead time and circle time. If you have just started your agile journey, you may consider also tracking the adoption rate of an individual team by measuring qualitative signals, for example, based on self-assessment tests like the ‘Scrum test’ by Henrik Kniberg.

What are you measuring to track your progress? Please share with us in the comments, or join our Slack team “Hands-on Agile” — we have a channel for agile metrics.

Related Posts

How to Kick-off Your Agile Transition (Part 1)

Product Backlog Refinement — Agile Transition Part 2

How to Build Offline Boards — Agile Transition (Part 3)