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

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

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

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

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

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

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

R_Part4_Table1

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

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

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

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

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

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

R_Part4_Figure1

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

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

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

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

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

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

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

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

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

satishgraphic

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

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

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

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

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

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

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

Guest post from David Nicolette, agile coach at Eliassen Group

Background

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

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

The Metrics

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

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

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

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

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

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

Collecting the Raw Data

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

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

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

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

 legos1

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

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

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

table2

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

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

lego image3

 

What we do with the information

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

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

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

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

chart4

Initial observations

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

1. Immediate reaction to impediments

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

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

2. Limiting WIP

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

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

3. Tracking unplanned work

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

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

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

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

4. Manager response

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

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

5. Micromanaging time?

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

Any comments?

Please let us know what you think below!

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

Top 10 Causes of Chaos in Agile Software Development

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

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

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


1. New Teams Forming.

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

2. Process Learning.

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

3. HEAVY Learning Mode.

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

4. Greenhorns.

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

5. When Quality is NOT Built-in.

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

6. Quality Automation Doesn’t Exist.

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

7. Lack of Cadence.

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

8. Unpredictable Release Cycles.

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

9. Deadline-Rich Environment.

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

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

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

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

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

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


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

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

Establishing a Sustainable Pace

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

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

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

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

Finding the causes of team pressure

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

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

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

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

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

Establishing sustainable pace

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

Possible actions that they can take are:

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

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

Collaborate with your stakeholders

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

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

Sustainable improvement

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

 

 

 

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

What’s Down With Agile Documentation?

Guest post by Ellen Gottesdiener and Mary Gorman of EBG Consulting

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

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

documentation-value-volume-relationshipProcess Versus Product Documentation

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

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

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

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

On Your Mark…

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

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

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

Sliding Along the Documentation Levers

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

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

sliding-along-documentation-levers

The Low-Down on Documentation

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

Don’t forget to leave your comments below!

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

 

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

The 4-Step Action Plan for Agile Health: Step 3: Understand how to use additional enablers of Agile Health

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

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

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

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

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

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

R_Part3_Table1

In Part 1 of this blog series, I used an example of a typical 4-week (20 workdays) sprint for the Struggling Agile Team.  Figure 1 illustrates the Sprint History Map of this 4-week sprint for the Struggling Agile Team after the sprint is over.   This Figure 1 is a revised version of Figure 1 of Part 1 as it shows the effects of two additional harmful behaviors, 5B and 6B, described below.

R_Part3_Figure1

Figure 1:  Sprint History Map of the Struggling Agile Team
suffering from 6 harmful behaviors

5B. Frequent impediments and non-availability of qualified team members:   With struggling agile teams, there is often no disciplined way to minimize and manage impediments.  Team members (especially contractors supplied by an off-shore vendor) are reluctant to bring impediments to the attention of ScrumMaster in a proactive manner.  ScrumMaster may have difficulty in removing organizational impediments.  More importantly, the team may not have the required training and norms to prevent or minimize the impediments in the first place by taking timely proactive actions to resolve issues to prevent them from becoming impediments.  As a result, the number of impediments experienced by the Struggling Agile Team is rather large (as shown by 9 impediments — marked as IMP – on the Sprint History Map of Figure 1).  Furthermore, impediments may take substantial time to be removed, which holds up the work.

As shown in the Sprint History Map in Figure 1, a rather larger number of 32 cells are marked as NT (No Team Member Available) events because of frequent non-availability of qualified team members.   These members may be busy on other projects or teams due to multiplexing, or busy with other features due to multitasking, or are interrupted by customer support work or customer demos.  Members that may be available are not qualified or ill-prepared to do work outside their area of expertise due to the silo mindset.

Although it can be argued that NT events is an example of impediments (as no work can proceed due to non-availability of qualified team members), it is important to differentiate between NT events from general impediments to understand the gravity of problems caused by non-availability of qualified team members and then take appropriate actions to correct or mitigate that problem.

As shown in its Sprint History Map (Figure 1), the Struggling Agile Team planned 8 features, but could complete only 4 features (Features 1 through 4).  Four features (Feature 5 through 8) could not be completed.

6B. Manual testing is the norm: For struggling agile teams, the level of automation for unit testing, acceptance testing and regression testing is non-existent or at best low.    This creates an untenable situation as evermore regression test cases need to be run within each successive sprint to ensure that the functionality implemented in all previous sprints is still working, i.e., hasn’t regressed.  This growing effort for regression testing for each successive sprint with the same number of QA testers in the team performing manual regression testing is simply not feasible.  As a result, many teams do little or no regression testing in each sprint as shown in Figure 1; that effort is postponed until the so-called hardening sprint.   Neither the team nor its customers or users are clear about the quality of each sprint release as there was little or no regression testing done.

In Part 2 of this blog series, I used an example of a typical 4-week (20 workdays) sprint for the Healthy Agile Team. Figure 2 illustrates the Sprint History Map of this 4-week sprint for the Healthy Agile Team after the sprint is over.      This Figure 2  is a revised version of Figure 1 of Part 2 as it shows the positive effects of two additional healthy practices, 5P and 6P, described below.

R_Part3_Figure2

Figure 2: Sprint History Map of the Healthy Agile Team
following 6 healthy agile-lean Practices

5P. Effective impediment management and full availability of qualified team members: ScrumMasters should develop and practice these skills:

  • Encourage team members to bring to attention issues in a proactive way
  • Resolve issues before they have a chance to become impediments
  • Recognize real impediments that team members simply cannot resolve on their own
  • Develop technical and organizational skills to resolve impediments quickly if they still occur
  • When an impediment stops work on a feature (should be rare event), the feature team members may be assigned to help other feature teams, instead of pulling a new feature to work on (which increases WIP)
  • Apply the 5-Why’s technique (see: http://en.wikipedia.org/wiki/5_Whys) to find and address the root causes for recurring impediments

As a result of this practice, the number of impediments is minimized and impediments are removed quickly when they occur.  Compared to the Struggling Agile Team’s 9 impediments (see its Sprint History Map in Figure 1), the Healthy Agile Team encountered only 2 impediments (see its Sprint History Map in Figure 2).  NT (Non-availability of qualified team members) events can be completely eliminated for the Healthy team as shown in its Sprint History Map (Figure 2) because full-time, dedicated, cross-functional team members swarm on features; they do not squander their time on multiplexing or multitasking.  As shown in its Sprint History Map (Figure 2), the Healthy Agile Team planned 8 features, and completed 7 features (Features 1 through 7). Only one feature (Feature 8) could not be completed.

6P. Test Automation: Evermore regression testing is required in each successive sprint to ensure that the functionality built during past sprints is still intact and has not been broken, i.e., hasn’t regressed.  Unit tests are automated by following the practice of Test-driven development, and acceptance tests are also automated.  These two classes of automated tests are added to build the growing automated regression test suite.  It now becomes practical to run ever larger number of automated regression test cases on Day 18 and 19 of a 4-week sprint by using computers (typically virtual machines) as shown in Figure 2.   Although it is not possible to automate every test case, such as usability testing that involves subjective judgment, a vast majority of test cases are automated by the Healthy Agile Team.

I recommend to gradually growing test automation expertise within each cross-functional team.   If you have to depend on the availability of test automation experts controlled by some group or department, you will be back to harmful behavior 2B of Team members working with a silo mindset.   These test automation experts will always be in high demand by multiple teams, and often will become a bottleneck.

By no means, the list of 6 harmful behaviors and the corresponding 6 healthy agile-lean practices presented in this blog series is exhaustive.   More Practices for you to consider: Build automation, Continuous integration, DevOps, Refactoring, Technical debt reduction, Spikes, Waste reduction to improve lean flow, etc.

Now let us take a holistic view of all 6 harmful behaviors to move away from, and 6 healthy agile-lean practices to adopt.

Six harmful behaviors feed on each other to create more harm:  When multiplexing and multitasking is common, team members get distracted and lose productivity, which reduces throughput and increases NT events (work cannot proceed due to non-availability of qualified team members) as team members get pulled off to work on other multitasked work.   When team members work with a silo mindset and don’t have skills or inclination for cross-functional work, there are many NT events.  When team members have no focus on completing the work already started, WIP goes up, cycle time goes up, and throughput goes down.  Lack of test automation (manual testing is the norm) also reduces productivity and makes regression testing almost impossible in each sprint, which reduces quality.     As a result of all these 6 harmful behaviors, the Struggling Agile Team could get only 4 features (Features 1 through 4) accepted in the sprint representing a velocity of 8 story points.  The remaining 4 features (Features 5 through 8) could not be completed within the sprint.  A struggling agile team may continue to struggle into a downward spiral, until and unless it starts moving away from harmful behaviors and start following healthy practices.

Six healthy agile-lean practices feed on each other to create increasing benefits:  When multiplexing is avoided and multitasking is minimized, team members increase their productivity due to single-team loyalty and by not wasting time on context switching, which increases throughput and reduce NT events.     As teams develop and use cross-functional skills, NT events reduce dramatically as at least one team member is almost always available to do any work (each member is a Master of One and Jack of Two).  As team members follow lean mantra of Stop-Starting-Start-Finishing, and work in a highly focused way, WIP goes down, cycle time goes down, and throughput and quality go up.   As manual testing reduces, and Test automation increases, it increases productivity and makes regression testing possible in each sprint, which improves quality.      Instead of struggles caused by harmful behaviors, an agile team starts experiencing an upward spiral of improved health and consequent higher productivity, throughput, and quality.  As a result of all these 6 healthy-lean agile practices along with the practice of sprint pipeline, the Healthy Agile Team was able to get 7 features (Features 1 through 7) accepted in the sprint representing a velocity of 15 story points.  Only one feature of 1 story point (Feature 8) could not be completed within the sprint.   6 healthy agile-lean practices synergize to create more positive benefits. Success feeds on success

Are any of the 6 harmful behaviors causing serious challenges and issues in your organization?   Are any of the 6 healthy agile-lean practices giving your team tangible benefits or of interest to you for your adoption?

I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

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

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

Part 4: Develop and implement your customized plan for adopting healthy agile-lean practices

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

The 4-Step Action Plan for Agile Health: Step 2. Understand how to adopt healthy Agile Mindset Practices and Lean Practices

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

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

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

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

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

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

R_Part2_Table1

“Agile Mindset” practices to improve agile health:  I now explain and recommend 2 specific practices to embrace an “agile mindset.”   I typify an agile team B that consists of a business analyst, 3 full-time developers, 2 full-time QA testers, a Product Owner and a ScrumMaster.   All members of Team B are full-time, dedicated members unlike the Struggling Agile Team of Part 1 of this blog series which had part-time, multiplexed members.   As Team B follows all 6 healthy agile-lean practices (1P to 6P) listed in Table 1, it is our prototypical “Healthy Agile Team”.

I use a similar example of a typical 4-week (20 workdays) sprint for the Healthy Agile Team.   Figure 1 illustrates the Sprint History Map of this 4-week sprint after the sprint is over.   It uses the same format and legend as used in in the Sprint History Map of the Struggling Agile Team (see Figure 1 of Part 1). Each feature was broken down into its implementation tasks either during sprint planning or actual sprint execution.  These tasks are indicated in the legend at the bottom of Figure 1.

R_Part2_Figure1

Figure 1: Sprint History Map of the Healthy Agile Team following the
Agile Mindset Practices

The 2 “Agile Mindset” practices (numbered 1P and 2P below) require replacing the legacy mindset with agile mindset, moving away from silo thinking, welcoming the change necessary for successful agile adoption and implementing the required change to get the benefits of higher productivity, throughput and quality.

1P. Full-time, dedicated agile team members without multiplexing and with minimal multitasking: Move away from the old mindset that treats people as resources whose utilization needs to be maximized via multiplexing and multitasking.   It is much more important that you maximize agile team throughput than worry about utilization of each team member as a resource.

Assign agile team members to work full time (100%) on a single agile team through all sprints of at least one release cycle.  You need at least a full release cycles (4 to 6 sprints) for team members to understand each other’s strengths and weaknesses, develop a (hopefully smooth) working relationship, and jell together as a team.  These well-jelled team members show higher productivity as they learn how to capitalize on each member’s strengths and compensate for weaknesses.  They learn to work with each other as human beings, and not replaceable resources.  This often requires a significant buy-in from management, if it is steeply rooted in traditional project management practices.

Cultivate the habit of doing focused work – one task at a time – starting with 30 minutes of uninterrupted work on a single task, and gradually extending it up to two hours.  Then you will need a well-deserved 5-minute break due to intellectual fatigue.  See The Energy Project: http://theenergyproject.com/  to understand how to conserve your energy to work in a highly focused way on single task at a time. Each team member learns to focus on a single task at a time (up to 2 hours in a stretch) until the task is over, before switching to other tasks.

Avoid multiplexing and minimize multitasking.  It increases productivity by avoiding wasteful context switching, and making each team member committed to and accountable for the success of a single team.  There are no divided loyalties of a person among different teams and projects.  That simply doesn’t work well.

2P. Cross-Functional Team Members: An agile team is composed of cross-functional team members: Train, cultivate and invest in each member to become a “Master of One and Jack of Two”.   Each member has primary expertise or mastery in at least one area, and working level skills in two other areas.  From time to time, each person is needed to work in areas outside his/her own mastery.  For example, a developer tests features developed by other developers, or a tester develops scripts for automated tests, etc.   See: http://bit.ly/1lkaXHc.

Investing in team members to become “Master of One and Jack of Two” may require a significant buy-in from functional or departmental managers.   Team members don’t just do their own tasks that match with their primary expertise or interest.  They swarm as a team to deliver working features within each sprint. Each feature is worked on by a logical feature team swarming to complete the feature in the shortest cycle time.  See: http://bit.ly/1rhtV6g.  Although the Sprint History Map for the Healthy Agile Team (Figure 1) shows swarming feature teams only for Feature 1 and 2 for brevity, they exist for all 8 features in the backlog.  These feature teams are “logical” teams in the sense that they may share one or more individual team members.

How to adopt two lean practices:  These 2 lean practices (labeled 3P and 4P in the list of 6 healthy agile-lean practices of Table 1) are described below.

3P. Stop-Starting-Start-Finishing and work under WIP limit: Form swarming features teams within an agile team to focus attention on getting each feature accepted by the Product Owner as soon as possible.  Without completing a feature or a task already in progress, resist the temptation to start working on a new feature or a new task.  Stop starting new things (features or tasks) before completing the things you have already started.  This is a good mantra for life too.   This practice will effectively allow a lower WIP limit in an informal way.

As explained by David Anderson in his book “Kanban: Successful Evolutionary Change to your Technology Business,” 2010, page 114, the WIP limit needs to be set up as 2 to 3 people per feature plus 2 to 3 to smoothen the impact of a blockage.   For an Agile team of 7 full-time, dedicated team members, the WIP limit can be set up as 3 + 2 = 5.   You will need to experiment with this number and adjust it empirically up or down based on the experimental results.  Progressively lowering WIP limits will bring out bottlenecks that need to be resolved.  Agile Lifecycle Management tools, such as VersionOne, help you visualize the Kanban workflow under WIP limits, and provide warnings if WIP limits are exceeded.  Learn how to work with smaller WIP limits.

As shown in the Sprint History Map (Figure 1), the WIPs on Day 2 through 17 (total 16 days) for 7 completed features (Feature 1 through 7) in the sprint are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 2, 2, 1, 1, with the average WIP = (46/16) = 2.875.    The WIPs on Day 2 through 17 (total 16 days) for all 8 features are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 3, 3, 2, 2, with the average WIP = (50/16) = 3.13, which is only slightly more than the WIP of 46/16 = 3.13 for 7 completed features.  The Healthy Agile Team has its focus on completing the work in progress before starting the new work by following the Stop-Starting-Start-Finishing mantra which reduces WIP.   The Healthy Agile Team has a smaller WIP compared to that of the Struggling Agile Team illustrated in its Sprint History Map (see Figure 1 in Part 1, and the WIP data for the harmful behavior 3B in Part 1).

4P. Focus on minimization of cycle time: Improve team’s throughput (features completion rate) with cross-functional team members, eliminate NT events by avoiding multiplexing and multitasking, and use of proper test automation tools (see Part 3 of this blog series).

Reducing WIP reduces the cycle time.    As shown in the Sprint History Map (Figure 1), the cycle times for the 7 completed features (Features 1 through 7) are 6, 8, 5, 7, 7, 8, 5 days, with an average cycle time of (46/7) = 6.57 days.   I will now use the well-known Little’s Law to calculate the average throughput (rate of feature completion and acceptance by product owner) of the Healthy Agile team.

Average Cycle Time = Average WIP / Average Throughput, or alternatively

Average Throughput = Average WIP / Average Cycle time

In the example of Healthy Agile Team, Average WIP = 46/16 (see Practice 4P above), and Average Cycle Time = 46/7 (as explained just above).

Therefore, Average Throughput = [(46/16) / (46/7)] = 7/16 features per day.

You may use the Sprint History Map (Figure 1) to visually verify that the Healthy Agile team has  delivered 7 accepted features (Features 1 through 7) in 16 actual work days of the sprint, confirming the average throughput of 7/16 features per day.  Sprint History Maps provide visual data for WIPs and Cycle Times, and visual verification of Little’s law.

The higher throughput of 7/16 features per day for the Healthy Agile Team (compared to the Struggling Agile Team’s throughput of 4/18 features per day) can be attributed to the facts that the team has moved away from harmful behaviors:  it has no NT events and substantially reduced number of  impediments (IMP events); it avoided multiplexing and minimized multitasking, gotten away from the silo mindset,  is practicing Stop-Starting-Start-Finishing lean mantra, has reduced long cycle times (average cycle time of only 6.57 days in a 16-workday sprint), and is practicing automated testing (as explained in Part 3 of this blog series).

Little’s Law is a powerful and versatile tool.  A change in any one of its parameters (WIP, Cycle Time and Throughput) is most likely to effect a change in one or both of the other two parameters.  You can reduce cycle time by reducing WIP while holding throughput constant.  Or you may increase throughput by decreasing cycle time as we have just seen.  There is a third option: a team may increase the average WIP (more work in parallel) and thereby increase the throughput, provided that the team can hold the average cycle time by increasing its intrinsic productivity by upgrading its skills via training and apprenticeship, getting more experienced members on the team, using various automation tools, increasing its design and code reuse, etc.   If any one of these 3 parameters needs to be corrected or improved, Little’s Law tells us exactly what to do to achieve the desired results.  Most of the time the goal is to increase throughput (without sacrificing quality) by reducing cycle time or by increasing team’s intrinsic productivity or both.   Bennet Vallet of Siemens Health Care presents a great case study of Kanban success providing the details of how to harness Little’s law to reduce the average cycle time, increase the average throughput and improve the release predictability.

Lean methods provide us additional options to reduce the cycle time, and thereby, increase the throughput.  Splitting large features into smaller features (they still must deliver value to customers) reduces the average cycle time.   How small should these features be?   Larman and Vodde suggest that for an N-week long sprint, each feature should take no more than N/4 staff-week of total effort (Reference: “Scaling Lean and Agile Development” by Larman & Vodde, 2009, page 120).  For the 4-week example sprint used in this blog series, it would be ideal if each feature takes no more than 4/4 = 1 staff-week or 40 staff-hours (or less) of total effort.  For a 2-week sprint, each feature should take no more than ½ staff-week or 20 staff-hours of total effort.

Furthermore, leveling the workload, i.e., having all features of roughly the same size also reduces the average cycle time.  Uneven sized sprint workload (small features intermixed with medium and large features in a sprint backlog) increases the average cycle time.

As shown in the Sprint History Map (Figure 1), the Healthy Agile Team has swarming feature teams; each feature team is working on multiple tasks of a feature concurrently.  For example, in the Sprint History Map (Figure 1), Software Design task (D) and Acceptance Test Development task (TD) were going on concurrently on Day 2, Code development task (C) and Acceptance Test Case execution task (TE) were going on concurrently on Day 4.  This swarming action also reduces the cycle time due to intense collaboration among the feature team members, their focus on completing the feature and getting it accepted as fast as possible.

Sprint pipeline: Learn and apply the Sprint pipeline practice where feature analysis and UI design work is done one timebox ahead of software design, coding, testing, defect fixing, acceptance testing.   This effectively allows two successive timeboxes for each sprint, but without adversely impacting throughput (it still produces working software at the end of each sprint).   With sprint pipeline, feature specification and UI design is in much better shape when a sprint starts, compared to trying to squeeze all work for a feature in a single time box where analysis or UI design may become bottlenecks.   In the Sprint History Map (Figure 1), there are no “A: Analysis” tasks at all, because the Healthy Agile Team is following the sprint pipeline well. 

Is your team facing the challenge of moving away from harmful “legacy mindset” and “non-lean” behaviors, and is interested in transitioning to the healthy “agile mindset” and lean practices?  I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

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

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

Part 4: Develop and implement your customized plan for adopting healthy agile-lean practices

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

An Open Letter to Executives Leading Agile Transformations

Dear Executive,

Let me congratulate you on your decision to introduce agile methods within your organization. It is a wise decision that holds incredible potential for your employees, your company, and especially your customers. If you are just beginning your improvement, or are yet to begin, the journey upon which you are about to embark is one that will be well worth the effort. And it will take effort—long, arduous, and at times frustrating effort.

Although Machiavellians do exist, my experience is that they are exceedingly rare.  In general, people are good, honest, and hard-working and really want to do the right thing. We hold a desire to do our jobs well, be recognized for it, and make a difference in the world by being part of something larger than ourselves; to have a purpose at work, if you will. To this end, we will do what is necessary to get our work done in the manner that our environment best supports. Put more simply, we will take the path of least resistance and complexity. Your move toward agility may be more challenging than necessary if you don’t keep this in mind while traversing your path toward improvement.

Rather than simply introducing and mandating agile methods such as ScrumeXtreme Programming (XP), and/or Kanban, create an organizational environment where agility is the path of least resistance for your employees and colleagues to get their work done. Here is a ten-step plan of action to help you create that environment within your organization.

  1. Stop referring to the change as organizational and/or agile transformation. We’ve all heard and understand the cliché that “change is the only constant.” Using phrases like agile transformation can shoot fear of the unknown into the psyche of everyone as it screams massive change. A less scary word is improvement. We all like to improve. Start talking about improving delivery, increasing customer engagement, and enhancing responsiveness to new challenges.
  2. Restructure your organization to reduce emphasis on functional specialization.One of the factors strongly contributing to the slow responsiveness of waterfall is the typical hand-off of work as it passes from the hands of one functional group to another—Business Analysts for requirements to Architects for design, to Developers for build, etc. Create teams that are cross-functional and require little to no hand-off of work. If so desired, create Centers of Excellence (CoE) organized around professional career ladders but remove reporting ties to any functional manager in the CoE.
  3. Start demonstrating the behavior you desire in your organization. One of the most powerful ways to build momentum is to first change yourself and your behavior. You really can’t force change within others, but you can inspire it. It’s amazing the change you’ll see in others when you first seek to change yourself. Actively seek ways you can serve the teams within your organization. With genuine curiuosity, caring, and empathy ask them what gives them headaches in their jobs. Be the aspirin for these headaches and remove the obstacles that are getting in their way. You might also consider working cross-functionally as a leadership team. Break down functional silos by creating teams that consist of representatives from many departments such as sales, marketing, IT, support, etc. The gears in any machine only work if cogs make contact and work collectively.
  4. For technology projects, refuse to move forward on any project without business representation and team involvement. Be uncompromising about beginning any project that does not have business representation. I was recently asked what I thought was the one thing that, if it did not exist, you could not consider yourself to be agile. This is that one thing—business involvement. If it’s not important enough to warrant business involvement, it’s not important enough to work on. Thank you, Samar Elatta, for this reminder because it’s so obvious it can easily be overlooked.
  5. Completely drop discussions of “resource allocation” and speak only of “team availability”. Agile is a team sport. The focus needs to shift from individuals to teams. Instead of identifying individuals within a functional specialty and percentage of availability to do work seek out only complete teams with availability. Also, don’t begin work with incomplete teams. Have all of the requisite skill sets available so you can avoid slowing them down with the burden that’s created to bring a new team member up to speed on the project.
  6. Increase your delivery cadence. The ideal situation is to be able to deliver at any time (or all the time, as in continuous). Take incremental steps toward this goal by reducing the delivery window by at least half. If you’re on a semi-annual (6-month) delivery cycle reduce it to quarterly. If it’s annual, reduce it to semi-annual; quarterly, release every six weeks. This will automatically require teams to focus on smaller increments of work instead of looking at very long horizon delivery windows that only serve to increase estimating complexity and uncertainty about scope of delivery.
  7. Give high praise for “complete” features only. The only features that provide customer value are those that are complete. Almost done features may have future value potential but they have zero value right now. Consider work either done or not done. There is no credit for work that is not 100% complete. Define expectations very clearly for what is meant by “complete”.
  8. Recognize entire teams. The best way to support teamwork is to value and recognize teamwork, especially in a public setting. Praise entire teams and avoid the temptation to call out individuals on the team that did an excellent job. While it’s true that some of them may well have went above and beyond, it’s dangerous to the cohesiveness of the team if you praise an individual. If you must mention names, mention the names of all individual members of the team. Only the team (those on the frontline of value delivery) has the credibility to recognize individual team members for their efforts.
  9. Don’t mandate a methodology at the team level. Rather than requiring teams to do Scrum, or any other methodology framework, put the ingredients in place for agility such as those described in points 1-8 above, provide and demonstrate your personal support and commitment to the removal of organizational obstacles and dysfunction, and stand out of the way. These people are professionals, they are smart, and are very capable. If not, why are they working in your organization? They will do what’s required to get the results expected of them, sometimes regardless of whether those results are even realistic. This is autonomy and is one of the incubators of the only form of motivation that is effective, intrinsic.
  10. Invest in your workforce and your teams and they will invest in you. I do not tolerate tales of woe about organizations experiencing a lack of worker loyalty when those same organizations refuse to invest in their workforce. When times get tough and the C-suite is getting pressure to show near-term stock price growth, drastic measures are taken to reduce costs. Unfortunately, these short-term measures such as workforce reductions, slashing benefits, and cutting investment in training usually have a negative long-term effect. Make decisions that will positively impact the long-term value of both your stock price and your organization (boths its viability and people). If you’ve created an unsustainable cost structure that requires drastic measures, then you obviously need to take some drastic measures. If you and your management team created it, admit it because your people probably already know it. They have great “BS” meters and will see right through any attempt you or your leadership team make at masking it. Demonstrating humanity through vulnerability and admitting personal fault may feel terrible but it will increase your credibility in the eyes of your constituents by orders of magnitude. If you create an environment that inspires workers to give their all, run a company that gives to the community, and demonstrates that it values its workforce by investing in them, you and your organization will have a much greater chance of competing in the marketplace for a long time to come.

I opened this letter by expressing my belief that people are generally good, honest, and want to do the right thing. I close this letter by restating that this belief I hold has only been reinforced through my personal interaction with a diverse group of colleagues throughout many organizations spanning a long career. I would like to affirm that this belief also extends to you, the organizational leader. I believe that you genuinely want to do the right thing, to contribute to something larger than yourself, and to support those around you to improve the quality of life for each of us.

With high confidence in your ability, personal desire, and integrity I urge you to create an environment within your organization that inspires those around you and that enables agility. The future of your organization is depending on it.

Posted in Agile Adoption, Agile Coaching, Agile Management, Enterprise Agile, Scaling Agile | Leave a comment

The 4-Step Action Plan for Agile Health: Step 1. Understand “Legacy Mindset” and “Non-Lean” behaviors to move away from

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

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

  1. Agile development “sprints” assigned to software development lifecycle phases: analysis, design, code development, testing and defect fixing, delivery and deployment activities are carried out in sequential “sprints.”
  2. Agile development “sprints” assigned to technology tiers: user interface tier, business logic tier and data management tier work are carried out in sequential “sprints.”
  3. Mini-Waterfall inside sprints: for example, in a 4-week sprint, week 1 is used for analysis and design, week 2 for code development, week 3 for testing, and week 4 for defect fixing, i.e., these activities (design, code development, testing, defect fixing) are sequential, creating a mini water fall; they are not concurrent as required by true agile development.
  4. Water-Scrum-Fall: Although design, code development, testing and defect fixing go on concurrently in each “sprint,” there is a fairly long Requirements Analysis phase carried out upfront prior to the first sprint by a group of business analysts producing a comprehensive Requirements Specification document; and at the end of the last sprint, IT Operations staff spends a fair amount of time in deploying the system in a production environment, often finding problems that are expensive to fix.

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

In this 4-part blog series, I focus on 6 harmful behaviors exhibited by agile teams and how to move away from them, and transition to 6 healthy agile-lean practices in order to get more benefits (improved productivity, throughput and quality).  I also present 4 specific steps to transition to healthy agile-lean practices.   Table 1 summarizes these 4 steps, and labels 6 harmful behaviors (as 1B through 6B) and 6 healthy agile-lean practices (as 1P through 6P) for ease of cross-referencing. Table 1 also indicates what is covered in each of the 4 parts of the blog series: In this Part 1 (highlighted in pink color), Step 1 – understand “Legacy Mindset” behaviors (1B and 2B) and 2 “non-lean” behaviors (3B and 4B) – is described. Parts 2 to 4 will be presented in the future.

R_Part1_Table1

In this blog series, I typify an agile team A consisting of a business analyst, 2 full-time developers and 2 half-time developers, 1 full time QA tester and 2 half-time QA testers, a Product Owner and a ScrumMaster.  Business analyst works with product owner to write and clarify feature specifications as part of Analysis tasks.  As you will see shortly, Team A exhibits all 6 harmful behaviors (1B to 6B) listed in Table 1; it is our prototypical “Struggling Agile Team.”

In this blog series, I use an example of a typical 4-week (20 workdays) sprint.  Figure 1 illustrates a Sprint History Map of this 4-week sprint for the Struggling Agile Team after the sprint is over; it is not a sprint plan projecting what will happen in future on each of those 20 days; this kind of plan would be a total anti-pattern for agile development.  In Part 4 I explain how to get information to construct a Sprint History Map as a visual metric for gaining critical insights that you can act on.  The 20 workdays of the sprint are shown as columns numbered 1 through 20 Figure 1.

The Struggling Agile Team completed sprint planning on Day 1 where the Product Owner rank ordered the sprint backlog of features.  In our example, the sprint backlog has 8 rank-ordered features (also called “stories”) shown under the backlog column in Figure 1.  During sprint planning, the Struggling Agile Team also estimated the relative effort of features in story points.  For example, Feature 1 is of 1 story point (indicated by “1, 1”), Feature 2 is of 3 story points (indicated by “2, 3”), and Feature 8 is of 1 story point (indicated by “8, 1”).  In this example the Struggling Agile Team planned 8 rank-ordered features representing a total effort of 16 story points.  Each feature was broken down into its implementation tasks either during sprint planning or actual sprint execution.  These tasks are indicated in the legend at the bottom of Figure 1.

R_Part1_Figure1

Figure 1:  Sprint History Map of the Struggling Agile Team suffering from
“Legacy Mindset” and “Non-Lean” behaviors

Two harmful “Legacy mindset” behaviors to avoid:   I have called these 2 behaviors as “legacy mindset” behaviors because they arise primarily from legacy habits and practices of old waterfall days, silo mindset, and resistance to cultural change needed for agile adoption to succeed.  These behaviors give rise to many difficulties in successful agile adoption and prevent the teams from getting full benefits of agile development.

1B. Multiplexing and Multitasking is common:  Members are tasked by management to work on multiple concurrent teams of the same project or even different projects.  The behavior is rooted in the traditional project management mindset of treating people as resources and attempting to maximize their utilization by assigning them to multiple concurrent projects or teams.  This behavior is further driven by the fact that most people are narrow specialists; they are assigned to do work in their specialization on multiple teams or projects, as there is usually a shortage of other people to do that kind of work.

It has been reported that a team member working on two concurrent teams or projects loses 20% productivity due to frequent context-switching.  A member working on 3 or 4 concurrent teams or projects may lose 40% or 60% of productivity respectively, due to frequent context switching (Reference: Quality Software Management: Systems Thinking, Gerald Weinberg, 1991).

Multitasking behavior is also common.  Team members work on several tasks of different features of a sprint that match their skills often concurrently (frequently switching from one task to other), or team members may be pulled away for production support work or customer demos.   Their work gets frequently interrupted by meetings, phone calls, people stopping by for discussions, as well as self-imposed urge to check and respond to emails and instant messages incessantly, and in general, due to lack of self-discipline to focus on one task at a time.   Like multiplexing, multitasking also diminishes productivity.  Unlike CPUs, humans are not well suited for multiplexed or multitasked work.  Unfortunately, the trend is to do extreme multitasking: doing work, web surfing, tweeting, “Liking” on Facebook, talking over phone, replying to email and instant messages, and eating…all concurrently.   Single-minded focus means “while eating, only eat with single-minded focus on enjoying food.”

Thus in reality, the Struggling team has at best 2.8 (not 3) equivalent developers with its 2 full-time and 2 part-time developers, and 1.8 (not 2) equivalent testers with its 1 full-time and 2 part-time testers.  The team members’ effectiveness and productivity is further reduced proportional to the degree of multitasking they may indulge in.

2B. Team members with silo mindset develop features in a “micro waterfall” manner:  Each member works on only specialized tasks suited to his/her expertise or interests.   Departmental silo mindset is common.  A developer is reluctant to test code written by other developers, a tester is not skilled to write automated acceptance tests, an architect is reluctant to get down into trenches and write code, a technical writer rarely does usability testing, etc.

A team is also likely to develop each feature in a sequential “micro waterfall” by performing the implementation tasks (analysis, design, code development and unit testing, acceptance test case development, acceptance test case execution, defect fixing, etc.) within the sprint timebox in a linear order.  Although the Sprint History Map in Figure 1 shows only three micro waterfalls (for Features 1 through 3) for brevity, all 8 features are developed in a micro waterfall manner.    In a micro waterfall there are very few concurrent activities.  As a result, in the first half of a sprint, most developers of the Struggling Agile Team are too busy and testers believe they don’t have much work to do until developers have completed all their work.  This picture reverses in the second half of a sprint; testers get too busy and developer don’t have much to do.

Two harmful non-lean behaviors to avoid: I have called these 2 behaviors as “non-lean” behaviors because they arise from not understanding the relevance and importance of key lean principles and practices.  Just like “Legacy mindset” behaviors explained above, these non-lean behaviors give rise to many difficulties in successful agile adoption and prevent the teams from getting benefits of agile development.

3B. Team members start new work without any focus on completing the work already started: Most team members eagerly start working on new features and tasks of their personal interest with almost total disregard to features and tasks that were already started and are still in progress (Work in Process).  There is no focus on completing the features and tasks they have already started.   After all, starting new features is more exciting work compared to fixing defects in features that were already started.  The less exciting work of completing the features already started and getting them accepted by the product owner gets short shrift.     Similarly, due to multitasking habits, starting a new exciting task within a feature is much more tempting, leaving many “boring” tasks unfinished until the very end of the sprint timebox.

As shown in the Sprint History Map of the Struggling Agile Team (see Figure 1), the Work in Process (WIPs) on Day 2 through 19 (total 18 days) for 4 completed features (Feature 1 through 4) in the sprint are 4, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 3, 2, with the average WIP = (68/18) = 3.77.  However, the WIPs on Day 2 through 19 (total 18 days) for all 8 features are 3, 4, 4, 6, 7, 7, 7, 8, 8, 8, 8, 8, 8, 8, 8, 8, 7, 6, with the average WIP shooting up to (123/18) = 6.83, i.e., almost 7 features (out of 8 in the backlog) being worked on by the team in parallel!   The Struggling Agile Team does not have the required focus on completing the work in process before starting new work.  As a result, at the end of the sprint, only 4 out of 8 features were completed by the team and accepted by the product owner.   Sadly this Struggling Agile Team claimed that the remaining 4 features (Features 5 through 8) are “almost done” while in reality they took considerably more time in the next sprint to complete.  With proper coaching and experience the team learns that a feature is either 100% Done or Not Done, and there is no such thing as “Almost Done” or “98% Done.”  It is very binary.

4B. Work within a sprint proceeds oblivious to feature cycle time:  Feature cycle time (cycle time in short) is the total end-to-end time starting from when team members pull the feature from the sprint backlog to work on until the feature is accepted by the product owner after it passes the acceptance tests.   In Figure 1, cycle time for Feature 3 is 18 days, i.e., day 2 through 19 of the 4-week sprint.  Cycle times for the 4 completed features (Features 1 through 4) are 16, 17, 18, 17 days, with an average cycle time of (68/4) = 17 days.  This Struggling Agile Team is unaware of the importance of reducing the average cycle time, and could not complete 4 features within the sprint timebox due to their long cycle times.

I will now use the well-known Little’s Law to calculate the average throughput (rate of feature completion and acceptance by product owner) of the Struggling Agile Team.

Average Cycle Time = Average WIP / Average Throughput, or alternatively

Average Throughput = Average WIP / Average Cycle time

In this example, Average WIP = 68/18 (see Behavior3B above), and Average Cycle Time = 68/4 (as explained just above).

Therefore, Average Throughput = [(68/18) / (68/4)] = 4/18 features per day.

You can use the Sprint History Map (Figure 1 ) to visually verify that the team has delivered 4 accepted features (Features 1 through 4) in 18 actual work days of the sprint, confirming the average throughput of 4/18 features per day.

This low throughput is caused by the fact that the team is new to agile (low productivity due to learning curve), and also due to its own harmful behaviors:  it lost productivity due to frequently non-available members (NT events) and due to impediments (IMP events) marked in Figure 1.  This is explained in Part 3 of the blog series.  Also due to multiplexing and multitasking, silo mindset, no emphasis on finishing the work that was already started, long cycle times (average cycle time of 17 days in an 18 workday sprint), and manual testing (as explained in Part 3 of this blog series).  The Struggling Agile Team could not do any regression testing within the sprint due to its practice of mostly manual testing.  This is explained in detail in Part 3 of the blog series.

When Features 5 through 8 are completed in the next sprint (if that were to happen), it would be possible to consider the WIP on every day of two consecutive sprints for these 8 features and any new features started and completed in the next sprint, and also consider the cycle times for these 8 and new features over two sprints to calculate the average throughput per day over two sprints by following the procedure above.

The Struggling Agile Team failed to recognize the need for limiting the WIP and lowering the cycle time.  Large average WIP means large average cycle time, which increases the risk of many features not being completed and accepted within the sprint timebox.    The Struggling Agile Team is simply oblivious to the implications of Little’s Law.

The Struggling Agile Team attempted to do all work for each feature (shown in Figure 1 as A: analysis, D: Design, C: Coding, TD and TE: Acceptance Test Develop and Execution of QA tester, DF: Defect fixing, AT: Acceptance testing by product owner) in the same single sprint timebox as this workflow is simple to understand and to follow.   However, this behavior created many adverse effects as the answers to some analysis questions raised by team members could not be available immediately; a product owner had to talk to customers or senior management to seek clarifications, and those answers took too much time to complete all development within a tight sprint timebox.  As user interface design work could be tested only through working code, the feedback cycle was too long to correct the UI issues in the same single sprint timebox.  Analysis and UI design work, and associated clarifications and corrections for certain features took too much time to complete the feature within a single sprint.  What the Struggling Agile Team failed to recognize was that Analysis and UI design work had become bottleneck hampering the overall flow and increasing the cycle time; but the team didn’t know what action to take to remove the bottlenecks.

Is your team experiencing the harmful legacy mindset and non-lean behaviors, and looking for solutions?   I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

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

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

Part 4: Develop and implement your customized plan for adopting healthy agile-lean practices

 

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Metrics, Agile Project Management, Iterative Development, Kanban, Lean, Lean Software Development, Scrum Methodology, Scrum Software | Leave a comment

Make Agile 2014 PEACHy

This year, I’m excited to be returning the Agile Conference. Having organized and participated in the conference from 2001-2005, my attendance became sporadic as the beginning of the youth football season (my other coaching gig) won out over the annual agile pilgrimage. Preparing for the show brings back many memories, but also some lessons learned that I wanted to share for anyone new to the conference or looking to get a little more out it. In true agile form, I’ve made a pithy acronym. Follow these suggestions and after the conference, you’ll be saying, “That’s a PEACH, hon!”

Prepare
The Agile Alliance Agile2014 Pre-Conference Planner is a great resource for planning your conference activities. Obviously, you’ll get the most out the conference if you review the sessions and target the sessions you don’t want to miss (MoSCoW anyone?). For your most important sessions, check out the room size. As part of a commitment to an open learning environment, the conference does not reserve seats, nor limit your ability to participate. The most popular sessions will fill their rooms, leaving some standing or not able to attend. In your conference guide, you can get a sense of the room size. If your must-see session is in a smaller room, GET THERE EARLY!!

There is great content to choose from. Pick your targets, but include one or two sessions that are out of your box and may give you empathy for someone else’s kind of work. If you need ideas, check out these sessions being given by the nearly 20 speakers from VersionOne and our partners:

VersionOne: Matt Badgely, John Krewson, Steve Ropa
agile42: Richard Dolman, Martin Kearns
Cognizant: Raje Kailasam
DavidBase: Jeffery Davidson
DevJam: Matt Barcomb, David Hussman
Improving: Ken Howard
LeadingAgile: Mike Cottmeyer, Derek Huether
Lithespeed: David Bulkin
SolutionsIQ: Daniel Gullo, Tim Myer, Dhaval Panchal, Charlie Rudd, John Rudd

Engage
The conference can be overwhelming with tons of people, tons of sessions, tons of exhibitors (read: free stuff!), tons of activities. Sensory overload. So pick your focus , but try at least one thing that will stretch you a little, socially and intellectually.

If you are new the conference, I highly recommend the First Time Attendee Orientation. At that session you’ll see everyone else who is wondering about the things you are and then some. The Early Registration Meet & Mingle and Ice Breaker Reception (Moscow mule, anyone?) is another great way to start the week. Between sessions, look up from your screen enough to meet some new folks and hang out. Dinner with New Agile Friends is a great way to meet people, especially if you are not attending with a group of colleagues. And, of course, the Conference Party should not be missed.

Don’t miss the Sponsors reception and the booths through out week. Check out our @VersionOne mobile photo challenge on Twitter where you can win daily prizes or a GoPro HERO3+.

Adapt
You’ll learn new things about the conference as you go through it. Your time is the most valuable thing to manage, with perhaps sleep a close second. Use the Open Space Law of Two Feet to adapt what you do. Is a session not quite what you expected? Don’t be shy, get up and move on. Take the time to find another session, hang out, catch up with those incessant emails and posts, or just take a breather (or nap)

Collaborate
You develop deeper understanding by interacting with others. The conference favors interactive sessions, but there are many other ways to share and learn. Be sure to swing by the Open Jam and catch the latest buzz. The Scrum Alliance is holding a Coaches Clinic each day where you can share ideas and challenges with Scrum experts. Our conference organizers, the Agile Alliance will have the Agile Alliance Lounge open each day.

And if you see any of us VersionOne folks, in our sporty shirts, please stop us, introduce yourself, and mention what a wonderful blog post this is. We love agile and learning by sharing with others.

Hangout
The most valuable experiences I hear about are the interactions people have hanging out in the hallways. These by-chance encouters lead to amazing insights and relationships. If you are are an extrovert, this will come naturally. If not, here are a few tips:

  • The Agile conference has always been known for its community atmosphere and approachable speakers and attendees. Its kinda who we are. So, realize that you are in an environment that specifically values Individuals and Interactions.
  • It may be awkward at first. Yes, it can feel very weird to approach someone you don’t know and initiate a conversation. Work to overcome that fear (for the XPers and Scrummers, this is living up to your Courage value). Asking about a favorite session or the basics like what one does in their job are simply ways to get a conversion started.
  • Don’t give up. Not every encounter will be amazing. If a conversation does not take off, no worries, the next one prpbably will.
  • Approach a group. If you hear a small group talking about a topic of interest to you, don’t hesitate to approach, express your interest in the topic and join in. You’ll be well received and add another interesting perspective to the dialogue.
  • You probably know more than you think. Many attendees have told me after the conference, “you know, from our experience, we know as much as most of the people at the conference.” If you are feeling intimidated that others seem to know more than you, realize that either a) they don’t and are just more comfortable talking about what they know or b) were in your shoes just a few years ago and are passionate about helping you learn what they’ve learned.

Do you have recommendations for conference goers? Please share them by commenting below.

Have a great conference. I hope our paths cross during the week.

Posted in Agile Coaching, Agile Development, Agile Management, Agile Portfolio Management, Agile Project Management, Extreme Programming, Kanban, Scaling Agile, Scrum Development | Leave a comment