Agile Advice - Working With Agile Methods (Scrum, XP, Lean)

One of the challenges with agile methods is to get a clear perspective on how to measure process improvements. I recently had a brief discussion with a C-level executive at a small organization about this. His concern was that cycle time was meaningless because it depended so much upon the size of the work package. So how do we use cycle time as a meaningful measurement? What else can we use to measure process improvement?

Let’s look at the difference in measuring cycle time in an agile vs. non-agile environment. Then we’ll get to other measurements.

Cycle Time , Waterfall and Agile

First, let’s define cycle time. From iSixSigma we have:

Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.

This definition is important because it gives us a clue about the potential difference between a waterfall vs. agile method of delivering value. Let’s imagine the typical process used in a waterfall environment. The following are the high-level steps:

1. Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled. This is when we start the clock on cycle time.
2. The fulfillment organization (IT, Product Development, R&D) puts the request in a queue, backlog or requirements management system.
3. Along with other requests, the fulfillment organization schedules the work on the request, usually by creating a project to fulfill it and other related requests. The project is estimated at a high level, the current status of in-flight projects is noted, and the new project is prioritized relative to other projects.
4. At some point, based on the schedule and the reality of the work on other projects, the project containing our customer’s request is started. Here, “started” means that detailed requirements are gathered.
5. After sufficient requirements are gathered, a detailed technical analysis is done including architecture, high-level design, risk analysis, etc.
6. Development begins. (Note: many people mistakenly start measuring cycle time here.)
7. Developers and testers work to validate the results of development and fix any problems discovered.
8. Final acceptance testing is done.
9. The results of the project are deployed to users, sold to the client, or in some other way passed back to the original requestor. This is when we stop the clock on cycle time.

So from the start of the customer request formally submitted to the time that the fulfillment of that request is made is our true cycle time. There are a few important things to note here. First, there is a queue of work based on requests made but not yet scheduled. There is another queue for work scheduled but not yet started. We know that if we can reduce the size of these queues, we can improve cycle time in a general sense. Second, we know that most organizations of any significant size will have different queues based on the urgency of the request. For example, a high severity bug discovered in the production system of a company’s largest client will be treated differently than a wish list item for a small not-yet-client. These two requests won’t even go in the same queue: the high priority problem will be quickly escalated to a support or development team that can work on it immediately. Third, it is tempting for the development group to measure their local cycle time. This is a Really Bad Idea since it leads to sub-optimizing behaviors. For example, it is easy for the development team to improve their cycle time by sacrificing quality… but this just causes the QA cycle time to increase, and probably the overall cycle time (true cycle time) is affected more than the local improvement in the development group’s cycle time.

Now let’s look at the steps that occur in an ideal agile environment:

1. As before, the Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled.
2. That request is immediately placed in a ready state for the next iteration (cycle, sprint) of a delivery team. Elapsed time: maximum one month.
3. Team completes the request including all work to actually deliver/deploy and work is delivered to the stakeholder at the end of the iteration. Elapsed time: maximum two months.

So the ideal method of doing agile has a maximum cycle time of two months to deliver from the time a request is made… how many teams are doing this? Not many.

The ideal is extremely difficult to accomplish. Getting to that state requires that the development organization catches up to the business side so that there are zero pending requests at the start of each iteration. It also requires that the business side users and stakeholders are able to articulate their requests so that they are small, and appropriately detailed for the team doing the work.

A realistic agile implementation actually is a lot more messy. Depending on the type of request, the cycle time for a piece of work can vary widely. Some low priority items may take years even in an agile environment. A low priority request is made and approved but then never quite makes it into a project… and then once in a project never quite makes it to the top of the team’s product backlog. This is interesting to look at sometimes, but it points out another important aspect of measuring cycle time: mostly we care about average cycle time (or some other statistically interesting aggregate measure).

The predominant factor in most organizations’ cycle time is the number and size of the queues they use as work is processed. In most organizations there are several queues and most of them contain large numbers of requests or bits of work in process. Queues represent huge amounts of waste. It is easy to see that queue size and cycle time are closely related: the more items in a queue, the longer the cycle time.

This leads to a simple conclusion: regardless of lifecycle approach, reducing the size of an organization’s queues is one of the easiest ways to reduce cycle time. What are some common queues? There are often queues of projects, queues of enhancement requests, queues of defects to be fixed, queues of features, queues of tasks, queues of email (large inboxes), queues of approval requests, queues of production database changes. The number of queues increases the more an organization is oriented around functional groups, and the number of queues decreases the more an organization arranges work to be handled by cross-functional teams.

Cycle Time and Work Package Size

This is where queueing theory and agile methods intersect really well. Cycle time is related to the load on your system, in particular your units of work processing. In most organizations, teams are created to handle work. The more work given to a team simultaneously, the higher their utilization level. Many organizations like high utilization levels because it gives them a guarantee that people are doing valuable work all the time that they are paid to work. This is a completely false benefit and in fact is extremely destructive to overall productivity. From queueing theory we know that the cycle time for a piece of work increases exponentially to the utilization level. We see this whenever we over-load a server… but for some reason we fail to see this when we overload a person or a team or an organization even though it still happens.

Cycle time is also related to the variability in the size of the work packages. Low variability means that the exponential factor related to load is low, and high variability means that the exponential factor is high. In other words, if you have a highway that only allows motorbikes, you can have a very high load without getting bad traffic jams. On the other hand, if you have a highway that allows anything on it, you get traffic jams even with low levels of load. This is why HOV or commuter lanes and the left lane in multi-lane highways don’t typically allow transport trucks and buses. This result from queueing theory is not intuitively obvious so it is even harder for us to apply to software development.

But apply these two ideas, load and work size variability, we must if we wish to create a high performance development organization. The simplest way to do this is to have a single team work on a single project at a time and use iterations to ensure that the work being done is always exactly the same size - the size of the iteration.

Improving Cycle Time

It is possible to have very short iterations and still have a long cycle time. Many organizations make a few common mistakes with agile that cause this. If the work done inside each iteration is restricted to pure development work and everything else is done outside the iterations, then cycle time likely stays long. A common example of this is having the QA folks remain separate from the development team and do their work after a development team releases their work.

There is really only one way to avoid this: have a comprehensive definition of “done” that is met by the team every single iteration. This ensures that all work from idea to release for a given customer request is done inside a single iteration. A side effect of this is that all the pieces of work need to be small. It also gets rid of all the queues except one: the queue of ideas approved for delivery. With a single queue to manage, it becomes easy to measure cycle time, and therefore easy to improve it.

Improving cycle time can now be done in a few ways:

1. Put a cap on the number of items in the work queue. Since cycle time is directly related to the size of the queues in a system, this is a sure way of putting a maximum on cycle time.
2. Go through all existing requests and throw as many away as possible. This can be tough to do, but if you are able to do a cost benefit analysis, you will typically find that older items in the queue are no longer worth while.
3. Provide more stringent gating functions for allowing requests onto the queue. The few items added, the faster the size of the queue is reduced.
4. And of course, increase the performance of your team(s) so that they go through items on the queue more quickly.

Productivity and Cycle Time

Once you have control of cycle time, it is possible to make reasonable measurements of productivity and two more metrics become extremely important (not that they weren’t important before, but they are easier to work with now). The first is Return on Investment (ROI) and the second is customer satisfaction.

ROI is in its simplest form a measure of how much benefit there is to doing something as compared to the cost of doing it. It takes into account the importance of time and timing, the importance of other options you may have, and of course, hopefully takes into account the business reality of your work. It also takes into account costs.

In software development, the primary cost is the cost of the staff doing the work, and the time factor is your cycle time (Ah! that’s where we use it). If you have a consistent team working on iterations that are always the same size and if you have little or no work being done outside of the iterations, it is very easy to calculate ROI in a useful way. Simply measure how much value a given iteration worth of work will generate and divide by the cost of the team for an iterations (and if the team is not yet doing work as it comes in, take into account the time value of money since the work might not be done for several iterations). Now, productivity is simply a measure of the Return for each Team-Iteration. Dollars/iteration. Simple. If the team’s productivity goes down, you can ask some really simple questions:

• Did the expected return of the work go down? If so, is there more valuable work the team should be doing? This becomes an opportunity for product improvement.
• If not, what caused the team to get less done? Was the work harder than expected? Was there a skill gap? Was there an organizational obstacle that was revealed? Was someone sick? This becomes an opportunity for process and team improvement.

Customer satisfaction can be measured in many ways. If you have already started using agile practices, there is a good chance that your customers will already be more satisfied than they were before. This will show up informally through word-of-mouth. However, it is good to have a more systematic way of measuring customer satisfaction. One of the simplest and most commonly used methods of measuring customer satisfaction is the Net Promoter Score. From WikiPedia:

Companies obtain their Net Promoter Score by asking customers a single question (usually, “How likely is it that you would recommend us to a friend or colleague?”). Based on their responses, customers can be categorized into one of three groups: Promoters, Passives, and Detractors. In the net promoter framework, Promoters are viewed as valuable assets that drive profitable growth because of their repeat/increased purchases, longevity and referrals, while Detractors are seen as liabilities that destroy profitable growth because of their complaints, reduced purchases/defection and negative word-of-mouth. Companies calculate their Net Promoter Score by subtracting their % Detractors from their % Promoters.

The Net Promoter Score is closely linked to quality including the hard-to-measure parts of quality like responsiveness, ease of use, and fitness for purpose.

Cycle time also affects customer satisfaction. The faster you can respond to requests by customer, users or other stakeholders, the more likely they are to be satisfied. This happens for two reasons: fast response time means that solutions are more likely to still be useful and correct when actually delivered, and it also gives more opportunities for feedback.

In fact, if we look at these three measures, cycle time, ROI and customer satisfaction, we see that they form a mutually supporting and cross-checking system of ensuring productivity and effectiveness. Measuring anything else muddies the waters and can cause sub-optimal behaviors. The real challenge for most teams is realizing that all their local measures of performance and effectiveness may actually be causing harm (unintentionally) because they draw the team’s attention away from the three organizationally important measures.

Cycle time is the measure that is most closely related to process improvements, but ROI and customer satisfaction should also be used to ensure that process improvements don’t accidentally harm the organization.

The recent growth in the popularity of agile methods such as Scrum is gratifying. However, I am constantly encountering people looking for the Silver Bullet of software development. In the paper written by Brooks, No Silver Bullet[pdf], he describes “accidental” and “essential” complexity. Agile in no way changes his arguments. What agile methods do is to help remove the accidental complexity associated with people and their interactions. This can lead to substantial increases in productivity, but it does not change the hardness of the underlying problem that is being solved by building a particular software system. In fact, doing a good job with agile methods, in particular Scrum, is extremely hard work due to the deep cultural shifts that must occur in order to get the full benefits.

Building software is expensive. I’m not talking about creating software, I mean taking software as written (source code) and running it through compilers and linkers and post-processors and packagers and obfuscators and installer-generators. It might not seem so, but look under the covers and you will find a wealth of costs and potential savings…

Lifecycle of the Developer

The developer has a concept he needs to translate into software. He (or she) does not sit and meditate until it comes to him, then streams it effortlessly into the computer. Rather he tries something, and tries something else, and writes some conditions (tests) to limit the scope of his options, and cycles over and over and over again between four main activities: creating -> building -> executing tests -> discovering. The developer then wraps around, having discovered and learned (found the bug or identified a future direction) and begins to create again.

If you break this down, there are two states - active and waiting - that the developer is in at any point. He is active when he is learning and he is active when he is creating. He is waiting when he is building and executing tests. So the developer’s ability to do further learning/creative work comes from how long he has to wait for building/executing the software.

(more…)

How do we teach people to work in a collaborative manner? How do we help individuals, in our incredibly individualist and competitive society, to learn the skills needed for agile teamwork?

(more…)

The Project Management Institute refers to three variables that can be negotiated or constrained for a given project: scope, resources and schedule. Schedule is an interesting “variable” in that we have no choice about how time flows. We can control how much scope to ask for, we can control how much money to put towards the work, but we cannot actually “buy” more time than, say, our competitors. This has important implications which deeply challenge the PMI’s PMBoK model of project management.

(more…)

Last week I taught an introductory course on Agile Work. Normally this is pretty easy stuff. However, I was teaching this course in Bucharest, Romania (cool), and I have come across a substantial, strong and vigorous objection to agile (also cool, but challenging too). Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either. I’m looking for help on this!

(more…)

Last night I was thinking more about the analogy of technical debt. In this analogy, design and quality flaws in a team’s work become a “debt” that must eventually be paid back. This analogy is fantastic because it can be taken just a little bit further to understand just how bad defects are…

(more…)

What is the difference between an agile process and a non-agile process?

(more…)

Queueing theory (1, 2, 3) and Lean pull-based queue systems provide some insights into why agile backlogs such as the product backlog found in Scrum are done they way they are.

Updated! (originally published April 6, 2005)

(more…)

Most of the teams and organizations I coach are working on using agile methods to improve their software development approach. Somewhere along the way, someone has realized that there must be a better way… either better than chaos, or better than bureaucracy. Over the years that I have been practicing agile methods, I have come to believe that quality is not negotiable.

(more…)

There is a nice comparison that can be made between loans and agile. My father, an agile coach now, describes the metaphor this way:

(more…)

In Blink : The Power of Thinking Without Thinking by Malcolm Gladwell, there is a chapter that describes a number of fascinating experiments. These experiments show how we can be influenced by very subtle cues in our environment. This is a very important lesson for us to apply in our work environments and in particular in our agile work.

(more…)

If you are given a problem to solve, how much does the presentation of that problem matter to your ability to solve it? Imagine that it’s a simple problem… imagine that it is presented in two different ways, both of them simple. It turns out that presentation differences can still make a huge difference. In fact, there is a way to present problems that makes them substantially easiers to solve: make them people problems.

(more…)

We know that teams go through identifiable stages of development: forming, storming, norming and performing (1). What exactly does this look like for an Agile team?

(more…)

I recently completed reading An Introduction to General Systems Thinking by Gerald M. Weinberg. Since it was mind-blowingly fantastic, I thought I should probably write a brief review of it so you-all can check it out!

(more…)

In “Built to Last : Successful Habits of Visionary Companies” Jim Collins repeatedly emphasizes that long-lasting successful companies have a very single-minded focus. But that focus is not stupid or blind. Rather, Collins uses the phrase “Preserve the core / stimulate progress”. This is also the essense of agility.

(more…)

At the Coach’s meeting ten days ago, several of the attendees used a series of phrases to refer to the learning process or cycle that Agile Work promotes. These vocabularies all have a different slant or implication but they all map to each other fairly well.

(more…)

Software projects have a really bad record. Here’s a part of that bad record: on average, 45% of features delivered are never used! This is yet another reason that Agile methods shine: do the highest value work first and stop when you’ve got enough. Can’t do that with waterfall projects!

A recent discussion on the Scrum Development list (Start of Discussion) provides a good follow up to my parting words in The Art of Obstacle Removal about agile practices themselves becoming obstacles. I have excerpted a small amount of the discussion and added my own comments here.

(more…)

One of my favorite books of all time is Systemantics by John Gall. There is a new version of it called “The Systems Bible”. This book was my introduction in my early twenties to the topic of systems theory.

(more…)

One of my favorite little management blurbs, seen on the door of an SVP at a major financial services company: “Processes don’t write software, people do!” And of course, the Agile Manifesto states: “… we have come to value: Individuals and Interactions over Processes and Tools…” Here’s an interesting little writeup about people and process. My own take is quite similar: a process can be more or less helpful, but only if people are willing to learn and change can true progress be made.

Agile Work requires that we align our perception of reality in order to understand each other and do work that is considered valuable by everyone. One very blunt and seemingly simple way to do this is with metrics. But metrics need to be in context and that is the part that is hard to get right. Does your organization get it right?

(more…)

This third and final installment of the “Agile Work Uses Lean Thinking” series introduces Team Self-Organization from a lean and agile prespective. Find out what lean practice relating to people is not commonly used in agile methods… (Previous installments are Empirical Process Control and Queuing Theory. A polished version of all three articles will appear soon as a downloadable PDF.

(more…)

Twenty-five years ago American-Israeli Medical Sociologist, Aron Antonovsky developed the theory of salutogenesis. As opposed to the traditional pathogenic model of medicine focused on the study of disease, salutogenesis is the study of health. Since then, his work has been integrated into the field of public health and health education. This asset or strength based type of approach to individual or institutional development has been found in other fields such as organizational development and community development. In organizational development the field of Appreciative Inquiry and in community development the Asset Based Community Development model share the essential premises of salutogenesis. Quoting Garmezy, Antonovsky highlights the medical professions focus on deficits:

our mental health practitioners and researchers are predisposed by interest, investment and training in seeing deviance, psychopathology and weakness wherever they look.

This type of approach to work based on weakness and deficit can be found in most of our organizations. It seems to me that although Agile exposes inefficiencies and problems in organizations, it’s focus never-the-less is to build on strengths and assets. It is in this light that I have been thinking about Antonovsky’s work and what it can offer to Agile.

Antonovsky came to this theory of salutogenisis when he carried out a study on Israeli women going through menopause. He found that there were a number of women who, according to all indications of the pathogenic model, should be suffering severe symptoms (because they faced severe stressors which cause illness). But they were not suffering at all. To his surprise he discovered that these women happened to be survivors of concentration camps. He found certain qualities in these women that resulted in what he called a higher “Sense of Coherence” than the other women.

Sense of Coherence is made up of three factors; comprehensibility, manageability, and meaningfulness.

Comprehensibility means that whatever happens to a person, she is able to make sense of it and understand it, that is, the challenge is in some way “structured, predictable, and explicable.” Manageability means that either the resources are available to one to meet the demands posed by the stimuli,or one has a way to find them. Meaningfulness involves having a sense of meaning in the important areas of one’s life or recognizing “these demands are challenges, worthy of investment and engagement.”

Antonovsky found meaningfulness to be the motivational factor of the three, although he also found that all three mutually reinforce one another. For example if one has a high sense of comprehensibility but is low on the other two, one ends up not having the motivation to find resources and soon after this causes comprehensibility to be lost. If one is high on meaning and missing the other two, Antonovsky explains that there is a good chance to find the other two.

The theory of Salutogenisis may provide researched and proven reasons why Agile is so empowering for people. This research may also provide more insight into how to deepen Agile experiences to higher levels of empowerment. Agile methods help people to make sense of the market place by allowing for iterative delivery and adaptive planning, thus increasing their level of comprehensibility. Iterative delivery, adaptive planning and the concept of amplifying learning are all conducive to increased sense of manageability. Because people spend most of their time at work, it is quite important that they feel a sense of meaning in their work. The concept of empowering the team and the practice of self-organized teams and appropriate metrics can contribute to increased sense of meaning in one’s work.

Salutogenic food for thought for the Agile practitioner:

Antonovsky associated comprehensibility with consistency which he defined as “the extent to which one’s work situation allows and fosters the clarity of seeing the entire work picture and ones place in it, provides confidence in job security, and supports communicability and feedback in social relations at the workplace”.

How can the concept of consistency be promoted in Agile projects?

Manageability is related to under load/overload balance which is defined as “the availability of resources to the individual and to the collectivity within which there is interaction to get the job done well” and “…the extent to which the work situation has room for allowing potential to be utilized in substantively complex work.” The opposite of the former results in overload and the opposite of the latter is a situation of under load.

How can Agile projects guard against overload? How can an Agile coach and Agile teams fully utilize the capacities of its members?

Meaningfulness is closely associated with participation in shaping outcomes. Antonovsky explains beautifully the relationship between these two concepts:

When others decide everything for us-when they set the task, formulate the rules, and manage the outcome-and we have no say in the matter, we are reduced to objects. A world thus experienced as being indifferent to what we do comes to be seen as a world devoid of meaning.

In light of the concept of meaningfulness how can the principle of self organized team and shared decision making be deepened in Agile work?

Reference:
Antonovsky, Aron (1988). Unraveling the Mystery of Health: How People Manage Stress and Stay Well (Jossey Bass Social and Behavioral Science Series)

http://www.stfx.ca/institutes/coady/text/about_publications_occasional_citizens.html.

What Is ABCD?

It is an approach to community-based development, based on the principles of:

* Appreciating and mobilising individual and community talents, skills and assets (rather than focusing on problems and needs)
* Community-driven development rather than development driven by external agencies

It builds on:

* Appreciative inquiry which identifies and analyses the community’s past successes. This strengthens people’s confidence in their own capacities and inspires them to take action
* The recognition of social capital and its importance as an asset. This is why ABCD focuses on the power of associations and informal linkages within the community, and the relationships built over time between community associations and external institutions
* Participatory approaches to development, which are based on principles of empowerment and ownership of the development process
* Community economic development models that place priority on collaborative efforts for economic development that makes best use of its own resource base
* Efforts to strengthen civil society. These efforts have focused on how to engage people as citizens (rather than clients) in development, and how to make local governance more effective and responsive.

http://www.synergos.org/globalphilanthropy/02/abcdoverview.htm