Scaling Agile: How Do You Scale from Projects to Programs?

Guest post by Johanna Rothman of Rothman Consulting Group

You have some agile teams who are successful. Good for you!

Now you have a strategic project that will require many agile teams to create a program. You know you need people in several locations. You know you need a cross-functional business team to make sure you address the needs of Marketing, Sales, and even Legal. How the heck can you make this happen?

In the agile project management literature, there is a notion of program management. A program is a collection of projects with one business objective. Each project might have its own deliverables. But the real value is in the program. The sum of all the projects is greater than any of the parts.

How do you scale from an agile project to an agile program without a lot of hierarchy?

What is the Most Efficient Network in Your Organization Right Now?

When I talk to people about scaling agile, I ask this question:

If you want to move information in your organization fast, what do you?

What is the most efficient way to move information in your organization? People often smile and answer, “The rumor mill.”

People in your company have informal networks. They talk to each other. They help each other. They connect to each other in any number of ways which managers don’t know about. You can use these connections to help agile programs succeed.

“When I discovered that one of the testers needed a little help building an automated test framework, I took 15 minutes and did a screen-share. I showed her how I had started our framework for our testers. It wasn’t exactly what she needed, but it was a start for her.

She understood where I was going. She took that framework, improved on it for her team, and got them going on their own framework. It took me 15 minutes. That’s all. Now, they have their own framework, which is different from ours. That’s okay. Our testers got a show-and-tell the other day from their testers. Our testers came back all excited about the refactoring they could do. I knew it would pay off. – Senior developer

This anecdote is an example of small-world networks and communities of practice in action.

In large organizations, people have mailing lists that are the start of communities of practice. In this example, a senior developer answered a question for a tester. He spent a small amount of time coaching someone in another area of the program. The return was tremendous. “His” testers are now improving on their testing.

johanna-people-imgIn small-world networks, people want to work toward a common goal. Many of them share connections, but it’s not necessary that everyone connect to everyone else. If enough people have connections to many other people, that is good enough.

In large organizations, between the project mailing lists, the functional group mailing lists, the project and program blogs and wikis, and whatever else the agile program uses for communication, there is often a way for people to connect with one another.

The small-world network helps people solve problems rapidly. But that doesn’t help people learn what the status is. How can you organize to learn the status in an agile program and elevate risks? Even if the technical folks can solve their technical problems, you still need a way to organize to see the big picture.

How You Organize the Technical Teams in an Agile Program

jrothman-imgIf you think “scale out, not up,” this is one image of a technical program team. Think spokes of a wheel, not a hierarchy.

The software program manager coordinates the delegate project/program managers of the feature teams. As you can see, some of those teams are small programs themselves.

Sally is an agile program manager for six feature teams. Her teams all collaborate on a significant feature set. They work together on a backlog. Once the product owner decides that the team has done enough for that backlog, the feature teams might work on other features. They might exit the program entirely. It all depends on what the program needs. In an agile program, you want to take advantage of your ability to replan based on feature team availability, and backlogs being “done enough.”

Joe, Tim and Henry have single-team projects. In order to show status and elevate risks, Joe, Tim, Henry and Sally would come to the program team meeting, along with the program product owner, the deployment person, and anyone else you need from the technical side of the program.

If you have a program architect, that person would participate, also. Teams embed architects in an agile program. However, you might need to discuss the risks at the program level with an architect. It all depends on your risks and challenges.

A program team meeting is a problem-solving meeting, not a micro-commitment meeting. Since the technical people can solve problems, you don’t need a daily standup for the program team. You do need to elevate risks, and see product backlog burnup charts, among other metrics, to see if the program is on track from the technical perspective.

That’s just for the technical team. What about cross-functional business interests? Cue the Core Team.

Agile Program Management Works Across the Business


Back in the ‘80s, I facilitated a cross-functional Core Team across the business. We had a person each from Sales, Legal, Marketing, Training, Finance, Marketing Communications and Hardware. We needed to release within a particular market window so we didn’t miss a specific opportunity. I bet this sounds familiar to many of you. We had inter-dependencies up the wazoo.

I didn’t know about agile. I didn’t know about Kanban. I knew about the value of monthly deliverables, and asking people to commit to small, do-able actions. I knew they each had their “own” work to do. I knew that the program’s work was their work, too. But I suspected they wouldn’t see it that way.

At the beginning of the program, eight months before our projected launch, I asked them to meet biweekly for an hour. We had an action-item list at the bottom of our agenda, which you would recognize now as a Kanban board. Everyone had just one item, and the item only took a few hours to accomplish.

By the six-month mark, we met weekly. By now, we understood how to work together across the organization. The Hardware guy understood how to work with the Marketing guy. (These guys are all generic guys. Some of these “guys” were women guys.) The legal guy was happy because we were not going to ship an empty box. So was I!

Best of all, the product came together, as planned. Not as estimated—not even close. But because we worked our inter-dependencies each week, and replanned as we saw our deliverables, and kept our action items small, we were able to release the product in our market window.

We worked in a cadence, kept our WIP (work in progress) limits small. We replanned. We used what we now know as Lean and agile approaches.

Agile Program Management Scales Out, Not Up

Note that the teams don’t try to solve everyone’s problems. The technical teams solve the technical problems. They integrate all the time. They provide good data and insight to the technical program team.

The technical program team solves the risks and understands where the program-level problems are. The program team doesn’t have to solve the technical problems, unless the technical teams are stuck. The technical teams can always ask for help.

Because agile program management uses small-world networks, and is not a hierarchy, this approach scales out well.

The core team solves the cross-business problems. They do not attempt to manage the project portfolio, unless that problem is also in its purview. In small companies, it might also manage the project portfolio.

Program management is not new. Applying agile and Lean methodologies to program management is a new twist on program management.

To read more, see Agile and Lean Program Management: Collaborating Across the Organization,

About Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She has been in the software industry for over 35 years—and she never fell for the waterfall promise. She’s the author of eight books about management and project management. Her most recent book is Manage Your Job Search. Her upcoming book is Agile and Lean Program Management: Collaborating Across the Organization. Read more of her writing on and

Posted in Agile Methodologies, Agile Portfolio Management, Agile Project Management, Kanban, Lean, Scaling Agile | Leave a comment

Building Software Craftsmen

I see Craftsmanship as the answer to an issue that has been rising in importance over the past several years.  Agile, as a development methodology, has hit the mainstream.   While in many ways this is a good thing, there are some drawbacks.  The majority of attendees at the major conferences are now project managers, while in the past they were developers, or at least a fair mix of both.  This has helped socialize the ideas around agile development and is a good thing, but we also need to seek balance in the Force.  This has given rise to the Software Craftsmanship movement, which is focused on the Art of Writing Software, and what is required to create great software, especially in the agile world.  In a previous post, I mentioned how important Craftsmen are to the agile world.  But how does one become a Craftsman?

First, lets take a look at the state of affairs of our industry, job-wise.  It is pretty well known that being a softwaresoftware developer outlook bls
developer is a lucrative career, but the numbers are still somewhat surprising.  According to the U.S. Bureau of Labor Statistics, the median salary for software developers in the United States is around $93,000.  The statistics further show that the number of jobs in the software development field will grow by 22% in the next 10 years.  This is significantly higher than the rest of the job market.  So how are we going to fulfill these needs with high-quality developers?

Obviously, we need to train a lot of really talented people.  We need them to be able to create software well, and also to be able to work well together.  Currently, the primary source of education in software development is via the universities and colleges.  Unfortunately, not only is this failing to provide enough programmers for the jobs, it is also failing to provide the high level of quality and experience we will need.

Now, universities are great for a lot of things.  They provide a strong level of theory and understanding of the underlying science and logic.  What they don’t provide is real-world experience and practical applications of knowledge.  This needs to come from somewhere else.  My suggestion is to turn the clock back a few hundred years, and turn your team room into a workshop.  Let’s populate that workshop with Craftsmen.  We may not have all of the Craftsmen we need to begin with, so we need to build and grow them.  This can be done by applying an apprenticeship program and using the craftsmen’s model for further career development.  Let’s take a look at how this would work.


ApprenticeshipLet’s begin with the idea of hiring apprentices.  An apprentice is someone who may or may not have a formal education in software development.  What she will have is the desire to learn.  The question remains, “What will she learn and how will she learn it?”  For starters, we will focus on five main areas:

  1. Crafting Code – The art of using one or more programming languages to create clear, well-factored code.  We want our apprentices to be polyglots by the time they become journeymen, so we will do this in more than one language.
  2. Applied Principles – Well-written code isn’t enough.  An apprentice needs to understand principles like SOLID, and know how to apply them.
  3. Technologies and Tools – While programmers need to be able to practice activities like Refactoring by hand, they also need to know how to use certain tools, as well as which tool to choose for a particular task.
  4. Work Habits – Programming is about more than just showing up, slinging some code, and going home to play Mine-Craft.  Especially in an agile software development shop, we need to be able to build muscle memory around the activities that make good programmers great, such as TDD, Continuous Integration, etc.
  5. Soft Skills – The days of the socially inept programmer are over.  Software apprentices will learn how to work in a team, how to communicate with others, and other soft skills that tend to be forgotten in the traditional learning environment.

An apprentice will learn these foundational areas through working on real projects, under the tutelage of a mentor.  Ideally, that mentor might be a Master Craftsman, but if one isn’t available, then experienced, well-versed Journeymen will make good mentors as well.  At the beginning of her apprenticeship, the apprentice might do some basic things like creating and220px-Wanderbuch_journeyman_Wobrausky_from_Daschitz_02 maintaining the continuous integration environment, some bug fixing, or other tasks.  Over time, she will work with her mentor and other Craftsmen on real-world activities and projects, continually adding value to the team.  When the apprentice has demonstrated her ability to move on to bigger and more challenging projects and tasks, it’s time for her to be recognized as a Journeyman.  We will explore more about the life of a Journeyman in another article.  In order to become a Journeyman, the apprentice must show her expertise by doing, not by taking tests.  Real work pieces that evidence her abilities in various areas and languages, coupled with having paired with everyone on the team, will determine an apprentice’s ability to move on.

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile programming, Agile Software, Agile Teams, Continuous Integration, Scrum Development, Software Craftsmanship, Test Driven Development | Leave a comment

Encapsulating Value Streams and the Object Oriented Enterprise

Guest post by Mike Cottmeyer of LeadingAgile

When you get right down to it, a Scrum team is fundamentally a container designed to encapsulate the entire product delivery value stream into a single workgroup.

The value stream associated with software development typically goes something like this: analysis, design, build, test, and deploy. That’s pretty much everything you need to develop a working, tested increment of the product… and is, therefore, what defines the basic requirements for a Scrum team.

When you put analysts, designers, developers, and testers into a single workgroup; let them work across skill-set boundaries, self-organize to balance load; and have them collectively produce a working, tested increment of product on regular intervals, you can reduce a tremendous amount of planning complexity.

Your organization has to get past the belief that individual productivity and utilization are the measures of effectiveness. You have to focus more on team throughput and flow of value, but the construct allows you to move fast, change direction, and adapt as we learn more about the emerging product. Planning is simple, objectives are clear, and outcomes are measurable.

Why Scrum Breaks?

The problem with many Scrum implementations is that the team doesn’t actually encapsulate the entire value stream. In almost every real-life organization, someone who is necessary for the team to complete their work doesn’t actually live in the Scrum team. This is very simply what causes Scrum to break. Dependencies kill Scrum.

When this happens, we get into an agile project management mindset. We are running some of the work through the Scrum team, but we need extra coordination mechanisms to help us line up the Scrum team with the other parts of the value stream that live outside the team. We have external planning dependencies that have to be dealt with.

It’s my assertion that these planning dependencies are what result in teams going through the motions of Scrum without realizing value Scrum promises. Last month I did a talk at Agile 2014 that was all about why agile fails in large enterprises. The whole talk is about how to systematically break dependencies between teams.

That said, some organizations are simple enough that a Scrum of Scrums is sufficient to model and deal with the unavoidable coordination issues. Some organizations have to be more proactive coordinating complex backlogs and use constructs like Product Owner Teams, Solutions Teams, and Requirements Clearinghouses.

The key takeaway here is that when you have a Scrum team where the entire value stream is not encapsulated, you need something outside the basic Scrum construct to coordinate across the teams. Pick your poison, but something outside the team almost always has to be present.

SAFe (Scaled Agile Framework) and Value Streams

I want to see if we can pull this up a level and talk a bit about SAFe. Coming off the Agile 2014 conference in Orlando, SAFe was everywhere… and for good reason. Everyone is trying to figure out how to take the concepts we’ve learned with Scrum and get the value at enterprise-level scale. Scaling Scrum is the topic du jour.

Honestly, I don’t keep up with SAFe in detail… I’ve never been in SAFe training… and I’m definitely not part of the inner circle of SAFe thought leaders. That said, I’ve read everything Dean (Leffingwell) has written since he released Scaling Software Agility, I have a ton of respect for his work, and I agree with the basic patterns he has introduced.

(At) this conference though, I heard something I hadn’t really heard before. It seemed that everyone was talking about value streams relative to SAFe. I’m sure the concept has been in SAFe for a while, but it caught my attention differently this time around. It made me wonder if I should think about SAFe similarly to how I think about Scrum.

At LeadingAgile, we typically coach an explicit value stream in the middle-level program tier. We think about progressive elaboration and maximizing the flow of value in the middle tier. We usually encourage an explicit Kanban flow that respects some of the upstream and downstream work processes we see most often in product delivery organizations.

It occurred to me that SAFe isn’t modeling the value stream explicitly in the middle tier; it is managing the work through the PSI/PI planning meeting, fundamentally encapsulating the entire value stream within the planning construct. In short, SAFe is fundamentally operating like a big Scrum, just encapsulating a larger value stream.

Whereas I’ve been thinking most about breaking dependencies, SAFe appears content with managing dependencies and making them visible and explicit in the planning session. This is absolutely a necessary step in the process, but by not dealing with the root cause of dependencies directly, I believe they will limit your ultimate agility over time.

SAFe will struggle with dependencies at scale for the same basic reason Scrum struggles the team level. Dependencies make it hard to move.

We’ve been giving a lot of thought lately to breaking dependencies, and our work with clients is fundamentally about forming complete cross-functional agile teams and systematically breaking dependencies between them over time. We believe that this is the only true way to scale agile indefinitely to the enterprise.

We believe this concept is methodology-independent and will make any methodology you choose better in the long run.

Why SAFe Breaks?

Scrum isn’t trying to break dependencies within the team; it is merely trying to encapsulate the value stream, allowing the team members to work across role boundaries, self-organize around the work and stabilize throughput, while holding them to producing a working, tested increment every couple of weeks.

SAFe isn’t trying to break dependencies within these larger value streams, either. It is merely trying to encapsulate the value stream similarly to Scrum, allowing team members to work across role boundaries, self-organize around the work, and stabilize throughput while producing a working, tested increment every PI.

There are clearly more constructs within SAFe than exist within Scrum to deal with the larger effective team size and integration tasks, but I think that the pattern fundamentally holds. I never really thought about it that way before. I’m curious if anyone else has ever thought SAFe as kind of a big Scrum?

If we know that Scrum implementations struggle when the entire value stream can’t be encapsulated within a team of 6-8 people, do SAFe implementations struggle when the value stream can’t be contained within a team of 125? If my assumption about dependencies and value streams holds, I suspect they would.

If SAFe is ultimately going to struggle at scale beyond 125 people, does that mean that we are going to need the same constructs for coordinating value across teams that we need in Scrum? At some point will we find ourselves talking about ‘SAFes of SAFes’ or ‘SAFe Product Owner Teams’ or ‘SAFe Portfolio Solutions Teams?’

I suspect we might. I think we might also see evidence of this already.

Maybe there is some stuff in SAFe that already accommodates this, but I’m curious what’s out there to tactically coordinate across SAFe value streams? Remember, I’m not talking about investment decisions across a SAFe Portfolio… I’m talking about managing dependencies between value streams. I gotta figure some folks are dealing with this already, given how well SAFe is doing in the market.

If anyone has any insight or can point me in the right direction, I’d appreciate it. I’m interested to know how the insiders think about this? Is anyone inventing things outside the SAFe body of knowledge that are being written about? Where is the body of knowledge emerging outside of the official cannon, and are people talking about this?

Ken and Jeff Got it Right

Back in 2006 Ken Schwaber put up a slide where he illustrated a team-of-teams structure, one where lower-level Scrum teams were encapsulated in a higher-order Scrum of Scrum construct. Back in 2006 I was thinking that there was no way this would work in the absence of very loosely coupled teams (and at that time, that was NOT my reality).

A few years ago, I heard Jeff Sutherland and Jim Coplien give a talk at the Scrum Gathering in Orlando. The one line I vividly remember from that talk was that, “teams were never expected to self-organize across class boundaries.” They were implicitly saying that encapsulation was the expectation for a Scrum team to form.

Jeff Sutherland, as we speak over at is talking about Object Oriented Design (OOD) in Scaled Scrum implementations. He is basically making the case that Scrum teams are intended to be formed around Objects in an organization. It is a prerequisite for Scrum to work.

I think that this one concept is a point which has been wholly misunderstood and largely ignored by organizations adopting Scrum. Many people implementing Scrum nowadays don’t have any idea about OOD principles, let alone as they relate to organizational design and team structure.

When you read Craig Larman and Bas Vodde’s stuff around LeSS (Large Scale Scrum) and consider the structures they’ve put into place, you have to view those structures through the lens of an Object based organizational structure. Their work is built on the same foundation that Ken and Jeff laid 25 years ago, but that is seldom implemented.

I find myself fundamentally in alignment with Ken, Jeff, Bas, and Craig… and I think theirs is the best end-state for a scaled agile enterprise. The problem is that their underlying operational structure for a scaled Scrum implementation to work… the Object Oriented Enterprise… doesn’t exist in most companies adopting Scrum.

SAFe is a Compromise

I think I’m coming to the conclusion that SAFe is a reasonable compromise given the operational constraints in many organizations. If you aren’t going to form teams around Objects in your organization, you probably shouldn’t bother implementing any of the Scaled Scrum variants. You’ll just get frustrated.

That said, I do believe that SAFe is going to suffer from many of the same problems that Scrum deals with organizationally in the presence of incomplete or dependent value streams and a lack of organizational object orientation. It’s just a matter of time and scale.

At this point in the evolution of my thinking, I find myself in a place where I don’t believe the scaled Scrum stuff will work in most companies in their current state. I think SAFe will work to a point, but if it’s sold as the final destination, we are going to limit our ability to scale and ultimately limit our ability to be agile.

We can only be as agile as the size of the team, and the independence of the value streams, and the length of the PI boundary. I think organizations will soon find they are going through the motions of SAFe without really solving the problem. Again, it sounds just like where we are with Scrum in most companies.

Refactoring Your Enterprise

The only real, long-term sustainable approach to Scaled Enterprise Agile is to take the long, hard road toward refactoring your enterprise into an organization based around the OOD principles that were implied, but maybe not explicit, when agile was formally articulated 13 years ago. The problem is that this message doesn’t fill CSM classes and has to be sold all the way at the top of the organization. It will require a significant investment on the part of the executives.

The cool thing is that in the presence of this kind of organization, everything else starts to make sense. You can see a place where Scrum and Kanban live side-by-side in peaceful harmony. You can see where the technical practices fit in at scale. SAFe, Disciplined Agile Delivery (DAD), and LeSS all have a place in the pantheon of ideas. No matter which path you take, the Object Oriented enterprise makes everything else make sense. It’s the right context.

With the Object Based Enterprise as a sort of backdrop to sort out all the different perspectives on agile, we can begin to see that the conversation around potential future state starts to get WAY less interesting than what it takes to get there. I think the interesting conversation is around how we do the refactoring in the first place, and what the possible transition patterns look like which help us get there, while still running our businesses effectively.

If I think about it… that was really what my talk last week was about. It’s up on my blog, and was recorded by the conference, but that might take some time to publish. I think I’ll do my next post as an overview of the content and rationale behind the material in my presentation. Let me see if I can make that happen this weekend ;-)

- See more at:

Posted in Scaling Agile, Scrum Development, Scrum Methodology | 1 Comment

Secret Recipe for Building Self-Organizing Teams

Guest post by Venkatesh Krishnamurthy, Advisor and Curator, Cutter, Techwell, Zephyr

Some time back I noticed something odd with an agile team. Team temperature used to be 10 out of 10, and each team member expressed their happiness working on this project.  I was curious to find the secret behind an “always happy team.” A bit of interaction with the team and the ScrumMaster revealed some disturbing secrets.  Here are the key ones:

  1. The team is self-organizing, and individuals can pick the story of their choice and deliver at their discretion!!
  2. Team has neither time pressure nor delivery timelines

I thought to myself that this is not a self-organizing team, but a directionless team.

As Esther Derby points out, there are several myths and misconceptions about Self-Organizing teams.  I did cover a bit about these myths during my talk at Lean Agile Systems Thinking conference(LAST) in Melbourne, which is available on Youtube (toward the end at 1:03 minutes).

I understand it is not easy to build a self-organizing team, but there are principles enabling leaders in building such agile teams.

One of the best analogies that I have heard so far about self-organizing teams is from Joseph Pelrine.  As Joseph puts it, building self-organizing teams is like preparing soup.  I thought it would be easier for readers to understand the self-organizing concept if I map the soup preparation steps to the self-organizing steps. Yes, soup preparation involves many more steps, but the key ones below would give the clues to readers for further analysis.

The below table illustrates the mapping:



To conclude,

  • A self-organizing team needs a leader, the right amount of pressure apart from the right set of constraints/goals to succeed.
  • The true test of the self-organizing team is their collaboration ability during war time and not during peace time.
  • There is a difference between a team organizing themselves and a self-organizing team.  Don’t ignore the “self” part.
Posted in Agile Management, Agile Methodologies, Scrum Development, Scrum Methodology, Scrum Software | Leave a comment

The Impact of Agile and Lean Startup on Project Portfolio Management

With the large number of organizations now adopting agile methods, the existing body of literature has paid significant attention to the function of project management, business analysis, and more recently program management.  This is understandable as individuals filling these roles are ubiquitous and critical to the operation of their respective organizations.

Many organizations have an additional formalized function, project portfolio management (PPM), that is also critical to the organization but gets little attention — especially in light of the considerable desire being shown to scaling agile to the enterprise level.  The focus, objectives, and responsibilities of agile PPM must fundamentally shift when transitioning to an agile model, structure, and culture.  The reason for this is simple—the same agile principles that are being applied to individual projects can also be leveraged to manage the portfolio.

Below are two ways that agile PPM differs from traditional PPM:

Traditional PPM:  Optimize portfolio resources (individuals) by skill set
Agile PPM:  Maximize value delivery to customers by team capability

Traditional projects, while still delivered by teams, are much more focused on optimizing skill set across a portfolio.  One reason for this is because most traditional organizations are structured and organized by functional specialty.  That is, the organization’s structure is very hierarchical and often has individuals within a particular functional specialty (business analysis, quality assurance, project management, etc.) reporting to the same manager.

Another reason is that projects move through the process by passing through one of several phase gates such as requirements, design, test, etc.  When this is the case, project execution may be throttled by a particular skill set at each gate.  For example, if you have five business analysts, you will be limited to the number of projects that can be active.  However, most organizations ignore this fact and still have far too many projects active at any time; this only adds needless risk.  The sad truth is that most organizations really have no idea of their true project capacity.

In agile organizations, the team (not the individual) is the unit of capacity measure.  Therefore, if you have three teams that are capable of delivering an initiative or feature, you are limited by the number of teams.  So, how many projects of each type can you have active at any one time?  I don’t know; each situation will vary by organization, team, and context.  However, to get started, try setting the limit to be equal to the number of teams with the capability of delivering that type of solution.  If it doesn’t help, experiment.

For example, if you have five products that need mobile solutions, but only have three teams capable of doing the work, only start the three that will deliver the highest customer value.  Of course, that assumes that the teams are not already working on other items.

Traditional PPM:  Maximize Revenue and Evaluate Project Health
Agile PPM:  Govern Empirically through Validated Learning

One of the primary goals of traditional PPM is maximizing revenue… that is, how much money a particular project or product can add to the “bottom line” of a company’s balance sheet.  In today’s economy that is characterized by pervasive, disruptive technology and consumers that demand choice and flexibility focusing on revenue alone misses the point.

Revenue is the metric of wildly satisfied customers.

Stated another way, many would say that the sole objective of PPM is to maximize shareholder value.  This is done through increasing revenue, but it misses the point.  Because customers have flexibility and plentiful choices, the focus must be on maximizing customer value.  By focusing on customer value, if shareholder value doesn’t increase, it may be because you’re building the wrong thing.  Wouldn’t it be appealing to find that out sooner rather than later?

Further, traditional PPM typically measures the health of the agile portfolio by evaluating the health of its component projects.  This is great—in theory.  But one of the big problems with this approach is the way in which health is typically measured.  It’s most commonly done through subjective mechanisms like project status reports, achieved milestones, and progress stoplight indicators.  None of these approaches offer an objective mechanism of determining if the project is actually building the right thing.  Personally, I’ve managed projects that have delivered the wrong solution on time and within budget.  The kind of objectivity that’s required is customer validation.

A more agile PPM approach would be to introduce some mechanism of validated learning to help us make more sound and responsible decisions for our customers about what projects or products to continue funding.  Validated learning is a key aspect of the Lean Startup approach made popular by Eric Ries’ book of the same name.  Agile projects aim to build small increments of a product.  This means we are dealing with smaller return-on-investment (ROI) horizons.

Through agile PPM it’s possible to incrementally fund two projects to experiment with two different solutions to a (perceived) customer problem.  This is known as A/B testing, a.k.a., “split testing.”  Because agile methods allow us to get solutions into the hands of customers more quickly, we can evaluate the results of our experiments and shift funding to investments that are more promising and pertinent.  Because the funding is done incrementally, we need not fund an entire project for an extended period before finding out whether our assumptions were incorrect.


While these are only two of many considerations when adopting agile PPM, each has the potential to make an immediate and lasting impact on your organization and its customers, thereby, positively impacting your shareholders as well.  In my opinion, the sooner organizations can sow the seeds of customer satisfaction through validated learning, engagement, and collaboration, the sooner they will reap the rewards of increased shareholder value.

What are your thoughts?  How can you begin to apply these concepts within your own unique context?

Posted in Agile Adoption, Agile Benefits, Agile Portfolio Management, Enterprise Agile, Lean, Lean Software Development, Scaling Agile | Leave a comment

The 4-Step Action Plan for Agile Health: Step 4: Develop and Implement your customized plan for adopting healthy agile-lean practices

Agile development requires a cross-functional, self-organized team to deliver potentially shippable software at the end of each sprint, with analysis, design, code developing and testing activities going on concurrently (not sequentially) within each sprint.      Combining Agile/Scrum development with some of the lean methods is also becoming popular (so-called “Scrumban” methods). These methods emphasize reducing Work In Process (WIP), reducing feature cycle time and increasing throughput (feature completion rate).

In my blog on From Agile Pathologies to Agile Health I explained that some “agile” teams suffer from the following common pathologies, i.e., major dysfunctions in practicing agile methods, while claiming that they are “doing agile”:

  1. Agile development “sprints” assigned to software development lifecycle phases
  2. Agile development “sprints” assigned to technology tiers
  3. Mini-Waterfall inside sprints
  4. Water-Scrum-Fall

While an agile team may not be exhibiting gross dysfunctions (pathologies) listed above, it may still behave in harmful or unhealthy ways that would prevent it from realizing the benefits of agile development, such as higher productivity, throughput and quality.    Absence of major pathologies or sickness doesn’t imply health; agile teams may still not be healthy due to one or more harmful behaviors.

In this 4-part blog series, I focus on 6 harmful behaviors exhibited by agile teams and how to move away from them, and transition to 6 healthy agile-lean practices in order to get more benefits (improved productivity, throughput and quality).  I also present 4 specific steps to transition to healthy agile-lean practices.   Table 1 summarizes these 4 steps, and labels 6 harmful behaviors (as 1B through 6B) and 6 healthy agile-lean practices (as 1P through 6P) for ease of cross-referencing. Table 1 also indicates what is covered in each of the 4 parts of the blog series: Part 1, 2 and 3 (highlighted in light green color) were completed.    In this Part 4 (highlighted in pink color), Step 4 – develop and implement your customized plan for adopting healthy agile-lean practices – is described.

Table 1: The 4-Step Action Plan for Agile Health


Sprint History Map:  In Parts 1 to 3 of this blog series, I presented and extensively used Sprint History Map as a visual metric to understand what has happened on each day of a sprint timebox and to derive many useful data points to help us understand the health of an agile team:

  1. Cycle time for each accepted feature and the average cycle time
  2. WIP for each day of the sprint for accepted features in the sprint, and their average WIP
  3. Throughput (feature acceptance rate per day or per time unit) – calculated from 1 and 2 above using Little’s law; this number can be visually verified easily on the Sprint History Map
  4. WIP for each day of the sprint for all features (accepted as well as not accepted) worked on, and their average WIP
  5. Specific days when regression testing was done during the sprint (if any)
  6. Planned number of features and their total story points
  7. Velocity: Accepted number of features and their total story points
  8. Number of NT and IMP events, and their total.  These are the days when work stoppage occurred.

Many Agile Lifecycle Management (ALM) tools have a data warehouse facility for storing historical data, and analytics tools to generate reports from the historical data.   Ideally a single analytics report (or a small set of few reports) should present all the data listed above in a visually simple way to understand.   It might require some programming effort using the tool’s APIs.   You may check with your ALM tool vendor if this is possible, and seek vendor help to generate Sprint History Maps.  Otherwise, you may have to put some effort to gather different historical data items or reports to piece together your version of the Sprint History Map.

Sprint History Map is a very useful visual diagnostic tool that offers a number of critical insights indicating the health of an agile team, how effective its practices are, and how much dysfunction exists in its agile practices, etc.

Recommended approach for moving away from harmful behaviors and adopting healthy agile-lean practices:  Each team and organization is unique, and therefore has unique challenges and opportunities to move away from harmful behaviors to adopt healthy practices.   Your approach should be customized to your specific situation, constraints, needs and goals. 

It is helpful to organize 6 harmful behaviors and the corresponding 6 healthy agile-lean practices along 3 dimensions (X, Y, and Z) as shown in Figure 1.  X-dimension covers transition from manual testing to test automation, and from “frequent impediments and non-availability of qualified team members” to “effective impediment management and full availability of qualified team members”; Y-dimension covers transition from “non-lean” behaviors to agile-lean practices; and Z-dimension covers transition from “legacy mindset” behaviors to agile mindset practices.  For each transition (from a harmful behavior to a healthy practice) to succeed, I have also indicated the degree of senior management and functional management support likely to be needed along X, Y and Z dimensions.


Figure 1: 6 Harmful Behaviors and 6 Healthy Agile-Lean Practices organized along three dimensions including the degree of senior management support needed

I recommend launching an immediate effort along the X-axis by embracing test automation practice, both unit test automation with test-driven development discipline, and acceptance test automation.  Both practices will need training.  Get help from qualified coaches, and relevant training courses and books.   No team can migrate from the manual testing norm to fully automated testing practice in few sprints.   Test automation will require serious commitment and effort over several release cycles to get more and more test cases automated, and thereby building a growing suite of automated regression tests.   As explained earlier, without regression test automation, fully tested, potentially shippable software for every sprint is not feasible.  It is imperative to get started on the test automation practice and gradually minimize the manual testing effort.  Clearly, some types of testing that require human judgment, such as usability testing, cannot be automated.

Effective impediment management can be learned with practice and improved with process maturity and experience; management support is still needed for removing organizational impediments.  As multiplexing and multitasking reduces, and the team starts following Stop-Starting-Start-Finishing lean mantra, the number of NT events should reduce over a period of time.  Moving away from non-lean behaviors (3B and 4B) to healthy agile-lean practices (3P and 4P), shown along the Y-dimension of Figure 1 is a challenge that can be addressed at the team-level.  It usually doesn’t depend on and need not wait for senior management support.  I suggest starting with training and workshops on lean methods from qualified coaches.  A number of good books and web resources are also available.

Moving away from legacy mindset behaviors (1B and 2B) to healthy agile mindset behaviors (1P and 2P), shown along the Z-dimension of Figure 1, is likely to require a high degree of support from senior management and functional management because it is probably the most dramatic change in a hierarchically structured, waterfall organization.    Only the senior managers are in a position to move an organization from multiplexing/multitasking behaviors to instituting and empowering cross-functional, self-organized agile teams consisting of full-time, dedicated team members.   If you believe getting support from senior management would be a significant challenge in your organization, I suggest starting with agile-lean training for executives, where they could understand how their role changes to support agile-lean adoption, and what they will need to do differently.

You should assess which specific current behavior(s) produce the most pain, which new practice may produce the most benefits quickly, and the degree of support needed from senior management.   Some of this assessment can be done qualitatively in discussions among the team members and stake holders.   This qualitative assessment should be supplemented with measured quantitative data for one or more agile teams in your organization.  I recommend taking a look at your team’s most recent Sprint History Maps (typically the last 4 sprints) to assess its current state.

Does your agile team’s Sprint History Map look more like a healthy agile team’s map (as shown Figure 2 of Part 3)? Or does it look closer to the map of a struggling agile team (as shown in Figure 1 of Part 3)?  A careful analysis of your team’s Sprint History Maps will provide quantitative data, such as the cycle time, WIP, throughput, velocity, number of IMP and NT events.  I suggest doing this analysis for the last 4 sprints, if you have that data available.    In addition, I suggest analyzing more traditional reports for your team, such as sprint burn-down and burn-up charts, and cumulative flow charts to identify problem areas, if any.   For example, if the sprint burn-down charts show flat horizontal lines, they might be caused by IMP and NT events (but not always).  If the sprint burn-up charts show most features getting accepted towards the very end of a sprint, it may indicate that the team is not following the Stop-Starting-Start-Finishing lean mantra and has no WIP limit for its work.

With this information (qualitative as well as quantitative) you can assess your current situation, and perform a gap analysis, i.e., determine the gap between the desired goal state at some time in future (say six months from now) and the current state.  Based on this gap, you should then decide and implement the course of action: where is the biggest return on investment would be, i.e., the most benefits for the least amount of effort or time.

Table 2 summarizes the transition from 6 harmful behaviors to 6 healthy agile-lean practices.  It also summarizes several recommended possible actions that you may choose from to implement your customized action plan.

Table 2: Transition from harmful behaviors to healthy agile-lean practices
Expected challenges and suggested actions


How does your History Map look? Are any of the 6 harmful behaviors causing serious challenges and issues in your organization? Are any of the 6 healthy agile-lean practices giving your team tangible benefits? Are you interested in developing and implementing a customized approach for your transition from harmful behaviors to healthy agile-lean practices?

I would love to hear from you either here or by email: ( or on twitter (@smthatte).

Part 1: Understand harmful legacy Mindset and Non-Lean behaviors to move away from

Part 2: Understand healthy Agile Mindset and Lean Practices to adopt

Part 3: Understand how to use additional enablers of Agile Health

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Metrics, Agile Project Management, Agile Software, Agile Training, Iterative Development, Kanban, Lean, Lean Software Development, Scrum Development, Scrum Methodology | 2 Comments

Using Legos to Capture Raw Data For Cycle Time & Process Cycle Efficiency

Guest post from David Nicolette, agile coach at Eliassen Group


I’m one of six technical agile coaches engaged by a large bank to support an initiative to improve software delivery performance. The IT department is an established agile software development shop that uses the SAFe™ framework with Scrum at the team level. They are seeking to achieve continuous delivery, improve software quality, establish a developer-friendly working environment, and foster a culture of continual improvement.

We want to be able to show the effects of changes the teams make in their working practices. Improving delivery performance involves changing the way people work; therefore, we need measurements that aren’t dependent on doing the work in any particular way. Three metrics from the Lean school of thought are helpful: Throughput, Cycle Time, and Process Cycle Efficiency (PCE).

The Metrics

It isn’t the purpose of this post to explain these metrics, but here’s a quick summary. Cycle Time is the time it takes to complete one work item. Throughput is the number of “value units” delivered by the process in a given unit of time (say, per release or per month). Process Cycle Efficiency (PCE) is the proportion of total lead time in which value is added to the product. If we take a look at these measures at the start of an improvement initiative and again at the end, we can see whether the organization has improved its delivery performance.

To adapt these metrics to software development, we need to adopt somewhat softer definitions of “work item” and “value unit” than what is usual in the manufacturing domain. For our purposes at this client, a “work item” is a User Story, the type of work package used with the Scrum framework. A “value unit” is a software feature. While these things can be somewhat loosely defined and can vary in size, these working definitions are sufficient for our needs.

It’s easy enough to get Throughput using the tools they are already using. We can get a crude sense of Cycle Time from their agile project management tool by subtracting the start date from the end date of each work item, but we want a little more granularity than that so we can show the effects of external dependencies, back flows, meetings, and context switching on Cycle Time. It can be difficult to get meaningful PCE out of some project management tools, so we need to collect the raw data for that as well.

To show the impact of changes in team structure, delivery process, and technical practices on delivery performance, we want to compare these measures at the beginning and end of the coaching engagement. We’d like to see Throughput and PCE increase, and we’d like to see mean Cycle Time and Cycle Time variation decrease.

Generally speaking, increased Throughput means the teams are delivering more software in each release than they were previously. Increased PCE means the teams are spending proportionally more of their time adding value than they were previously. Reduced Cycle Time means the teams are able to complete work items in less time than previously. Reduced variation in Cycle Time means the teams are learning to decompose work into similarly sized User Stories, and/or they have eliminated some of the blockers that had been present in their process. Reducing variation in Cycle Time improves planning predictability, which usually leads to greater stakeholder confidence in the teams and higher trust across the organization. In turn, those factors feed back into delivery performance in a positive way.

You may have noticed that there is no mention of comparing estimates with actuals. This is an entirely empirical approach. Observed actual performance is of interest. Optimistic stretch goals, coerced commitments, and guesses are less informative than empirical observations. These teams follow the usual Scrum ceremonies and practices, including relative sizing of User Stories in terms of Story Points and estimation of tasks in terms of hours. We do not find that information useful for understanding the effectiveness of software delivery.

Collecting the Raw Data

The typical way to collect baseline numbers for these metrics is to conduct a value stream mapping workshop that involves most or all team members for one day or longer. The client is worried about losing too much time in the workshops when the teams could be doing value-add work. Therefore, we needed a less intrusive way to collect baseline measurements. There is also the question of how accurate the PCE data will be when it is obtained through a workshop, rather than by direct observation of team activity.

I came up with the idea of using Lego bricks to collect the raw data for Cycle Time and PCE. There is some impact on team member time, but hopefully it is not too intrusive. My observation is that people enjoy manipulating Lego bricks, and they don’t mind sticking the bricks on a plate to represent their work.

For each team, we set up a Lego plate large enough to hold about 10-12 1″×2″ bricks. We allocate one row of bricks for each User Story. For each hour in the day, team members place a green brick when they performed value-add work on the User Story, and a red brick when the User Story was in a wait-state during that hour. A 1″×1″ white brick is used to show User Story completion. We don’t worry about counting minutes. At the end of each day, we collect the data from the Lego plates in a spreadsheet and remove all the bricks for a fresh start the next day.

Here’s how the Legos looked at the end of the first day for the first team that set this up:


Each team tweaks the setup in their own way. In this case, the row of black, blue, and yellow bricks across the top of the plate represents the hours of the day. Black and blue colors alternate for visual clarity. The yellow brick represents the lunch hour. User Stories are identified by their key in the team’s project management tool.

From the state of the Lego bricks, you can see that the team had six User Stories in “in progress” state. For the first one, value was added during one hour out of eight. There are no 1×1 white bricks, which means none of these User Stories has been completed.

At the end of each day, I collect the data from the Lego plates and accumulate the values in a spreadsheet. Here is how the spreadsheet looked when I had entered the data from the board above:


After capturing the data in the spreadsheet, the Lego plate is cleared and we start the next day with a clean slate. There is no need to extend the Lego bricks indefinitely, as we are interested in accumulating Cycle Time observations and not in building up a physical history of User Stories in the form of Lego bricks.

Here is how the board and spreadsheet for the same team looked after the second day of collecting data:

lego image3


What we do with the information

The plan is to collect this information for a couple of sprints at the start of the improvement program, and repeat the collection again for a couple of sprints toward the end of the program. We don’t want to create an ongoing administrative task for team members. We are interested in:

  • Mean Cycle Time – average time to complete a User Story
  • Common cause variation – variation within one standard deviation indicates common cause variation; that is, variation that is caused by systemic factors (organizational or team structure, process steps, technical practices, etc.). This can point to potential structural or procedural improvements.
  • Special cause variation – variation beyond one standard deviation indicates special cause variation; that is, variation that results from unusual events or one-time problems. This can help us define policies to deal with unexpected issues in a way that doesn’t significantly impede continuous flow.
  • Clustering – Cycle Time observations may settle out into multiple clumps. This indicates User Stories that have certain characteristics have a different effects on Cycle Time. For example, User Stories that have dependencies on external teams or outside vendors may tend to have longer Cycle Times than User Stories the team can fully control. Understanding the impact helps us perform short-term planning effectively.
  • PCE – low PCE may point to “time sinks” in the process that we can address. External dependencies are an obvious cause of wait states, during which no value can be added to the User Story in progress. Wait states may also be caused by team structure, when teams of specialists are organized in silos, and multiple teams must be engaged to complete a single User Story. Context switching due to high WIP is another obvious cause. It’s useful to be able to make these effects visible, as people are more willing to address underlying issues when they see evidence than when they just hear words.

We are more interested in aggregate numbers than in individual User Stories. Mean Cycle Time (possibly broken out by categories of stories) helps with short-term forecasting. Beyond that, we can look for opportunities to shorten mean Cycle Time and to reduce variation in Cycle Time to improve continuous flow.

Here is a generic example of a chart we might generate from observations of Cycle Time. It is not based on the specific teams mentioned here — we haven’t been collecting data long enough to develop this sort of visualization.


Initial observations

Two of the four teams involved in this have embraced the idea openly, and the other two are hesitant because they have not yet seen how it might help them. The two teams that have embraced the idea started to change their habitual behaviors almost immediately, as soon as the wait states in User Stories became visible.

1. Immediate reaction to impediments

It’s commonplace that when something is made visible, people act on it. I was surprised to see the natural response when a team member reaches for a red brick. Others on the team immediately ask what the impediment is and how they can help. These were already practicing “agile” teams, so they are already stable teams working in team spaces, and collaboration was not a new concept at the start of the engagement. However, the immediacy of their reaction to seeing a red brick is a radical improvement in the speed with which teams respond to emerging issues.

You might point out that basic “agile” practice includes posting an indicator on the User Story card on the team’s wall as soon as an impediment comes up. These teams are not in the habit of doing that, so there is typically a delay before the team begins to act on impediments. A couple of these teams did not have a card wall at all when we started working with them. They believed their electronic project management tool served the same purpose as an information radiator, which is not always the case. The organization has been using “agile” methods for several years, but not every team does every little thing to perfection.

2. Limiting WIP

A second natural reaction to the boards is that when a team notices a large swath of red on their board, they start exploring the reasons why. Without any formal training in Lean concepts, they quickly conclude that they have too many User Stories in play. They limit their WIP, even without knowing that term. Before the impact of high WIP was visible, team members often said they did not understand the “big deal” about pulling just one or two User Stories at a time.

Management looks at the burndown charts and cumulative flow diagrams (CFDs) for each team. Nearly all teams in the organization have the classic “hockey stick” burndown chart, and a CFD that looks like a single block of color representing “in progress.” The teams that have started to notice the impact of high WIP thanks to their Lego boards are already starting to show burndowns that look like actual burndowns. They are pulling User Stories through to completion rather than starting everything on the first day of the sprint. Within days, it became a sort of game to see if the team could eliminate all the red bricks from their board.

3. Tracking unplanned work

A third reaction has to do with “user stories” that are not really User Stories. Many of the teams in this organization define “user stories” as placeholders for unplanned work. Scrum is generally good for managing planned work — the Product Backlog lists features to be developed in priority order by business value. Each Backlog Item is decomposed into one or more User Stories, which can then be pulled into Sprints for development.

Teams that service requests from other teams do not know in advance when the other teams will request services. The requests are not in the Product Backlog. As an expedient to fit this into the Scrum framework, they define pseudo-stories where they throw in “tasks” when other teams submit requests for services. They try to account for the impact by setting aside a portion of their available time each sprint to handle whatever unplanned work may come in during the sprint. This tends to throw off their sprint forecast, but they can’t think of another way to account for the work that is consistent with their understanding of the Scrum “rules.”

A consequence of the practice is that these “user stories” appear to have Cycle Times equal to the Sprint length and to spend almost all the time in a wait-state. This is because they are ongoing, open-ended “user stories” that can never be completed, and most of the time there are no unplanned requests in progress. If they continue to do this, their Cycle Time metrics will be skewed. Making Cycle Time visible causes these teams to reconsider the way they define and track unplanned work.

Without prompting, some people have suggested moving to a Kanban system that supports explicit policies for different classes of service, rather than trying to define every type of work as a User Story. Others are considering allowing urgent “stories” to be added mid-sprint and having the Product Owner remove scope from the sprint backlog, as per standard Scrum practice. The important thing is that they are thinking about better ways to manage unplanned work.

4. Manager response

The managers over the Release Train were very interested in how Cycle Time and PCE were being used. I explained what the metrics mean and how we intend to use them to show progress with the process improvement goals. I took them on a tour of the four team areas and they saw how the Lego boards had been set up. They asked team members whether this was helping them, and got mixed, honest answers. The managers noticed that some teams routinely work through the lunch hour and some routinely work 10-hour days. They expressed to the teams that they don’t want them to burn out and they want to figure out ways to get the work done in a sustainable way during normal working hours. This had a positive effect on team morale.

The managers were just as interested in playing with the Lego bricks as the team members. They suggested various changes, using additional colors to represent details about wait states. I suggested that we keep it simple. We don’t want to turn this into yet another administrative overhead task for the teams. I think I convinced them that we only want to capture the wait times, and leave root cause analysis for later.

5. Micromanaging time?

A couple of people voiced the concern that we were asking individuals to keep track of how they spend their time. The organizational culture is such that management expects people to get their work done, and does not track when, how, or where they work. I had to clarify that this is about tracking time from the point of view of a User Story, and not from the point of view of any individual person. We want to expose time sinks so that we can help management change the organizational structure and formal procedures in ways that make life better for development teams. Once that was clear, people were not opposed to it.

Any comments?

Please let us know what you think below!

Posted in Agile Coaching, Agile Management, Agile Methodologies, Agile Metrics, Agile Teams, Agile Velocity, Scrum Development | 1 Comment

Top 10 Causes of Chaos in Agile Software Development

“Everything is so chaotic.”
“Seems like we are constantly in a state of chaos.”
“Is agile always crazy and chaotic?”

Chaos is a word I hear a lot lately while working with software development teams that are either initially adopting agile software development or possibly undergoing a Lean/agile reshaping to improve their existing agile development approaches. I am often asked if the chaos will subside, and the good news is it will — to a certain extent. But to best understand when things will slow down (or even if they’ll slow down), it’s good to explore some of the causes that make things chaotic with agile software development.

And in my world, there’s no better way to assess than to make a list of Top 10 causes of chaos in agile software development:

1. New Teams Forming.

New TeamThis one is obvious — as people come together to work with one another there’s a feeling-out period. Usually during this period, teams are learning how to collaborate and work through conflicts. In addition to the people learning to work with one another, there are plenty of established organizational structure and cultural barriers that slow the progress of agile teams forming.

2. Process Learning.

Complex ProcessAnother obvious one. Although most agile process frameworks (e.g. Scrum or Extreme Programming) are fairly easy and well documented, it takes time and practice to learn the mechanics. Couple this with #1 and, well, there can be some real challenges to getting things done.

3. HEAVY Learning Mode.

Young Student overwhelmed with studyingThis may seem redundant, but it really cannot go under emphasized. In addition to learning about each other and learning the process frameworks, as engineers — we are constantly learning about technologies, learning about our products, learning about our customers, well — just getting smarter. Needless to say, this all adds up.

4. Greenhorns.

Crab Fishing GreenhornIf you ever have watched the Deadliest Catch on The Discovery Channel, you get to see the struggles and pains of the first-time deckhands – called Greenhorns. They are often in way over their heads, running into challenges around every corner, and are just flat out exhausted. In addition to physically and mentally killing themselves, they are trying to prove themselves. Well, this is true with just about every new team member. Not only are they dealing with Items #1-3 above, the intensity of learning is magnified; until they have some wins and time under their belts, chaos exists.

5. When Quality is NOT Built-in.

Rolex Quality Built InIt is my opinion that in software development, over the years we’ve invented this approach to quality that is “risky and invites failure.” [1] Yes, I stole that — in most software development shops, quality is something that is done by different people to ensure “separation of duties” and because of the mentality that ‘developers make bad testers.’ Couple that with the attitude that QA engineers can’t, or don’t necessarily need to know how to code, we have what we do today — a ton of end-of-stream testing, out-of-band automation efforts and, honestly, even the staunches of agile shops struggling with testing and ensuring quality. Without quality weaved into the Design>Build>Test cycle, we tend to see a lot more of these noisy things called Defects. Defects take a ton more time and energy than building it right in the first place.

6. Quality Automation Doesn’t Exist.

Sonar DashboardWithout automation you’re going to find it almost impossible, or at least extremely constraining, to effectively and efficiently deliver software quality in a predictable manner. Similar to the “build quality in” challenges, teams often struggle because their estimation processes call out quality separately (which makes it a target for evil doers), and it often does not account for the work-around automation. Many organizations adopting agile software development don’t have an automation strategy for their legacy code. Therefore, they tend to have bouts of analysis paralysis around the problem space or they simply say, “our product or software is too hard to automate the testing” — so they won’t try. The other challenge around automation is that some see it solely as an end-of-line UI automation thing where a couple engineers work on it. Test automation is a holistic challenge and needs to be treated as such.

7. Lack of Cadence.

Perpetual Motion - Agile CadenceWhen teams are starting out, they don’t realize that the first thing to establish is their cadence — get their schedule in place and timebox everything. The cadence surrounds the process touch points that require formal communication and help us to build habits, thus making the process aspects of agile software development more muscle memory. If you feel like you are always in meetings or your iteration meetings are not occurring at the same Bat-Time and same Bat-Place, it might be time to reset; your cadence is lost.

8. Unpredictable Release Cycles.

Roll DiceThis one is an enigma because there are teams I run into that say, “Our product is too large and complex to release in short cycles.” And then there are those that say, “We just release when we have to, it could be twice today or two weeks from now.” Looking at these two statements, they appear to be opposite in cause; however, it all comes down to #7 above and understanding what is the ideal batch size that reduces thrashing allows for tighter alignment among teams; reduces “Integration Hell;” and prevents the amoeba-style releases that never seem to end.

9. Deadline-Rich Environment.

DeadlineProjects are the problem — or at least the traditional sense and meaning of a project drives the idea of fixed scope and fixed schedule. Let’s look at the PMI’s definition of ‘a project’:

A project is a temporary group activity designed to produce a unique product, service or result.

A project is temporary in that it has a defined beginning and end in time and, therefore, defined scope and resources.

At the end of the day, we drive our business off of the idea that of pushing for a date — we get emails from colleagues asking “when?”, we get emails from tools telling us “now!”, and we have other teams telling us “yesterday!” Ultimately, projects drive expectations that are generally dates; we can’t seem to get away from them until everyone realizes that we should design and define the scope to fit the schedule, not the schedule to fix the scope. This is because the schedule usually flexes in these situations, not the scope.

10. Estimation (and For That Matter, Capacity) is Not Understood.

Voodoo-dollWe often see teams measuring productivity units of time versus being measured as units of value. This is the case even in mature agile shops. Everyone is so focused on trying to come up with a voodoo formula to determine capacity of a team or organization and another voodoo formula to normalize story points across teams in order to build a long-term plan based on the cooked-up numbers. The funny thing is that in many cases, the approach used for estimation doesn’t really change once an organization starts using agile. Everyone continues to plan predictively what we really don’t know. Agile software development is an adaptive approach to estimation and capacity. We work with what we know, we measure value, we assess complexity, and we often simply size efforts based on relative uncertainty. If people would just keep it simple, try to get all stories to the same level or near the same level of certainty, and do the same with the to-do’s (a.k.a. tasks and tests) — then in a couple iterations, teams could just count the stories and count the to-do’s accomplished within a timebox and use that for planning. Oh, if only it could be that simple … it is.

Okay, this was just my brainstorming or brain dump (literally) of 10 things that cause chaos in software development, in particular in the situations where an agile adoption or reshaping is underway. Just keep in mind, change is constant in business — now, more so than ever. Software development is complex; so are people. The great thing about tomorrow is that we don’t know what is going to happen. So, just practice and keep in mind: if today is bad — then there’s tomorrow.

Posted in Agile Adoption, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Agile Teams, Lean Software Development | 1 Comment

Establishing a Sustainable Pace

Guest post by Ben Linders, Netherlands-based senior consultant, InfoQ editor and blogger

Agile promotes that teams work in a sustainable pace to be able to keep delivering value to their customers. When agile teams are working under too much pressure, technical debt increases and the velocity and productivity of teams goes down. Agile retrospectives can help you to discover the causes of pressure and take actions to establish a sustainable and healthy pace with your teams.

A sustainable pace is a workload which a team can handle for a longer period, without compromising the quality of the product. It is based on a velocity that is doable for the team and doesn’t lead to stress or illness of the team members. Organizations can deploy agile processes that give teams flexibility to self-organize their work to manage their workload and flow.

When the workload of the team becomes too high, chances are high that team members will make more mistakes with increased technical debt as an result. Team pressure drives code quality down and increases maintenance. Due to the technical debt, the velocity of the team will decrease so they will actually be delivering less value to their customers while putting in more hours. Clearly a waste of valuable time, money, and energy of your people.

Finding the causes of team pressure

Some pressure is acceptable, but if you have the feeling that you are always working under pressure,the pressure is hampering your teams to deliver value to your customers, and the low quality of your products is costing you money, then that is something that should be addressed.

You can do that for instance with valuable agile retrospectives, by using exercises where team members state how they feel things are going. Facilitators can ask questions to discover what can be done to reduce the pressure. A retrospective can also be used to find the root causes of team members feeling constant pressure. You can do a five times why exercise to investigate the deeper causes of pressure.

How do you find out if teams are under pressure and what causes it? Here are some things coaches can focus upon in retrospectives, daily stand-ups, or in mentoring and coaching sessions:

  • Do teams get enough freedom to do the work in the way they think it should be done?
  • Are team members allowed to fail or make mistakes? Is it ok to learn from them?
  • Is it just 1-2 people who are under pressure, or is it everybody on the team?
  • How is the morale of your teams?  What’s the atmosphere at work, and how do people react to each other?
  • Do team members feel happy when they come to work, and when they go home?

Once you’ve identified that teams are under pressure and have learned what causes it, then they can take actions to address it in a next iteration.

Establishing sustainable pace

If a large workload is causing too much pressure and hampering teams, then they should take action.

Possible actions that they can take are:

  • Commit to a lower number of user stories in the planning game. Build in slack.
  • Investigate which improvements they can make to increase team velocity.
  • Establish stable teams that are capable of delivering quality and maintaining high productivity.
  • Prevent multitasking/task switching as much as possible.
  • Monitor work in progress; use Lean and Kanban to steer on flow instead of working more hours.
  • Plan time for team members to relax and blow off steam after having had a busy period.
  • Focus upon happiness in your teams; make sure team members have fun while doing their work.

It’s important to follow up on the actions to verify that the pressure decreases so that teams can work in a sustainable pace. An effective way to do this is by doing short-cycled improvements: Observe how the team is doing in their daily work. Use opportunities to change the way of working to improve in small steps. And turn that into a new way of working for the team.

Collaborate with your stakeholders

It may be good for teams to involve their stakeholders to find workable solutions to reduce the pressure and find a sustainable pace that delivers value to them. Teams may have the opinion that stakeholders are causing pressure, which indeed can be the case. But often stakeholders are not aware that they are putting teams under too much pressure. Teams should discuss it with them, make them aware, and together look for solutions to decrease the pressure.

Building trust is important: The stakeholders should trust the teams by assuming that they will do the best they can, and the teams should secure this trust by continuously delivering valuable products. In the longer run, both the teams and the stakeholders will benefit from a sustainable pace by getting more value.

Sustainable improvement

“If you want to deliver more, you should not work harder, but smarter” is a basic thing that didn’t change when agile was coined. Self-assessing how agile you are and doing smaller changes that stick using feedback and learning cycles from agile methods like Scrum are effective ways to implement lasting improvements. You need to invest time and energy, but when properly done, it certainly pays back. It helps you to stop death marches and to work in a sustainable pace.




Posted in Agile Coaching, Agile Development, Agile Management, Agile Teams, Agile Velocity, Extreme Programming, Kanban, Lean | Leave a comment

What’s Down With Agile Documentation?

Guest post by Ellen Gottesdiener and Mary Gorman of EBG Consulting

Recently we worked with an agile team that was building an FDA-regulated medical device. Some team members were worried about how to produce the required verification and validation documents. “What do we do?” they asked us. “We’re not supposed to do documentation in agile.”

That’s a myth. In agile development, the question isn’t whether to document. It’s what kind of documentation to create, and when. Like everything else in agile, those decisions are based on your assessment of value—in this case, the value of the documentation. More documentation is not necessarily better. In fact, the volume of product documentation often is inversely related to its value.

documentation-value-volume-relationshipProcess Versus Product Documentation

You essentially have two types of documentation: process and product documentation. In either case, we urge teams to focus on the documentation’s consumers and look closely at their usage needs. Look at the documentation from the consumer’s perspective, and explore her usability needs to determine the minimum useful and usable documentation.

Process documentation describes the work-in-progress or handover information the stakeholders produce as they discover and deliver the product—the software application, system, or device containing software. Process documentation has less value for a co-located, domain-savvy team than for a team working in a distributed mode in different time zones and with varying degrees of domain expertise. On the other hand, even a co-located team may need process documentation if they are building a regulated product and require evidence of product verification, as in our client’s case.

Product documentation, which conveys information about the product, is an asset that tends to be valuable because it’s used to sell, service, and use the product. Consider that the consumer of your product documentation might be a validation analyst from a regulatory body, a product end user, an installer, a help desk technician, a field staffer, a maintenance programmer, and so on.

For our medical device client, the product documentation included scripts for a demo used to conduct validated learning to test the product idea itself. We took the perspective of the people going on-site to conduct the demos and, as a result, we created a booklet in a slim, tabular format with abbreviated feature descriptions and demo steps. Not only was this booklet “just enough” to document the product, but it was also fast to produce. As a bonus, the delivery team found the format useful for on-boarding new team members.

On Your Mark…

Teams, including the product owners, need to decide when to produce documentation. There are the two meta-patterns: build it incrementally in small bits as you build the software (and when you have the greatest knowledge for creating the documentation), or defer until prior to release (batching documentation as a larger set, created all at once).

When the requirements are fairly well known, documenting early and often makes sense. On the other hand, our medical device client was essentially a start-up. The potentially lifesaving devices were being used experimentally with patients in the hospital, and the requirements were changing as the product itself was being tested. This meant that it would have been wasteful to document what the team was delivering at each iteration. They agreed to wait to document prior to each release throughout the experimental usage of the product (this is roughly equivalent to what a Lean start-up calls “validated learning”). For this team, it made sense to defer documentation.

A good practice is to produce documentation as part of the acceptance criteria for completing a slice of the product, whether it’s a story, feature, or minimum marketable feature—whatever anchor you use to describe the requirements you’re delivering. When you make the necessary and sufficient documentation a part of the acceptance criteria, you’re gaining value for little added effort.

Sliding Along the Documentation Levers

Consider documentation formality and precision and the volatility of your requirements. Do you need documentation that conforms to a predefined format, sign-off, and so on? Will informal documentation good enough? How precise must the documentation be? Who will be consuming the documentation, and to what end? And as with our medical team, documenting too soon would have been wasteful because of the volatility of the requirements; yet, when it was produced, it needed to be precise and formal.

There is no one size fits all. As shown in Figure 2, different product and project situations influence how you will adapt your documentation plans.


The Low-Down on Documentation

Documentation boils down to knowledge transfer. Where possible, document in chunks, and deliver just enough to serve the needs of the specific consumer of the documentation. In that way, you maximize the value you create for the effort you invest.

Don’t forget to leave your comments below!

Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, Inc., 2012.


Posted in Agile Methodologies, Agile Software, Iterative Development, Lean | Leave a comment