I really enjoyed Agile 2010 this year. My workshop, “Feeding the Agile Beast”, and presentation, “Using Lean and Agile to Lead Business Transformation”, were both well received. We found good interest in the Agile Extension to the BABOK. ICAgile was a topic of conversation and for the most part we found an appetite for a solid certification model. I also got to spend time with people I consider to be in my tribes. Just to name a few – note: if I fail to mention someone it is not intentional, just tweet me and I will add you to the appropriate clan(s)

• The Agile Project Manager clan: Mike Cottmeyer, Pat Reed, Michelle Sliger, Brian Bozzuto, including ICAgile visionary Alistair Cockburn
• The Kanban clan: Karl Scotland, Chris Shinkle, Eric Willeke, Mike Cottmeyer, and Brandon Carlson
• The Enterprise Agile clan: Alan Shalloway, Dean Leffingwell, Jim Highsmith, Portia Tung and Mike Cottmeyer
• The Agile Business Analysis clan: Pascal van Cauwenberghe, Shane Hastie, Kevin Brennan, Steve Adoph, Ellen Gottesdiener, and Mary Gorman
• The Agile Testing / Quality Assurance clan: Liz Hendrickson and Lisa Crispin

While some of these people, like myself, may have come from coding backgrounds, none of these people are primarily heads down technical resources. All of these people have spent years – some of us decades – improving our craft. All of these people bring deep experience, passion and knowledge to an area that is deeply necessary to deliver Agile projects to organizations.

It isn’t just about code

I was rankled by comments that came out at the end of the conference from people that I deeply respect that there wasn’t enough technical content at the conference. It wasn’t so much the comments as the context that they were delivered in. The troubling perspective was encapsulated in a post that said, “too much of the content was not technical. It was simple content that could be easily understood and digested.” I have tremendous respect for developers. I used be one – and I was pretty good. But about 15 years ago or so I realized that I could create more value in organization’s by removing the organizational constraints that create difficult environments for developers.

When you get beyond pretty small organizations, just writing code is not enough. In fact, without the capabilities practiced by my Agile Project Management, Kanban, Enterprise Agile, Agile Business Analysis, and Agile Testing clans, you can’t deliver value to customers. And the craft of being great at these in organizations is just as challenging, evolving, and important as any line of code anyone ever wrote.

Excuse me, but are you kidding me

Does anyone really think that the work of these clans is easily understood and digested? Getting organization’s to focus on strategy, then translate the strategy into work that can be developed, then coordinate that development across functions, then ensuring that what is needed is what is delivered, and then implementing the changes necessary to ensure the business receives value is not easily understood and digested. As a matter of fact, I think it is at least as interesting and difficult a problem as writing good code. And I think in the context of leveraging Agile software development in organization’s it is just as valuable and not as well understood.

My Job is Hard, Yours is Easy

A common bias in organization’s is the fundamental attribution error. This is also known as the self-serving bias. This manifests itself when people attribute different circumstances to their experience than they do to the experience of others. I see this all the time when coaching organization’s.  People devalue the contribution of others and overvalue their contribution. This attitude leads to bunkering down in silo’s, organizational conflict, and obstacles to improvement and flow of value.

I have written code in an organization. It is hard. But I have also been responsible for business analysis, project and program management, quality assurance, process improvements, training, organizational design, and change management aspects of projects. All of these are important, all of them are hard. Delivering value for the business requires cadence and flow among these disciplines. As you are making assessments of how simple and easily digestible non-technical content is remember this tendency. Just saying, “My job is hard, and yours is easy”, doesn’t make this assertion true. And it results in value destroying behavior.

Over the last month I have presented or participated in several user groups and conferences. There was Southern Fried Agile in Charlotte, Agile 2010 in Orlando, a PMI Atlanta professional growth event, meetings of Agile Atlanta and the Atlanta Scrum Meet-up, and Product Camp Atlanta (not surprisingly in Atlanta). These conferences give me an opportunity to meet with people doing, or attempting to do agile in the enterprise. There are a lot of common patterns that I am seeing. One of the most common patterns is that we are doing QA all wrong in most companies.

Imagine if someone approached you up front and said “I have an idea. Let’s design our product development system like this. First, development is going to take in less then precise requirements. Then development is going to build something from the requirements. Then we are going to deliver this to a separate group that will then figure out how to test it for accuracy. Then that team will test it. When the product doesn’t pass the test we just defined we will return it to development for them to fix it.”   Is this the way that your test organization operates with your development organization? Does the relationship between QA and development seem reasonable? Why are challenges between QA and development so prevalent in our organizations?

We Don’t Understand Quality Assurance

Quality Assurance and Quality Control are different things. We have Quality Assurance organizations – but most often they are involved in Quality Control control activities.

Quality Control: Find defects. These activities are focused on validating the deliverable. They are performed after the product (or some aspect of the product) has been developed. It also enforces fit to specification. This protects production and our customers from getting defective deliverables that do not meet the specification. But when done on a completed product it isn’t doesn’t enable flow and defects found downstream of the deliverable result in rework in development.

Quality Assurance: Prevent defects. These activities are focused on the process used to create the deliverable. They are performed as the product is being developed. So, Quality Assurance should be helping us improve our processes so we don’t create defects in the first place. A key point to this is that creating a common understanding of the specification and how we will validate it up front is really important to eliminating defects.

If your Quality Assurance activities are primarily focused on finding defects and ensuring fit to requirements after the fact then your QA group is primarily doing Quality Control. Getting QA involved in improving the specification communication process through is a good place to start. A specific technique might be exploring communicating acceptance criteria to development with the same examples QA will use to perform acceptance tests.

We Don’t Understand the Cost of Rework

Finding defects after the product has been delivered ensures that you will generate rework. Rework from failed QA tests are extremely expensive to flow. Sending work back into development interrupts work in process. This has a dramatic effect on cycle time across the system – which results in increased cost of every item in the system.

After the fact testing is also typically done in batches when a release or iteration is delivered to QA from development. Defects uncovered in these batches create bottlenecks at development.  Just like when traffic backs up on the highway, bottlenecks in product development result in a long term cost to the overall system.

We can dramatically reduce the cost and adaptability of the system by reducing this rework. One way to address this defect bottleneck is to perform quality control frequently – not in batches. Another way is to prevent defects through effective quality assurance in specification understanding and in development. This will reduce the number of defects produced that escape to Quality Control.

We Have Designed the Product Development System Wrong

We used to teach that there needed to be a separation of testing and development. Having them both report to the same person was like having the person that wrote the checks in accounting also reconcile the check book. It was too easy to cheat.  We created QA teams that were completely separate from development – and that reported up through different management structures. I was talking to the director of development at a company where the QA and development chains of command meet at the CEO. When you design the organization to QA and development in different silo’s you will make it very difficult to have effective Quality Assurance involvement. You will ensure Quality Control behavior.

This separation made sense at one point (I think). It doesn’t make as much sense today – especially as the resulting silos result in slower delivery times and increased costs. What has changed in the last 10 years is:

• the cost of setting up testing environments is much lower
• our ability to rapidly and frequently produce testable deliverables for these environments is much greater, and
• our ability to perform acceptance, integration, regression, performance, load, and stress testing frequently is enhanced.

Quality Assurance needs to be part of the development team and process. We need to change our thinking around this.

So we need to integrate Quality Assurance very early in the process. We need to ensure early arrival of acceptance test examples to development. But, we still need independent test teams when we are doing large or complex projects that require integration of many team’s outputs. Independent test teams can be running parallel testing or test-immediately-after delivery. When they are getting high quality components, they focus on user experience, performance, load, and stress testing.  Move everything you can into the development teams (enhanced with quality assurance) so you can produce low defect escape rates. Then eliminate the defect bottleneck and increases in cycle time by treating most of the defects at the independent test team as new specifications to development.

We have the Wrong Expectations

We Expect Perfection – Not Improved Value

Our QA organizations tend to be focused on defect identification and perfection in delivery. The focus of QA, and everyone in the organization, needs to be on producing value-add and delighting the customer – not on defect-free code. This doesn’t mean that defects are okay – but every application has some defect or limitation. Unless you are building aircraft navigation systems or other critical systems you are going to deliver some defects. Make sure the defects don’t block business value – but there is a point where it is more important to the customers and business to deliver value.

We Expect Local Optimization – Not Flow

Rather than perfecting Quality Control, QA can add a lot of value helping the organization enhance the flow of value through the entire product development system. Delivering a unit of value requires analysis, development and testing. There is no value delivered internally. The local optimization problem of improving one area at the expense of another is not useful. Crossing the boundaries between analysis, development, and testing is needed to optimize flow of value. The various teams need to figure out how to do it together – not just improve their area.

Expect our Current Constraints to be Permanent

Organizations labor under the belief that their constraints are fixed. Find a way to break down the barriers that lead to your constraints. Don’t accept the current constraints as permanent. Increase thinking at the system level to find ways to improve the product development process.

We Don’t Use the Tools Available to Us

There is an impressive amount of automation and related techniques available at very low cost to help build the QA environment that allows for fast feedback, building on progressively tested levels, and improving opportunities for frequent testing. Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests. This provides a basis for validation and refactoring. Test driven development or test  just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation. This helps everyone work on a stable build and ensures that no one gets way off track. There are automated tools for acceptance testing and some levels of UI testing. When the tools are combined you can build a very powerful regression testing environment that can also rapidly perform performance, load, and stress testing.

The lack of general adoption of these tools probably has multiple roots. Sometimes it can be difficult to leverage all of them with legacy systems. They require new skill sets and generate new artifacts that have to be maintained. On the surface, they automate tests that are currently performed by QA groups and so their is fear and organizational threat. But some subset of these tools should be broadly adopted by each team. QA teams can focus their efforts on valued added items like Exploratory Usability Testing and Release Validation.

Summary

Most organizations are doing QA all wrong. It is time to start doing it right, the cost of low quality in dollars, time, customer satisfaction, and the engagement of employees depends on it.

• Switch their primary focus to Quality Assurance
• Help the organization reduce re-work
• Integrate QA and QC with analysis and the development organization and work to eliminate defects – not just identify themF
• Enable value, flow, and ongoing improvement
• Leverage proven tools and techniques across the Product Development Organization to increase the value delivered

The status quo is not sufficient to meet the needs of most organizations. While not all of these approaches will be right for every situation, the rate of adoption is too low to be justified. There is far too much latent value being tied up in organizations because we are doing QA all wrong.. What obstacles do you see in your organizations?

Alistair Cockburn, in the Oath of Non-Allegiance, has issued a call to action for the software development community to stop bickering and calling out contending methodologies. He has called for “discussion about whether an idea (agile plan-driven impure whatever) works well in the conditions of the moment.” As someone who has earned his PMP, CSM , received certificates from the Lean Enterprise Institute, and who completed David Anderson’s Kanban Coaching workshop – I have had the opportunity to see this bickering up close. I have occasionally even as the target of it.  Here is Alistair’s call to action:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

This is becoming an increasing familiar theme. We see it in Laura Brandeburg’s Business Analyst Manifesto. It is expressed by by Liz Keogh, Jean Tabaka and Eric Willeke in “A Community of Thinkers”. I am involved in a PMI Agile team where we are trying to make sense out of the benefits associated with bringing together the PMI Body’s of Knowledge (Portfolio, Program, and Project) in the context of Agile. I am working with the IIBA’s Agile Business Analyst core team to express the Business Analysis Body of Knowledge in an Agile fashion. I also participate in various Yahoo and Google groups where we are working at having these kinds of conversations involving Kanban and Lean.

These teams and discussion groups bring together practioners and thought leaders from various communities working to understand and to share. Sometimes the discussions get heated. You have a lot of successful, intelligent people sharing their experiences and trying to make sense out of their successes while simultaneously trying to expand their world view. The awesome thing is that there is a lot of learning and connecting going on in these communities.

You may want to protect your turf -  but this is the future. The tools and resources that support software development have improved orders of magnitudes in the last two decades. It’s crazy to believe we don’t have a long way to go to figure out the best ways to deliver software – especially at the enterprise.  Tom Peters quotes General Eric Shinseki, Chief of Staff, U.S. Army – “If you don’t like change, you’re going to like irrelevance even less.” I choose to join the community who is looking for ways to honor the fundamental premise of the Agile Manifesto – We are uncovering better ways of developing software by doing it and helping others do it.

When I start talking about speeding up work and reducing variability in lead time to a group of software developers, the initial reaction is often, “We can’t do that. This is knowledge work. You can’t reduce variability in the work itself. The hard stuff just takes longer and the easy stuff is shorter.” This is often followed by, “You don’t want to take the creativity out of our work”, or “You can’t treat us like machines.” So, it is important to point out up front that I agree with all of these statements. So, why would you want to shorten and reduce variability in lead times and how can you reduce lead time and variability without inhibiting the creativity required to do the work.

Why Reduce Variability and Lead Times?

Lead time is the average time it takes for one work item to go through the entire process – from start to finish – including time waiting and time consumed by rework. In most cases, unless you are intentionally managing your lead time, you will have lead times that are highly variable and probably excessively long. Why would you want to reduce lead time duration or variability?

Increase Predictability

Reducing variability in lead time will allow you to consistently know and commit when something can be delivered. Delivering consistently will help to increase the trust within the system. One of the very beneficial outcomes from increasing trust in the system is that it leads to a dramatic reduction in expediting. Once the system becomes predictable, the business may be able to make new offers to customers based on the high level of predictability.

Faster Feedback

Reducing lead time duration results in faster feedback. Faster feedback can result in increased quality. There are number of reasons for this.  Less work is done based on work items that require rework. Shorter cycles result in better fit since the feedback can be gathered and applied frequently. Also, faster feedback means that the team can minimize the work required to meet the objectives.

Flexibility and Responsiveness

Shorter lead times and trust based on predictability increases options for flexibility. You can delay some decisions until very late – deciding just before you pull into the system the details of solution. Expediting now means putting an item into the queue as the next item. Also, you can make new promises to customers based on this increased level of flexibility and responsiveness.

Wimbledon

Okay, so there are some benefits to reducing variability and duration in lead time. But, how can you reduce lead time duration and variability without inhibiting the creativity required to do the work.

Wimbledon provides some insight into this. At Wimbledon, the games take as long as they take. The number of games played is determined up front – they have to play all the games. There are Men’s and Women’s Singles, Men’s and Women’s Doubles, Mixed Double’s and many players participate in multiple events. Games can’t play in darkness (except on center court). Games can’t be played in the rain. Players can’t overlap doubles with mixed doubles or with singles play.

Wimbledon has been played 142 times and the finals have been delivered late twice. That’s pretty amazing given the wide level of variation in the length of games and the other constraints that must be addressed.

How does Wimbledon accomplish this? They have policies that impact the timing of the games – for the most part without impacting the way the game is played.  For example:

• A tie breaker in the first four sets. This tie breaker is open ended as it requires a player to win by two points – only the final set requires winning by two games.
• Games can start earlier on a day if games are behind.
• The gap between games can be shortened to get in additional play each day.
• The tournament director may have players warm up on other courts to bring games closer together.
• Additional courts can be opened for play as long as it doesn’t create a conflict across events.
• They minimize the impact of rain by covering courts during rain delays.
• They have added lights and a roof over Center Court to allow games to run longer and during rain.

Combined, these policies allow the games to take as long as they take – while allowing the tournament to deliver a fixed number of games in a fixed time.

Reducing Variability and Lead Time in Software Development

Just as software development isn’t manufacturing, it isn’t tennis either. What the example shows is that lead time duration and variability can be reduced without changing restricting the way the game is played and with minimal impact on the rules of the game. This concept can be translated to software development.

Reduce Waiting

How much time is a work item actually actively being worked on? If you pay careful attention to flow of work through your system you will likely find that a typical work item spends more time waiting to be worked on then being worked on. It is not unusual to find 5-10x wait time to work time. With wait time being a large portion of lead time, reducing wait time will have a significant impact on reducing lead time. Limiting WIP and pulling work are key techniques to reducing waiting.

Rework: Or Failure Load

Another big cost on lead time – and typically a huge impact on variability – is rework. Rework is the result of a defect that unintentionally escapes from one work queue and is identified in another. The result is that work moves backwards through the system – increasing lead time not just of the current work item, but of other work items. Leveraging techniques that minimize or eliminate rework are important to reducing variability and duration of lead time. Test driven development, automated test frameworks, continuous integration, and coding standards are methods of reducing or eliminating rework. Investing into reducing rework reduces lead time duration and variability.

Making Work Ready

One cause of variability and extended lead times is when work is pulled that isn’t ready to be worked on. This can happen when dependent work items aren’t prepared, required external resources aren’t standing by, or when the outcome (not the how) is not well understood. Making work ready requires understanding and aligning dependent work items. Minimizing dependencies during design helps reduce negative impact. Using scheduling methods like Kanban to schedule external (non-instantly available) performers helps coordination of external performers so work can continue to flow.  Feature injection, where outcomes are defined during analysis and presented as testable examples is an excellent method of understanding and clearly communicating the expected outcome. Extra effort put into making work ready often results in reduced lead time.

Relatively Small and Similar Size Work

Large work items – or high variability in size and complexity of work items will result in higher variability and duration of work items. Breaking work into relative small and similar size work is a good method for reducing variability and duration of lead time. Breaking solutions down into small work can also result in improved design, higher testability, and more flexibility in the solution. This doesn’t mean that work should be broken down arbitrarily. Work should be broken down to the smallest level that is reasonable and no smaller.

Swarming

Swarming is when team members work together on work items to move them forward faster. Sometimes this is increasing the number of developers doing development – often it involves having generalists work in areas outside of their specialization. You will want to have the performers work on work items that are in risk of being late against their  SLA.

Tracking The Data

To track lead time, track the entered day and exit day from the Kanban. Do this by having the performer who pulls the card into the first queue write the date it was pulled. When it is moved to the last queue, write that date on the card. Lead time will be the difference between the two days.

To track waiting time, put a blue dot on the card for each day it sits waiting to be pulled into any queue. Count the dots when you pull the card off the board to see how many of the lead time days were waiting days.

To track defect days, you can create a defect card when a defect in a piece of work is identified downstream from its source. Move the card back to the source location and move it forward through the system until it catches up with its card. Put the start date on the card when it is created and the end date on the card when it catches up with the original card. Defect days is the difference between the start date and the end date of the defect card. Track the cumulative defect days on the work item card.

Track blocked days when the card is blocked. This can be done by putting a red dot on the card for each day it is  blocked.

Reducing Lead Time Duration and Variability in Kanban

So, by tracking data related to Lead Time, waiting time, defect time, and blocked time, the team can identify where to act to reduce the lead time duration and variability. Then, identify and leverage strategies like reducing waiting, reducing rework, making work ready, defining small size work, and swarming, to improve lead time. Tracking causes of defects and blockages can help make decisions to focus these strategies appropriately. Reducing lead time duration and variability will result in increased predictability, faster feedback, improved flexibility and responsiveness.

In my last couple of posts I have been talking about Measuring and Managing Flow in your Kanban system. With some simple tracking, you will pretty rapidly have an understanding of Classes of Service and how to produce reliable estimates using Kanban. One of the big wins in Kanban is to take this understanding and have the team collaborate with the external stakeholders and business owners to agree on the performance goals. The performance goals are built on the assumption of a long term relationship between the team and the external stakeholders as well as team commitment to system level performance.

The performance goals are articulated as Service Level Agreements (SLAs). These SLA’s define cycle time targets and WIP limits. For example, a cycle time target might be something like – we will deliver small sized Standard items in 11 days 80% of the time; the WIP limits for Standard items is 2 in design, 4 in development, and 4 in acceptance. You can establish distinct SLA’s for each class of service and even for different sizes of work.

Four Keys to Negotiating SLAs

It is not sufficient for management to establish SLAs and then communicate them to the team and the stakeholders. The SLAs need to be negotiated in a collaborative way. This builds understanding and interest in the system on the part of all stakeholders. This understanding and interest, paired with the team successfully meeting the performance goals, results in establishing / increasing trust in the team. There are four keys to negotiating SLAs.

1. Include both upstream and downstream stakeholders in the discussion to form the agreement. Their understanding of the system and their participation in the negotiation helps ensure the stakeholders will be willing to uphold their end of the bargain in prioritization and WIP limits. It also enables collaborative behavior later, when the system is put under stress.

2. Involve the team in defining the the classes of service and negotiating the SLAs. This will increase their commitment, which is a key to meeting the SLA’s. Additionally, their participation in defining the SLA’s, the supporting policies, and their decision making in applying the policies results in increased engagement on the part of the team members.

3. Make promises the team can keep. Use data gathered from the historical performance of the team. Understand the distribution of outcomes and apply standard deviations to make statistically appropriate commitments. Don’t get pushed into hopeful SLAs. Support the negotiations with data and be sure you don’t allow the team to over-commit.

4. Balance demand to your capacity. As you set WIP limits, focus on maintaining the lowest possible limits. Also it is healthy to have a mix of classes of service active. This helps to optimize value and distribute risk.  Don’t over-commit the amount of work that will be in progress at any one time. It isn’t about starting work – it is about finishing it. Remember, the lower the WIP the shorter the cycle time.

Cost of Delay

Everything is not of equal priority.  It isn’t necessary or helpful to expect perfect estimates on stochastic work (work types with a lot of variability) like software development. Human nature will cause the system to underperform if all types of work require a high level of precision in time commitment. Read the section on Decoupling Planning and Scheduling in Kanban and When Will This be Done? to understand this phenomenon. Use the concept of the Cost of Delay to establish effective SLAs on various classes of service. Cost of Delay is the cost that will be incurred when a work item is delivered later than promised. Understand the Cost of Delay of each Class of Service and set the SLA appropriately.

For example, a compliance requirement that has to be delivered on a specific date or the company will incur a large fine has a high cost of delay. You need to use your the Mean + 3 Standard Deviations for that work item type when you set the SLA. If you understand the probability of a series of tasks that need to be delivered by a certain date, each individual task won’t have as high of a cost of delay. You should probably set an SLA that says the work item type will be delivered in (Mean + 1 Standard Deviation) days about 80% of the time. If you have work that needs to be completed – but new value isn’t released when the work is completed – that item has a low cost of delay. Don’t set a time based SLA – but limit the WIP capacity of this work. Use the concept of Cost of Delay to set the most flexible SLA possible. This will improve the flexibility in your Kanban system and increase the ability to deliver value.

Managing Policy to Achieve the SLA

Once your SLA has been established, the Class of Service policies need to be shaped to ensure the SLA is met. This includes the impact this class of service has on WIP limits, the prioritization and swarming agreement for the class of service, and estimation requirements for the class of service.

As you are performing the work determine early if the SLA is in jeopardy. The team should work hard to arrange their focus to meet the SLA. This will mean making decisions that give them the best chance to  succeed without jeopardizing the SLA for other work items. When an SLA is in jeopardy, the team should communicate this to business stakeholders early. If the SLA is critical the business stakeholder may decide to elevate the Class of Service.

Continue to measure your performance against the SLA. During your operations reviews – look for opportunities to improve performance against the SLA. Over time, you may look for ways to reduce cycle time to increase the performance of the system.

Benefits of Negotiating and Managing SLAs

Using metrics, classes of service, and service level agreements your team can learn to make promises they can keep. Making and keeping promises increases trust in the system and reduces pressure from the stakeholders to demand artificially inflated SLAs. Negotiating the SLAs effectively increases the commitment and level of engagement of the team. It also engages the stakeholders in the success of the system. Using cost of delay in the negotiations helps set appropriate SLAs that optimize value while maintaining flexibility in the system. Thoughtfully defining your policies gives the team the best chance to successfully deliver on the SLAs. Establishing and communicating the policies create a set of simple rules the team can follow to deal effectively with the high level of variability in the work moving through the system. Using Kanban, capturing a few simple metrics, and negotiating some simple rules around cycle time and WIP commitments can dramatically improve the reliability and trust experienced by the stakeholders while improving the commitment and engagement of team members.

One of the Yahoo groups I belong to, pmiagile yahoo group, is exploring whether there is any synergy between Agile and the PMBOK. Its is an interesting yet somewhat frustrating discussion. I think we should try to avoid platitudes and clichés. I understand that there are many project managers that have interacted with development teams in ways that were destructive. I understand there have been agile teams that were not responsible in their approach to development. This discussion should not about how individuals or organizations have behaved badly. It is about looking at an established body of knowledge, the PMBOK, to see if there is anything worth learning from there that could help us in uncovering better ways of developing software by doing it and helping others do it. Todd Little recently posted:

“It would be more productive to look at what problems exist that current agile implementations do not support well. Dennis is suggesting that there are gaps that agile does not answer. I’ll buy that there may be some gaps. What are those gaps? What are the user problems that need to be solved? What are the user stories and acceptance tests for those problems? Maybe then we can look at the PMBOK as a potential source of solutions to users that have those problems.”

I believe it is pretty important that the participants in this discussion have a pretty clear understanding of both Agile and the PMBOK if they are going to offer up opinions on one or the other. I have been involved in software development since 1985 (RPG2/3/400, C++, Perl, Java, C#). By the mid 1990’s I was leading development teams following an Incremental and Iterative development process. I purchased my version of Eliyahu Goldratt’s the Goal in 1994 and Critical Chain when it came out in 1997. I was busy reading and applying Larry Constantine’s Peopleware,  James Highsmith’s Adaptive Software Development, Kent Beck’s eXtreme Programming, and Alistair Cockburn’s Crystal methodology before I knew what the Agile movement was. I was explicitly applying value stream concepts, visualization, and limited WIP before 2000. I have always mixed and matched based on what made sense on my current project. I have actively been coaching and applying these ideas for over 15 years. I claim Agile chops.

I earned my PMP from PMI in 1998. I have produced hundreds of project artifacts including project plans, charters, and risk plans.  I was the Deputy Project Manager on the development of PMI’s Organizational Project Management Maturity Model (OPM3®). I have actually read through my PMBOK 4th Edition in detail. I am qualified to speak about the PMBOK.

The PMBOK

Let’s talk about the PMBOK for a few minutes. First off, the PMBOK describes good practices in project management that work for most companies most of the time. The PMBOK Guide also provides and promotes a common vocabulary within the project management profession for discussing, writing, and applying project management concepts. The PMBOK points out that the standard is neither complete nor all-inclusive. Additionally, the standard is a guide rather than a methodology. One can use different methodologies and tools to implement this project management framework. The PMBOK is not specific to software development – this language and this guide support all types of projects.

How The PMBOK is consistent with Agile

PMBOK supports self organizing. It is up to the organization and the team to determine what is appropriate for any given project.

PMBOK supports sprints and/or real-time planning. PMBOK doesn’t require big up front planning and then rigorous adherence to plan. PMBOK talks about iterations and progressive elaboration. Progressive elaboration is continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and therefore producing more more accurate and complete plans that result from the successive iterations of planning.

PMBOK supports continuous improvement. This is an iterative means of improving the quality of all processes, reduces waste, eliminates activities that do not add value, allows processes to operate at increasing levels of efficiency and effectiveness.

PMBOK supports overall adaptation of the product and the organizational processes. The Risk Management Section of the PMBOK calls for a continuous approach to identifying, monitoring and responding to risk. Technical Risks (including Requirements Risk and Quality Risk, External Risks (including Market and Customer Risk), Organizational Risks, and Project Management Risks.

How the PMBOK complements Agile

In many cases, software development takes place in a bigger context then just the software development team. This bigger complex can be messy, with lots of activities that have to be coordinated to deliver value to the customer. Here is a peak into that messy context.

In front of development this includes activities like market research, strategic planning, sales forecasts, budget forecasts, and making investment decisions.

During development activities need to be coordinated with development including procurement, vendor contracts, compliance research and documentation, legal evaluations, intellectual property protection, developing and implementing security, privacy and data protection controls, and designing changes to business process.

For each release of software, activities outside of development include, establishing sales and marketing readiness, updating customer service policies and procedures, updating business resilience procedures, updating impacted training and implementation procedures, updating customer service levels, re-aligning reward and recognition programs, and updating internal IT service level agreements. Then there are often launch activities around customer communication and product promotions and ICT coordination including licensing and production operations.

The importance of these activities will vary between contexts – but these are all real activities that I have had to handle on software development projects. In Agile, these are hidden behind the Production Owner or Onsite Customer abstractions. But in the process of delivering value to an organization or new product to a customer, these may exist, need to be coordinated, and aren’t particularly interesting to the software development team. This type of coordination needs to be done in a way that enables the Agile teams – to achieve the goal of delivery of value to the customer.

Barriers to Synergy

From the Agile perspective, barriers to synergy arise from the sense that PM’s will meddle in the performance of the team. This is based on historical experience and potentially a lack of understanding of real organizational constraints that result in obstacles for the team. The PM becomes the representative for these unreasonable constraints in a “shoot the messenger” fashion. The other big barrier to synergy is the prevalence of language in the PMBOK that is contrary to Agile values and principles. Make no mistake, from the definition of the project manager, through the use of words like directs, controls, and manages the language is an obstacle.

From the Project Management perspective, barriers to synergy arise from the primacy of developers and the development team in Agile talk. Project Managers also perceive the agile teams have a limited view of what “the product” is and what it takes to provide value to the customer. The project manager lives in that messy place behind the overly simplistic abstraction of the Product Owner.

How Do We Address These Barriers

Acknowledge that Agile and the PMBOK come from a different mindsets

Not regarding iterative and incremental development but from values and principles. We need to recognize this gap and start the discussion from the perspective that we are building on Agile values and principles.

Recognize that delivering value to the customer is often beyond the scope of the development team

The product is bigger than development. There is work to be done that isn’t best done by the development team. This becomes a bigger and more important deal when you are working in companies of any scale.

Acknowledge the Limitations of the Product Owner Abstraction Layer

Look back at How the PMBOK Complements Agile. That messy list of activities point out how big the set of issues are that the Product Owner is responsible for.

Distinguish between Project Management Practices and the Project Manager Role

The PMBOK is the Guide to the Project Management Body of Knowledge. It isn’t about project managers. In a small organization, with a limited number of products, with intimate access to customers, lots of automation, and a limited requirements for supporting infrastructure, the project management activities can likely be handled by a couple of people with very little coordination effort required. But in organizations of scale, the coordination effort will benefit from someone focusing on coordination. In both cases, the project management practices should be addressed – sometimes with a role and sometimes without.

Can Agile learn anything from the PMBoK?

Yes, by addressing the barriers. Start with Agile principles and values, look at the larger value stream from the customers perspective, understand the limitations of the product owner abstraction, and creating clarity about roles and authority regarding project management practices. Use the PMBoK as a placeholder for conversation about the Knowledge Areas and the purposes behind the tasks. As the PBMoK points out. the organization and/or team should decide what is appropriate for them for each project.

Here’s a starting point for the Ball in Court discussions

The conversation is about decisions rights and levels of authority. I have listed the PMBOK knowledge areas and some potential separation of authority as a starting point. I want to be clear about my perspective on this conversation. In a doubles tennis, everyone on the same side of the net is on the same team. Sometimes, the ball is in one person’s court and sometimes it is in the others person’s court. But when playing tennis the partners play the game to help set each other up for success and may back each other up if possible. I view these authority discussions as ball in court discussions.

Additionally, this starting point is going to be wrong for your organization. But making perspectives explicit helps start the conversation. This initial view is based on a discussion on the pmiagile board that I had with Ron Jeffries. I am not  claiming that Ron has endorsed this approach or these distinctions. What is important is that Ron Jeffries and Todd Little are willing to explore this line of thinking.

PMBOK Knowledge Area [potential authority]

Project Integration [development team inside development, project manager outside development]
Project Scope [product owner, project manager facilitation]
Project Time [development team]
Project Cost [product owner, project manager]
Project Quality [the development team, project manager facilitation]
Project Human Resource [project manager]
Project Communications [development team inside the team, project manager outside development]
Project Risk [product owner, development team, project manager]
Project Procurement Management [project manager]

A question that comes up a lot in Kanban is, “How can I know when this feature will be done?”.  First off, it is important to understand what makes estimating unpredictable – and then what steps Kanban presents to address this. Estimates are unreliable because the inherent variability work is compounded by the lack of flow in most teams and destructive behavior caused by fixed point estimates. Kanban, through a few simple techniques, a little bit of math, and the decoupling of planning and scheduling will give you the ability establish accurate estimates with minimal effort.

Cycle Time

The key metric we will use for estimating is Cycle Time. Cycle Time, in most Kanban and Lean contexts, is the time between when the team starts working on an item and when the item is delivered. Cycle Time is what is interesting to managing (whether managed by management or self managed) the team. This metric becomes a key management metric to reduce variability in the system, make reliable commitments, and provide insight into whether improvement efforts are delivering expected results. We are going to talk about using Cycle Time to make reliable Due Date Performance commitments.

Cycle Time is easy to capture. When a card is pulled into the first work queue – enter the date on the card next to Start. When the card is moved to the last queue, enter the date on the card next to Finish. Cycle time is Finish Date – Start Date. At the end of the week, when you pull cards off the board, capture the cycle time for each card into a spreadsheet or whatever tool you are using for tracking.

Distribution Curves

What you will most likely find after you have captured a little data is that lead times fall in a distribution that is skewed to the right. This shows the variability in the work that you perform – there is some absolute limit on the shortest time the work can take – but there are a lot of ways it takes longer. Take the Cycle Time data and find the Mean and the Standard Deviation. Then set the expectation to the Mean + 1 Standard Deviation.

In this chart the work items are taking from 5 to 15 days. The Mean is 8.6 days and the Standard Deviation is 2 days. You can set a Due Date expectation 11 days and and be sure that you will hit this date about 80% of the time without changing anything you do. So that’s the policy, we will deliver work within 11 days with an 80% due date performance expectation. Over time, we hope to be able to improve the 80% and the 11 days.

There are a few nice things about this Cycle Time number. It takes a lot of complexity into account. Your Cycle Time calculation will have already incorporated the impact of rework while in the system, the typical impact of disruption from expediting, and the impact of waiting in the ready/done queues.

What about the 20% that will be late? There are a couple of things you can do. First, you will begin to be able to identify early which stories are going to be late. These will be ones that are more complex or end up with lots of rework. You can address these with capacity, prioritizing and/or communication to the customer. Addressing it with capacity means swarming on the task to bring it in closer to the due date. Addressing it with prioritizing might mean moving the card up higher in the stack then one that is likely to be done early. The cost of swarming and prioritizing means that another card might be delayed – but if you are thoughtful about prioritizing and swarming you won’t cause delay outside of the Due Date promise. For some cards, you will communicate to the customer that the card will exceed the due date performance expectation – while not optimal this is within your delivery commitment as long as it doesn’t happen more than 20% of the time.

T-Shirt Sizing

Many teams are dealing with work of various sizes. If you do a frequency analysis of your data you will probably see clusters of data. In the picture below we have three clusters.  Rather than spending significant time in complex assessments to support estimating, the team can rapidly assign tasks into these clusters. We call this T-Shirt size estimating. Cluster like work into XS, S, M, L, and XL. You may decide that you don’t accept XL tasks without decomposition or require breaking them down. Then determine estimates for each size based on Mean + 1 Standard Deviation for each of the clusters. You can determine some simple process for assigning work into one of the T-Shirt sizes.

This won’t give you perfect estimates. Perfect estimates are almost impossible to determine. Additionally, Cycle Time Variability is probably impacted more by variation in the system like waiting and rework then anything else. It is impossible to determine the impact of the system by more deeply analyzing the task. With T-Shirt sizing and Cycle Time, you can get as accurate results in minutes as could you do in months. While not perfectly accurate – it’s as meaningful as anything you can do.

Schedule a Release

One of the interesting concepts in statistics is the concept of Regression Toward the Mean. What this means is that when you bring a lot of estimates together, you are likely to  have a final result where the average over time is close to the historical average. One example of this is driving to work. If you were asked to plan how long it would take to get to every stoplight on the way to work exactly, this would be impossible. But you have a pretty good idea what time you need to leave home each day to arrive at work at the right time.

Because of regression toward the mean and the actions we can take based on the visibility Kanban provides us, using T-Shirt sizes and cycle time to schedule a release will result in a pretty accurate estimate – and the cumulative estimate will be more precise than any individual estimate.

Decouple Planning and Scheduling

From a human nature standpoint, data can be a dangerous thing. The way we often couple planning with scheduling of resources is an example of this. With the way we have historically run projects, we put all the estimates together and then hold the team accountable to each individual estimate. This is unreasonable because we know that the estimate represents a range of possible outcomes. Five problems arise when we tightly couple estimating and scheduling of the work.

1. Bludgeoning: If we produce point estimates when outcomes are probabilistic – and then hold people accountable to hitting each individual estimate we are going get value destroying behavior. Bludgeoning people when they don’t hit 80% estimates means we are going to get 95% estimates. In most cases, the 95% estimate is about twice the duration of the likely outcome. This puts a lot of padding into the system.

2. Sandbagging: Another destructive management behavior when we couple planning and scheduling is accusing the team of sandbagging. This happens when the team delivers something in half the time of the estimate. Management will often want to go back and cut the “excessive padding” out of the rest of the estimates. First off, management drove the sandbagging behavior. Secondly, we know statistically that most work should be delivered earlier than an 80% or 95% estimate. The team learns not to deliver early because management charges them with sandbagging. So teams don’t deliver early and consume time that, on average, we need to accrue to the project.

3. Parkinson’s Law: Typical management techniques result in the team delaying delivery until the last moment. One outcome is that work expands so as to fill the time available for its completion. This is problematic because it leads to gold-plating of work that increases downstream efforts. It also ensure we don’t deliver a task that could be delivered early doesn’t get delivered early.

4. School boy Syndrome: The other behavior spawned by this is that the team doesn’t start as soon as possible because they wait until they think they need to start to deliver. This often means the team will start in time to deliver on the likely outcome – but deliver late when the task turns out to be more complicated or runs into a delay.

5. Murphy’s Law: If something can go wrong it will. We know that some work will take much longer than other work. This is Murphy’s Law. The behavior that arises from coupling planning to scheduling combined with Murphy’s Law ensures that projects will be delivered late – even against a 95% estimate. It is said that the losses accumulate and the gains are lost.

Kanban Helps Reliably Determine When Work Will Be Done

We can’t precisely predict how long work will take. Estimates represent a wide range of possible outcomes. In traditional project management, we ask for unreasonable estimates and then manage the work in such a way that we guarantee the project will be delivered late. Additionally, late delivery of work is as often driven by behavior that inhibits flow as the uncertainty around the work effort.

In Kanban we use Cycle Time data derived from the performance of the system to plan when work will be done. Then we decouple this planning effort from work scheduling – using the Kanban board to focus the team on flow. Kanban provides the team opportunities to make capacity and prioritization decisions that help address the innate variability of the work being performed to deliver within the policy. Cycle Time estimates, combined with limited WIP and a focus on flow, helps Kanban helps deliver predictable outcomes.

Kanban and conversations seem to be a hot topic recently. Jared Richardson with Pillar Technology had a nice post last week to remind us that a key to Agile is individuals and interactions over processes and tools. The next day, I had a twitter conversation with @paul_boos about how Kanban can facilitate these conversations. Pascal Pinck published a nice post that summarized our email exchange on the role that Kanban plays in influencing conversations and relational flow. Finally, @ronjeffries had this tweet on Friday,

“@alshalloway almost all well-coached "agile style" methods work consistently. at base i think it’s because [wise] inspect and adapt works.”

This recent flurry of activity confirms the core basis of my focus on Project Conversations for the last decade – Getting better at software product development is about getting better at the right conversations.

What conversations?

Knowledge work projects require inspect and adapt by everyone on the team. And not just inspect and adapt on the software we are delivering. We have to Inspect and adapt around every aspect of the project like; the technology we are are applying, the processes we use to perform the work, what our customers want, how people work together, and how we gain a better understanding of the delivery of business value.

Inspect and adapt takes place through conversation. Conversation is the use of language to exchange thoughts, ideas, and information. Knowledge work projects, like software product development, are performed through conversation. The three primary things we need to converse about to accomplish a project are Understanding, Forming, and Doing.

Understanding conversations include:

• conversations about the purpose, goals and targets of the project;
• sharing and resolving concerns about the nature and direction of the project;
• investigating the background, risks, and current conditions surrounding the project;
• and analysis of ways to achieve the goals and targets. 

Forming conversations include:

• establishing or ascertaining the enrollment of stakeholders on the project;
• exploring and evolving situation specific solutions to achieve the goals of the project;
• planning the activities and responsibilities required to implement the solutions;
• and coordinating the flow of activities.

Doing conversations include:

• assuring the team or promising to stakeholders to work toward accomplishing something;
• communicating the status of our ability to meet the promises of our work;
• declaring something complete and accepting that something is completed.

Conversation Flow

Think about the flow of conversations through a project. Then apply Lean values to this flow of conversation: Reduce Waste, Improve Flow, and  Reduce Unreasonableness. Not having the right conversations in the right order at the right time leads to challenges on the project. For example, you can’t make a promise on doing something until you have had appropriate understanding and forming conversations. This will lead to waste in the form of rework (not to be confused with iteration) and it is unreasonable to expect people to make promises without having already addressed understanding and forming.

You also can’t have some conversations too early in the project. By the time the team gets around to applying an early understanding or forming conversation to a doing conversation, it is likely that what was learned in the understanding or forming conversation is outdated. This is waste in the form of excessive ideas in process which lose value with excessive waiting – waste that reduces flow and leads to unreasonableness in the project.

Gordon Pask, whom the Pask Award is named after, developed Conversation Theory. One of the key ideas in conversation theory is how our internal conversations and way we are participating impact the way we make meaning in a conversation. We create barriers to conversation flow when we aren’t paying attention or when we hold other participants in an unflattering light. For example, I have seen teams that will reject all input from the project manager assigned to support the project because of the feeling the project manager is meddling – she isn’t view as a part of their team.

Kanban and Conversations

One of the things that I find frustrating in the “we need better communications” solutions offered to many teams is the lack of pragmatic application. Improving conversation flow is a pragmatic way to deliver on better communications. A solution to improving conversation flow has to meet three criteria. First, create an environment for effective conversation. Second, scale that environment beyond the small team to larger programs, even to the enterprise. Third, clearly couple conversation flow with the flow of work. Kanban (or as @ronjeffries points out, potentially any wise implementation of inspect and adapt) helps address these aspects of conversations flow.  Kanban’s daily standup and the after meetings is an approach that accomplishes all three criteria to establish effective conversation flow.

The Daily Standup and the After Meetings

In the Daily Standup the focus is on the work. So we don’t ask every person the three questions – we talk about the work. By walking the board right to left the team identifies blocks, next steps that need to be coordinated, and other opportunities for conversations. We have someone scribe the conversations that need to take place – trying to keep our focus on just those conversations that need to take place to improve the flow of work. I like to use a white board at the back of the room to list these conversations during the daily stand-up. Then have everyone bring access to their calendar to these meetings. The team takes responsibility for either having the conversation in an after-meeting, putting the conversation on their calendar, or setting up time to have the conversations. As conversations are performed or scheduled they are erased from the white board at the back of the room. Within a few minutes following the after meeting the list of meetings have been erased and the team is back at work – having optimized the conversation flow in the context of the work flow.

So Kanban helps deliver on all three criteria. First, Kanban helps us hold each other in a appropriate light – the focus on the system and the work in the system changes the way we participate. Holding each other in the light of a common interest with a clear outcome in mind results in an environment for effective conversation. Second, the Kanban board itself scales horizontally beyond the small team up stream and down stream – as well vertically up to the program and portfolio level. Third, Kanban helps with the flow of conversations by helping make it clear when we need have each conversation in the context of the current work in progress.

Kanban helps us get better at software product development by helping us get better at the right conversations. Combining the visualization of work provided by the Kanban  board with a Daily Standup and the After Meetings that are focused on the work – and not on individuals – are a pragmatic way get better at the right conversations.

In comments on my recent post, What’s Deming Go To Do With Agile, I proposed that Kanban brings an easy to implement – low friction implementation of Deming’s philosophy. Daryl Kulak disagreed – it turns out that this was based on the presumption that implementing Kanban included a prescribed implementation of TPS, TQM, and other Lean tools. We sorted it out and then Daryl made an excellent point – a normal Agile board can be used to learn from the system in the same fashion the Kanban board can. I believe this is true. In fact, I believe that the Agile board and the conversations and ceremonies around it are key to the success of Scrum teams. So, how is the Kanban board approach different then a normal Agile board approach?

No Role Changes Involved

Whether you are currently doing Agile or not, putting up a Kanban board to visualize your system requires no other changes. At the onset you don’t change any roles, ceremonies, artifacts, or measurements. You do need to go through the effort of defining the board collaboratively – involving performers, management, customers, and suppliers.

Just start with what you have. Establish a system boundary for your board. Identify the states your work goes through inside the boundary (i.e., Analyze, Develop, Accept, Release) – especially reflecting hand-offs or a shift in approach (i.e. talking about it, unit testing and coding, starting acceptance test, preparing for release). Put these states as columns on the board. Then define the various work item types that go through your system. Write up all the Work in Process on cards and place them on your board.

Use the board to understand what you have and think about it. As Daryl points out, Deming says “study your system THEN find tools to fix the problems you see.” This board will create an opportunity to create a shared understanding of your system among all the stakeholders. That’s it. In about a day you can have your board defined and within a week you will have your work moving across the board.This may not seem powerful, but in my experience this effort is extremely valuable. I have seen productivity dramatically increase just from this exercise – no role changes, no engineering changes, no changes in how we do requirements. Just making the work in the system visual and talking about it once a day.

A Broader View of the Value Stream

A normal Agile board is focused on the team, typically development. Even when you are running Scrum in other sections of the business the typical Agile board doesn’t show the broader value stream.  A Kanban board can cover all aspects of the business – from product conception to implementation. Put up the columns that help you understand your system. A common pattern I have implemented is using a Program or Portfolio level Kanban that feeds into various organizational units such as development, training, process, marketing, and HR. The point of this view is to show the broader system to everyone and how each area fits together in the broader view of delivering value to the customer. You can also cascade boards to show a comprehensive view of the complexity in the organization.

Limiting of WIP

Once you get work showing on your Kanban board you will see where work is piling up.  Excess work in process raises a number of challenges. It increases the time a new item will take to travel through the system. It indicates the likelihood of an overburden on the current performers or the next performers. For example, in Scrum iterations when there is a lot of work in development that all moves to test at the end of the iteration – this is undesirable.  You can limit WIP in a number of ways.  In Scrum, we limit WIP at the iteration boundary and some teams limit WIP by limiting the number of work items that can be active at any one time. The Kanban board calls for explicit WIP limits and also recommends buffer columns to mitigate the impact of variation to keep work flowing through the system. You can certainly explicitly limit WIP and include a buffer or buffers on a normal Agile board. Here is a essay from Lean Software Engineering showing ScrumBan.

Classes of Service

Kanban also introduces a concept of Classes of Service. Classes of Service are a mechanism for typing of work item types. Rather than treating each item homogenously, Classes of Service may let the team establish different prioritization policies for each class of service. Prioritization policies come into play when someone is looking to pull the next work item. For example, one class of service might always move the work item to the top of every queue. This would expedite it through the system. Another class of service might be even higher priority – with the team violating WIP limits and stopping what they are working on to pick up the item. Classes of Service can also help with the allocation of performers. For example, WIP limit policies may be established so that one new feature, three defects, and one technical debt feature will be active at all times.

Kanban boards are different then a normal Agile board

I agree with Daryl that a normal Agile board can be used to learn from the system in the same fashion the Kanban board can. There are some differences. A Kanban board can be implemented without changing any thing else and then making changes to fix the problems we see. Kanban can provide a broader view of the value stream. Kanban provides for limiting WIP and using buffers to facilitate pull and flow. Kanban supports classes of service. So, what stops a team doing Agile and using a normal Agile board from adding some columns, limiting WIP, and adding in classes of service? Nothing – except perhaps a lack of understanding. Part of uncovering better ways of developing software is to continue to learn and do what makes sense in each specific situation.

Here is the presentation I did at the Lean Software and Systems Conference in Atlanta. We combined Strategy Thematic Goal Models, Capability Mapping, Kanban at the strategy execution level with a cascading Kanban at the development level. The presentation was well received.