Posts Tagged ‘Lean’

10 Years Agile–Friday Night

Posted on February 12th, 2011 by Dennis Stevens  |  3 Comments »

Attendees

Here are the people that are in Snowbird for the 10 years Agile celebration.

  • Pekka Abrahamson
  • Scott Ambler
  • David  Anderson
  • Mike  Beedle
  • Tracy Bialik
  • Alistair  Cockburn
  • Rachel Davies
  • Michael Feathers
  • James Grenning
  • Robert Holler
  • Jonathan  House
  • Erik Huddleston
  • Michael Hugos
  • Zhon Johansen
  • Kay  Johansen
  • Ralph Johnson
  • Nate Jones
  • Joshua Kerievsky
  • Jon Kern
  • Phillipe Kruchten
  • Janice Linden-Reed
  • Todd Little
  • Ryan Martens
  • Eric  Olafson
  • Jeff Patton
  • Russ Rufer
  • Alan  Shalloway
  • Ahmed  Sidky
  • Andrew Shafer
  • Dennis  Stevens
  • Jeff  Sutherland
  • Arline  Sutherland
  • Ghennipher  Weeks

Friday Morning

I spent the morning with Ahmed Sidkey and Alistair Cockburn working on some ICAgile activities. We are trying to get the Business Analysis and Project Management tracks up now that Agile Fundamentals has launched. I am working with the Business Analysis community to coordinate the BA track and bringing the PM work from the recent (and ongoing) efforts of Alistair, Ahmed, Mike Cottmeyer, Mike Griffiths, Michelle Sliger, Jesse Fewell and others with PMI to define Agile PM.

Pre-Cocktail Party

After riding up to the conference, I got to meet and spend time with Tracy Bialik, Alistair, Ahmed, David Anderson, Alan Shalloway, Janice Linden-Reed, Phillipe Kruchten, Erik Huddleston and others greeting, catching up and talking about our expectations for the weekend.

Cocktail Party

At 8, we had a cocktail party where we met Janet Danforth and Robert Moir. Janet and Robert will be facilitating the Saturday morning discussions. There were questions spread around on tables that had been solicited from attendees by the facilitators prior to the event. They were divided into several categories for us to review and discuss. I spent some time at a table with a number of people including Ahmed Sidkey, Jon Kern, Erik Huddleston, and Scott Ambler. The discussion started off around how to get other communities (BA, PM, QA, etc) involved in the Agile. We ended up talking about resting heart rates and food densities – so while it was interesting at the moment I’m not going to blog about it here.

I then spent about half an hour in a discussion with Erik about his approach to scaling agile at his organization. He has courageously built on Dean Leffingwell’s model. He is implementing small fungible teams (high performing teams with the ability to deliver a working increment of software across the portfolio) and is using Kanban at the Program level to feed and coordinate the teams and to dynamically match capacity to demand. Then he is using Kanban downstream from the teams to coordinate integration testing, implementation, and production. This is a pattern that I have seen work well and have seen emerge from multiple directions. Mike Cottmeyer and I have been using this model as a kind of reference architecture for businesses and have had success. I believe this is an organizational adoption pattern that we will see more of.

Later I was involved in conversation with Jeff Patton and Rachel Davies talking about various topics. One was how hard it is to define explicitly how to apply certain practices when coaching teams since we tend to morph them to the moment and are always applying new concepts and ideas. Jeff is gently introducing A3 type thinking into his clients – something that we are starting to do more of – so it’s a validation of a pattern that makes sense. Jeff and I talked about how capability analysis and story mapping share some underlying patterns that seem to make sense. Rachel talked about how hard it is to to get organizations to change and how organizations seem to get stuck in destructive behavior. Jeff brought up this video as something he shows in his class to help people to recognize how they participate in their organizational dysfunction. It is pretty funny.

After Party

We had an after party from 9:00 – 11:00 where we drank Cockburn port and had more conversations. I spent some time talking to Alistair and then got to spend a while with Joshua Kerievsky and Mike Beedle talking about how important the underlying enabling technologies were to doing anything agile.  We also talked about how Scrum and XP have morphed and how implementations must be situation specific.

Summary

There are a lot of people here from various communities. Lean, Scrum, XP, etc. It would be fun to do social network map of who is connected to who in this group and what those communities look like. There was a lot of engagement and energy last night and I didn’t see any conflict. The themes of post-agile, situation specific morphing of practices, and scaling patterns were pretty common place. Today, we have a four hour facilitated session that should be interesting.

Kanban and When Will This Be Done?

Posted on June 7th, 2010 by Dennis Stevens  |  14 Comments »

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. imageCycle 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. imageTake 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. imageIn 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

Posted on June 1st, 2010 by Dennis Stevens  |  2 Comments »

image

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.

image

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.

image

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.

imageKanban 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.

Strategy Execution Case Study

Posted on May 22nd, 2010 by Dennis Stevens  |  No Comments »

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.


What’s Deming Got To Do With Agile?

Posted on May 21st, 2010 by Dennis Stevens  |  6 Comments »

When I show the Kanban board, a tool that is borrowed from Lean,I hear,

“Well, software development is an artistic process – you can’t apply manufacturing principles to it.”  

Or, “I was involved in a Six Sigma (or TQM) project that was devastating – Lean doesn’t translate to software development.” 

Or, “Analysis, Development, Acceptance, Production – that looks like waterfall, haven’t we gotten past waterfall yet?”

So let me be clear up front – some amount of software development is creative, you can’t directly apply manufacturing principles to software development, applying Six Sigma and TQM to software development like it is a production line is destructive, and in most cases waterfall doesn’t make sense in software development.

Deming is About Culture – Not Manufacturing and Not Process

But Deming is not about manufacturing. He is about showing management how to create an environment for success. Deming is about culture – and his System of Profound Knowledge creates an environment that is especially effective for knowledge work. As I discussed last week, Deming’s System of Profound Knowledge has four points: 1. Understand the System, 2. Understand Variation in the System, 3. Have a Theory of How to Act on The System, and 4. Understand Human Psychology. How does Kanban help us inform the context and culture of the team performing development to achieve the benefits associated with Deming’s System of Profound Knowledge?

What Does it Mean to Understand the System?

By understanding the system, participants can operate in a way that everyone (management, performers, customers, and suppliers) benefits. Understanding the system is difficult – typically everyone views the system from their own siloed perspective. Understanding the system requires that everyone rise above their siloed perspective to understand the system goal, what the organization does to achieve this goal, the boundaries and constraints, and the sensing and  feedback mechanisms.

Kanban helps participants understand the system by making the goals, capabilities, and boundaries explicit. The participatory nature of developing and interacting with the board changes everyone’s perspective from a siloed view to a focus on system level success. The board itself, metrics such as the CFD, the establishing of policies and tracking of.performance against those policies provides feedback on the system.

How do we understand the impact of variation?

Variation is inevitable. The size of work that needs to be done isn’t uniform. The complexity of work has high variability – not just between work items – even between the types of work to be performed on each work item. For example, one item may be hard to analyze but turn out to be easy to build and test. Another may be easy to design and build but very difficult to test. It is common on teams for there to be a significant gap between the most skilled developers on the team and the less skilled developers. So the work is of various sizes, with various levels of complexity, being worked on by various levels of performers.

Kanban helps with this in three ways. First, limiting WIP reduces the overall impact of variation on the system. Second, the Kanban board makes the impact of variation explicit. One a daily basis the team can work together to allocate themselves to adjust to variation in real time by swarming or influencing what they pull. Finally, by managing the average lead time – and not trying to manage exact lead times of every item – Kanban helps smooth the impact of variation on the promises (SLA’s) make to the business.

Theory of Knowledge or “What are you prepared to do about it“?

Using the information you gain from your understanding of the system and insight into variation on the system you apply PDSA. You will see this expressed as PDCA (Plan, Do, Check, Act) or PDSA (Plan, Do Study, Act). I like to use Plan, Do, Study, and Adjust. Plan-Do is typical management – this means take specific actions that you hope will achieve a specific result. An expectation of Study-Adjust allows the organization to learn rather than blame.  A culture of continuous improvement emerges where PDSA is practiced.

Kanban delivers a platform where the organization can practice PDSA. Through metrics, operations reviews, the Andon, and potentially retrospectives provides the ability to make a hypothesis about the system (Plan). Then they can make policy, process or organizational changes with the intention of achieving an improved outcome (Act). The system will expose whether the desired outcome is achieved (Study). Then the team can learn alter their theory of knowledge and adjust their actions. The transparency of Kanban helps develop our theory of knowledge and gives us courage to act on the system.

How does Kanban impact Human Psychology?

Employee engagement is a key to the successful performance in organizations. Organizations with high employee engagement have a much higher rate of employees who show a strong passion for their work and a commitment to their co-workers. Therefore it is not surprising that organization’s with higher levels of employee engagement also have higher levels of employee productivity. Employee engagement arises when employees believe they positively impact the quality of the organization’s products.

In knowledge work, where products are invisible, impact can be difficult to demonstrate. Kanban clearly shows progress and demonstrates the contribution of each person to the delivery of value. Additionally, PDSA provides opportunities for everyone to contribute to improving the quality of the organization’s capabilities. By breaking down silos and creating insight that results in employee engagement, Kanban leverages human psychology to help organizations transform and mature.

Kanban supports Deming’s System of Profound Knowledge

If you equate Kanban with manufacturing you won’t be successful. You need to understand what Deming has to say about knowledge work and how management is responsible for creating an environment for success. Kanban brings an easy to implement – low friction implementation of Deming’s philosophy.  Implementing Deming’s System of Profound Knowledge through Kanban is a proven method for achieving higher levels of maturity and improved performance.

Lean Time

Posted on December 26th, 2009 by Dennis Stevens  |  No Comments »

I have been reading a lot about of the recent group discussions and papers regarding Kanban and Lean Software Development. One of the things I have noticed is that there is not a consistent application of the concepts regarding time. One of the reasons we establish a body of knowledge is to create a common language that helps us communicate based on a shared understanding. This inconsistency in the use of terms around time create a gap in understanding. In an effort to help the conversation here are the appropriate definitions for each type of time.

Durations

Duration is simply a measure of elapsed time.

Lead Time: The average time it takes for one unit to go through the entire process – from start to finish – including time waiting between sub-processes. Lead time can take different perspectives.

Development Lead Time is the time it takes for a unit to go through development from release from the backlog until it is done (which includes analysis, development, test, acceptance, deployment – but maybe not release to production). It is interesting to the development manager.

Order Lead Time is the time that elapses between when the customer places an order and when the customer receives what they ordered. In cases where requests are queued in a back log and releases are decoupled from development completion this can be far longer than the Development Lead Time. This is interesting to customer.

Order to Cash Lead Time is the time from when the customer places the order to the time cash is received by the business. While this is often longer than the Order Lead Time it can be shorter than the Order Lead Time when the customer prepays. This is interesting to the person paying the bills.

Process Lead Time: The time the unit is being worked on in a specific process before it is passed on to the next process. For example, within Development Lead Time this could be analysis, development, automated test, acceptance test or deployment time. This is interesting to the person performing the specific process or activity.

Processing Time: The time the unit is actually being worked on. It would be the sum of all the Process Lead Times. This is interesting to use as we try to improve our Lead Time.

Value Add Time: The Processing Time spent on a unit that transforms the unit in a way that the customer is willing to pay for. Not all Processing Time is Value Add Time – although non-Value Add Time can be necessary due to compliance requirements, to optimize performance of value add resources, and to minimize rework. This is interesting as it has been the subject of much of the lightweight process effort in Agile development. When taken to far it results in increased Rework Time and increased Process Lead Time.

Rework Time: The Processing Time that results from poor quality.  Failure Demand is the amount of resource that is consumed by Rework Time. This is interesting as it is expensive.

Queue Time: The time a unit sits between sub-processes waiting for someone to work on it. This is interesting to us as we try to improve our Lead Time. This is no cost to improving flow to reduce Queue Time but it reduces Lead Time.

Cadences

Cadence is a measure of time per unit.

Cycle Time: The average time between units coming out the end of the pipe. This is interesting because it helps us predict Lead Time.

Takt Time: How often units need to come out the end of the pipe to meet customer demand. This is interesting because it reflects the rate we need to produce to optimize investment against revenue.

You would expect Lead Time to be the sum of Processing Time, Queue Time, and Rework Time – and it is in a purely serial process flow. But in cases where work moves in parallel the sum of Processing Time, Queue Time and Rework Time will be greater than the Lead Time. Lead Time is interesting because it is what we use to make commitments.  Improving Lead Time can be done by reducing Queue Time, shortening Process Lead Time, eliminating Rework Time, minimizing non-Value Add Time, and performing processes in parallel.

The concept of Value Add Time is interesting and has had strong impact on Agile processes. At some point things like documentation, planning, testing, and adding additional features are not adding value in a way the customer is willing to pay for. Reducing these items to the bare minimum time that is necessary to meet the needs of the customer is helpful. Reducing them to the point they increase rework or reduce the productivity of the value added performers is not helpful.

The biggest inconsistency I have noticed is the improper use of Lead Time (a duration), Cycle Time (a cadence), and Takt Time (a cadence). In summary, Lead Time is how long it takes us to build and deliver it, Cycle Time is how often a new one is produced, and Takt Time is the rate of customer demand. In a stable system, Duration and Cadence are related by Little’s Law. The cadence of Cycle Time will equal WIP divided by the duration of Lead Time.

I believe that consistent use of these terms will help us have more meaningful conversations and continue to improve the ways that we deliver software to our customers. Part of my focus over the last decade has been on reducing Lead Time through reducing WIP, Queue Time, and non-Value Add Time, improving quality to reduce Rework Time, and improving architecture, automation, and shared understanding to reduce Processing Time. Having a shared understanding for each type of time leads to productive conversations around specific techniques and improves the teams ability to focus on the right types of improvements.

Methods, Practices, and Outcomes

Posted on September 1st, 2009 by Dennis Stevens  |  No Comments »

There continues to be discussion about Scrum (as a brand) vs. Kanban (capital K) vs. Crystal vs. FDD, etc. If fact, I received a comment today on a March post discussing the Scrumbut test. My comment became to long and is so relevant to recent discussions that I turned it into a blog post. From my perspective these method wars tend to fall into “How Trap” discussions. How Trap discussions are not about specific outcomes you are trying to achieve and developing a situationally specific approach to achieving those outcomes.

Take a look at the Scrumbut test I learned about from Jeff Sutherland. Whether you are doing (or even like) Scrum – when viewed through an outcome lenses, these questions lead to discussion regarding clearly important outcomes. Below, I list the question category from the Scrumbut test, then the outcome that is desired from the practices described in the Scrumbut test, then a hopefully clarifying description.  The practices are detailed at the Scrumbut link.

Question 1 – Iterations: Limit Work in Process – don’t start anything you can’t finish

Question 2 – Testing within the Sprint: Maintain Code Quality – Shorten quality feedback loops to zero to maintain code quality and reduce the waste of rework

Question 3 – Agile Specification: Communicate Business Needs to Development – Ensure developers understand outcomes while minimizing coordination and transaction costs, maintain traceability to business need

Question 4 – Product Owner: Maintain Product Roadmap – The business communicates a plan of what is being built

Question 5 – Product Backlog: Prioritize Investments Based on Return – the business prioritizes work based on a current understanding of business value

Question 6 – Estimates: Provide Meaningful Effort Estimates – Understand rate the team can produce work to support planning, investment decisions, and customer commitments

Question 7 – Burndown Chart: Communicate Release Schedule – Be able to predict content and timing of future releases. This clarifies corrective action, next most valuable investment decisions, marketing decisions and customer commitments

Question 8 – Team Disruption: Maintain Productive Work Environment – Management understands and supports the focus on rapid delivery. Trust is established that the team will be able to meet current and future commitments.

Question 9 – Team: Develop an Empowered Team – The team feels empowered to make decisions about how to move forward. Management has provided sufficient guidance and direction that they trust the team will make operational and tactical decisions aligned with the best interest of the business.

Yes, Jeff has a brand he is protecting. If you think you are doing Scrum and you aren’t achieving these outcomes then you aren’t doing what was intended. Bad Scrum and Scrumbut hurts the Scrum brand. In fact, since Scrum is a dominant Agile brand, it hurts all of us trying to move Enterprises towards improved software agililty.

But, Scrum isn’t the only way to achieve these outcomes. I can map these outcomes to mature implementations of XP, DSDM, FDD, Crystal and Kanban (etc.). Now the interesting conversations sound like –

  • In what situations does Kanban reduce transaction and coordination costs more than Scrum?
  • In what situation does one method lead to better adoption over another? Why?
  • In a specific organization, what approach to developing empowered teams and upstream trust will be most likely to succeed?

The outcomes described in the Scrumbut test can be achieved by applying specific strategies that are consistent within an organization’s environment. When these outcomes are adopted development teams tend to become more mature, better at delivering software (many times dramatically), and improve their work environment. Regardless of method, you need to be focused on the outcomes that result in improvements in productivity and find the way that works in your organization to adopt and sustain the outcomes.

Does Process Discipline Really Reduce Creativity?

Posted on July 22nd, 2009 by Dennis Stevens  |  2 Comments »

Something I find interesting is the push back I hear from agile developers that process discipline will inhibit their creativity. They say, “Software development is a creative activity. If you put process rigor around it you will inhibit our creativity.” I have heard others complain about applying Lean concepts to software development. “This isn’t manufacturing,” they say, “There is no place for standard work in what we do.”

Non Sequiturs in Software Development

These statements are examples of the non sequitur fallacy. A non sequitur fallacy is where the argument is false because the conclusion (rigor will inhibit creativity) does not follow from the initial premise (software development is a creative process). We see examples of non sequitur’s every day. We see them in advertising. For example,

“Buy this car and you will be more appealing to the opposite sex”

This isn’t a true statement. The car won’t make you more appealing to the opposite sex. We may want to be –  so we believe it. But this is a logical fallacy because the conclusion (you will be more appealing) actually has no cause and effect relationship with the initial premise (Buy this car).

In fact, it is because software development is a creative process and because it isn’t manufacturing there there are a whole set of processes that must exist to drive value. It is important to focus creativity where it adds value. It is also important to create an environment where creativity can be harnessed. You may not be able to create standard work around domain specific problem solving, but I contend that the higher the level of process discipline in the team, the more reliably developers will  deliver value. Further, I believe that the lack of discipline in the following process areas is the key contributor to poor performance – particularly in new agile teams.

Areas Where Process Discipline will Drive Value

To make my point, I am going to discuss four processes areas where process discipline to the point of standard work will improve the delivery of software. “Standard Work” is defined as a simple written description of the safest, highest quality, and most efficient way known to perform a particular process or task. It is agreed by the team to be the only acceptable way to do the process it describes. It is expected to be continually improved.

This is not an exhaustive list of the processes areas where discipline is required. These are process areas that are critical to teams, regardless of your flavor of agile: quality, learning and feedback, collaboration processes, and flow management.

Quality: The purpose of Quality processes is to create an environment where it is safe to pursue creativity in domain specific problem solving. Quality processes ensure the resulting product meets the needs of the customer and supports the goals of the development team. Effective Quality processes result in a net improvement in time to value delivery. Test Driven Development, Continuous Integration, Use of Patterns, Configuration Management, and Coding Standards are examples of Quality processes. Quality processes don’t hinder creativity. Just as in manufacturing they enhance the ability to leverage creativity to deliver value.

Feedback and Learning: The purpose of Feedback and Learning processes is to inform the team about how they are performing and to identify where constraints to their performance exist. Armed with this information, the team takes corrective action to avoid problems and overcome impediments. They also identify improvements that increase their ability to deliver value. Feedback and Learning processes include maintaining Burn-down Charts, Cumulative Flow Diagrams, and Kanban Boards and performing Retrospectives and Operations Reviews. Because software development isn’t manufacturing, constant feedback and the resulting learning is necessary to ensure the Agile team is improving (or at least maintaining) its ability to deliver value to the organization. Feedback and Learning processes also provide the ability for teams to creatively improve their performance.

Collaboration: The purpose of Collaboration processes is to ensure the team has a clear understanding of what they need to deliver and have a shared understanding of the dependencies within the team. Effective Collaboration processes will dramatically improve the teams ability to create value. Sprint Planning, Daily Stand Ups, and Story Reviews are examples of Collaboration processes. Clearly, adherence and process discipline are necessary to ensure a team if performing effectively. Strict adherence to Collaboration processes does not restrict creativity.

Flow Management: The purpose of Flow Management processes is to prioritize work for the team to optimize value and to throttle the amount of work that is active within the team to optimize productivity. Management also uses Flow Management processes to understand where the business stands on commitments to stakeholders and customers. Setting Milestones, Iteration Planning, Backlog Grooming and setting WIP policies are examples of Flow Management processes. As we learned from manufacturing, following these processes with discipline can dramatically improve the rate and amount of value the team is able to produce. None of these processes restrict creativity.

Process without Purpose is the Culprit

When pursued with the appropriate purpose, process does not inhibit creativity – it enables creativity. Many of the processes and techniques that have proven to be valuable in manufacturing have also demonstrated tremendous benefit in software development organizations. The “bad-taste-in-your-mouth” feeling that developers get when discussing process discipline and standard work is the result of process for the sake of process. Don’t let that feeling sway you from putting appropriate process rigor into place. Remember, “Software development is a creative process. If you put process rigor around it you will inhibit our creativity” is a logical non sequitur. Process discipline and standard work are not inhibitors to creativity, they are enablers.

Uncovering Better Ways of Developing Software by doing it and Helping Others do it

Posted on July 12th, 2009 by Dennis Stevens  |  4 Comments »

In the Agile Manifesto it says, “We are uncovering better ways of developing software by doing it and helping others do it.” I have been paying attention to the conversations between the BUFD traditionalists, the Agilists, and now the Kanban communities. This conversation has not always been friendly – and some members of each community certainly aren’t looking to learn about better ways of developing software. In fact, the contentious debates are creating obstacles to helping others do it.

I find that there are valuable capabilities in each of the practice areas. Agile was never completely different than BUFD. It was 20-30% different. And that difference, when done well in the right context, dramatically improved the value of the software being developed and the velocity that it was delivered. Kanban is probably 10-20% different than Scrum, the most prominent instance of Agile. XP doesn’t really come into the discussion because XP practices will be applied in both of the situation. In the right context, Kanban will deliver dramatically improved value and velocity over explicit Scrum. After all, some companies have moved to single-unit engineer-to-order flow over small batches and realized dramatic improvements.

As I have been wrapping my brain around the distinctions and benefits, I keep coming back to Gerald Nadler’s book from the mid 1990’s, Breakthrough Thinking: The Seven Principles of Creative Problem Solving. Nadler had developed a meta-model for problem solving (solution finding) that has consistently delivered dramatic results. I am going to share the seven principles with you and then use them to talk about why I think the principles in Kanban can deliver results that are better than teams doing Scrum.

1. Uniqueness: Every problem is unique. You can’t directly copy a solution from elsewhere. Only if the context of the purposes shows it is useful should some available solution be considered.

2. Purposes: Always and continually ask the purpose. Then ask the purpose of that purpose. Expand as far as possible with this exercise. Focusing on purpose lets the uniqueness of the situation become clear and strips away nonessential aspects of the problem context.

3. Solution-after-next: Find solutions today that achieve the focus purpose, based on what might be the solution of the future. Having a target solution I the future gives direction to near-term solutions and infuses them with larger purposes.

4. Systems: Employ a format that includes all elements and interrelationships that the target solution will entail. Every solution or system is part of a larger system, and solving one problem inevitably leads to another. Understanding the elements and dimensions that comprise a solution lets you determine in advance the complexities you must incorporate into the implementation of the solution.

5. Limited Information Collection: Before taking the time and wasting the effort to collect and analyze extensive data, determine what purposes would be achieved by gathering the data. Study the solution, not the problem.

6. People Design: Throughout the process of finding a solution, give everyone who will be affected by that solution the opportunity to take part in its development. People are willing to explore purposes and solutions-after-next, rather than to gather data about what is wrong with the current system. Those who carry out and use the solution should be intimately and continuously involved in its development. Also, the proposed solution should include only the critical details, in order to allow flexibility for those who must apply the solution.

7. Betterment Timeline: Even as you design today’s solution, schedule future changes necessary to its continuous success. The only way to preserve the vitality of a solution is to build in and then monitor a program of continual change. A sequence of purpose-directed solutions and knowledge of the solution-after-next are bridges to a better future.

Scrum explicitly calls out several of these principles, particularly uniqueness, purposes, and people design. It provides direction that you should be looking for a way to remove impediments. It doesn’t explicitly provide guidance for doing that and a good, experienced manager is already applying many of the other principles. As I was telling Mike Cottmeyer this morning, a Scrum team in the right context will (and have) evolve into (many of) the Kanban practices.

Kanban explicitly calls out the rest of these principles. The Kanban itself becomes a framework for understanding the System and focusing on just enough information. The operations review is specifically in place to establish a betterment timeline and the solution after next.

Most of the Scrum teams dislike management and the other functional groups they interface with. The concept of pigs and chickens and the common perception that management causes obstacles for the team lead to conflict and distrust. Kanban focuses on how the development team can work better across the organization. From a purposes focus and people design standpoint, the Kanban perspective leads to greater trust and a shared focus on the solution-after-next.

Finally, many Scrum teams struggle with how to schedule defects and rework into their iterations. In the iteration world, QA gets the release after the end of the iteration for acceptance testing – this creates delay in feedback. This delay leads to all the relearning problems that we all have discussing. The enforced reduction in work in process and the single-unit flow reduces rework and shortens the time to feedback on defects and acceptance issues.

According to most reports, we still aren’t great a reliably delivering technology. No one has an answer yet that works for everyone. There is a lot of room for improvement and I believe we need to keep an open mind as we uncover better ways of developing software by doing it and helping others do it.

It’s the Agile Practioners that are not ready for the Enterprise

Posted on May 11th, 2009 by Dennis Stevens  |  7 Comments »

I spent last week in Miami at the Lean & Kanban conference. There was discussion (and twitter chat) about why Lean was better than Agile for the enterprise and how Lean and Kanban are different than Agile. But many of the distinctions were debatable because you can find Agile practioners that have adapted and inspected to include many of the Lean Software practices, including Kanban. I personally don’t see Lean and Agile as competitors. Lean is about improving flow through a value stream and Agile is about writing better software. Lean can help Agile teams perform better and realize benefits from agility at the Enterprise level. What was notable at the Lean & Kanban conference was the level of sophistication and maturity of the practioners that attended. These were experienced professionals focused on improving their organizations (and clients) ability to rapidly and profitably deliver value to their customers.

Big Agile Practices Survey

I gained some insight into the discussion about the distinction between Lean and Agile as I reviewed the results of Jurgen Appelo’s survey http://www.noop.nl/2009/05/the-big-agile-practices-survey-report-part-1.html into Agile practices. Agile is considered risky or even a pejorative by many Enterprises. Many executives don’t trust it as a mature or viable approach. The lack of trust that corporations have in Agile teams is not a reflection of “management’s” ignorance. It is a reflection of software teams failing to reliably deliver the software organizations and customers need. I have decided that the problem is not with Agile itself, it is in the level of process immaturity followed by many Agile Practioners.

For example, here are the practices that are not considered Agile in the Survey. The percentage reflects the number of practitioner’s who selected the practice as an Agile practice. Less than 50% means that the majority of the community does not consider it an Agile practice.

  • Configuration Management: 25.2%
  • Issue Tracking: 27.4%
  • Use Cases: 28.2%
  • Risk Management: 29.5%
  • Design by Contract: 32.2%
  • Software Metrics: 32.5%
  • Usage Scenarios: 37.9%
  • Code Reviews: 42.3%
  • Root Cause Analysis: 42.6%
  • Move People Around: 42.5%

The ones that jumped off the page to me were Configuration Management, Issue Tracking, Risk Management, and Software Metrics. Building Enterprise or commercial software without caring deeply about these items is problematic. An Agile team, who is interested in continuous delivery of valuable software pretty much has to care about these items. You can’t inspect and adapt without metrics and an understanding of your issues. You can’t continue to deliver the next release without configuration management. And Agile is all about Risk Management.

In fact, you hear people who believe that Agile is a no documentation, no planning, no requirements, and no control free for all. Apparently, many of these are Agile practioners themselves.  This is incorrect. Agile is a disciplined process that, when done correctly, helps companies improve their ability to reliably deliver valuable software to the business. So how does the immature implementation of Agile become so common? There are a lot of forces at work here.  I think the lack of “maturity” in many agile teams is the result of two different forces – the reaction to bad process and the local optimization problem.

A Reaction to Bad Process

Agile, at least partially, arose as a reaction to bad process. I think the pendulum has swung too far away from responsible software practices in response to costly and painful implementations of traditional big ceremony around things like risk management, issue tracking, requirements management, and configuration management. As a reaction, some Agilists believe that just enough, just in time documentation means no documentation. It doesn’t. Or that responding to change means no planning and no requirements. Not accurate. I got a tweet today that “By definition, agile programming dispenses with process.” What? One of the things that Agile is supposed to do is to eliminate the pain of big ceremony for its own sake and embed the purposes of these processes into your daily work. But a failure to understand the principles behind the practices leads to a large community (according to the survey – a majority) who don’t build software responsibly. Agile is a high discipline, introspective, continuously improving approach focused on delivering customer value. A reaction to bad process is not an excuse for no process, it is a basis for figuring out other ways to achieve the right purpose.

Local Optimization

Local optimization is the second major force. Local optimization is where one group focuses on improving its ability to do its job at the cost of the organization. Development organizations, like most functional groups, operate within their sphere of control. They can fall into the trap of believing that the business revolves around them. In an effort to improve development performance, Agile teams implement practices they have read about or experienced without understanding how they fit into the overall value stream. Gaps arise (i.e. configuration management) when there is a lack of clarity on responsibility across the value stream. Agile teams also don’t recognize the additional strain on other parts of the organization when they implement new Agile practices.  The only time you should subordinate one functional area for another one is to elevate or eliminate a constraint.  The goal of the organization is to improve the organization’s ability to profitably deliver value to the customer, not to get better at software development.  

Agile Practioners are Solving the Wrong Problem

When implemented maturely, Agile works to improve quality, fit, reliability, and responsiveness. The forces of reaction to bad process and local optimization result in Agile teams implementing not enough process or focusing on the wrong processes. The difference in (many) Agile practioners and Lean practioners is the problem they are solving. Immature Agile practitioners are focused solely on writing code better. This is important, but not a worthy goal in and of itself. Lean practioners (and mature Agile practioners) look at the overall value stream. They strive to identify the right process (and amount of process) while focusing on eliminating waste in the value stream.  The problems with Agile are not a problem with the principles and practices of Agile. It is a problem with the perspective and purpose on the part of many Agile practioners.