Agile Change or Adoption Always Starts with Why

Your organization has decided to become more “Agile.” Why? As we learned in a previous blog post, “Because Our Competitors Are” is not a valid – or sensible – reason. Before embarking on a change, adoption, or improvement program, you need to know the rationale behind that decision. So… why Agile? A traditional approach to answering this question might see the executive team going off-site for two to three days and holding a workshop where they decide why they should be Agile, then design an adoption strategy, and then summarize the whole thing in a few sentences to be sent out in a memo. Typically, large-scale change initiatives have a lot more ceremony, more meetings, and more setup than this. However, there are several key failings, including that they involve only a select few executives in the envisioning and decision-making process, and they attempt to plan for the long haul. There are dozens of examples in our industry of failed change efforts that have cost billions of dollars and proved that this approach doesn’t work. At Nokia, Stephen Elop issued the famous ‘burning platform’ memo in 2011, and yet two years later the company was sold to Microsoft. In 2013 Avon had to write off $125 million[1] of work that built an enterprise software implementation which drove representatives away. This was change that failed to help the very people it was intended for. These and other failures involve some combination of the following: Why – The “Why” isn’t understood by most of the victims of change. Strategy – The “Strategy” created by the executive group doesn’t make sense to all of the people doing the work. Ownership – People at the edges of the system (who do most of the work) feel no ownership of the change. Connection – The strategy doesn’t appear connected to the problems that the people at the edges of the system are experiencing. Improvement -The strategy appears to improve the lot of the executives, but not of the doers. Culture – The change doesn’t fit the organization culture. Leadership – Top level is asking for change but doesn’t appear to be involved in making it happen. To be effective, Agile organizational change needs to… well, involve the Organization! Not just the executives who have made the decree, often without fully understanding what the goals of the change are. This shouldn’t be a quick decision made at a two-day corporate retreat. It needs to be an ongoing effort to figure out the “why” collaboratively and share it effectively, being mindful of some essential ingredients. We will address those ingredients in the next several blog posts. Avon’s Failed SAP Implementation A Perfect Example Of The Enterprise IT Revolution – Ben Kepes: http://www.forbes.com/sites/benkepes/2013/12/17/avons-failed-sap-implementation-a-perfect-example-of-enterprise-it-revolution Image attribution: http://photodune.net/

Simplicity

In 201x, the global financial markets collapsed. Reason: mortgages were given to people who couldn’t afford them. This debt was then repackaged and sold to banks and other institutions as good debt. (“The Big Short” by Michael Lewis is an excellent indictment of this time). However, the bigger question remained. Why didn’t the financial regulator system catch the problem early, while it was still small? The answer? Complexity. In “The Dog and the Frisbee” (pdf), Andrew Haldane, Executive Director Financial Stability at the Bank of England, explains all the things a dog would have to know and understand to catch a Frisbee: wind speed and direction, rotational velocity of the Frisbee, atmospheric conditions, and gravitation. It might require a degree in physics to know how to express the control problem involved in catching the Frisbee. Yet dogs, without physics degrees, do this everyday. They obey a simple rule/heuristic: “run at a speed so that the angle of the gaze to the frisbee remains constant”. Empiricism and Simplicity. Agile works because it is an Empirical process using constant feedback to update both the work itself and the way we work. Haldane goes on to show that the financial regulatory system evolved from something simple that many people at a bank could understand, to something only a few people could understand. Eventually it became so complex that no one person understood the system as a whole. The earlier regulatory frameworks worked well in part because many people understood, and therefore many people could spot problems early, before they got too complicated and large to resolve. As we deal with ever-larger organizations, it’s tempting to say that this increase in complexity is okay because we’re larger. But if financial crisis taught us anything, the answer should be no. The bigger the system, the more important it is to use simple control mechanisms, simple feedback loops, and simple measures that can be understood by all. Decreasing complexity – not increasing it – has to be at the heart of all of our decisions. And coupled with that has to be the ability to respond quickly and change appropriately.   Image attribution: damedeeso, via photodune

“Because Our Competitors Are” is No Reason to Become an Agile Organization

Companies are starting to fall into a trap, and it goes something like this, “Our partners/competitors/… are Agile, so we need to be Agile.” Becoming Agile without a valid reason will harm your organization. I can’t state that any simpler. In the ‘80s and ‘90s, rival manufacturers often visited Toyota plants, and Toyota was delighted to welcome them, because Toyota understood that even if their competition copied company practices, practices change. What competitors weren’t copying was the culture that created the practices in the first place, and that’s where the real value was. Thus we had Cargo Cult Lean at many North American manufacturers, and it didn’t produce the results that companies were hoping for. We’re seeing that again with Agile. It’s not enough to become Agile and to copy Agile practices simply because your competitors are. Unless you develop a culture that creates its own practices, this will lead only to Cargo Cult Agile, and not a true Agile Organization. What competitors weren’t copying was the culture that created the practices in the first place, and that’s where the real value was. So what are some valid reasons to become Agile? One of the primary ones is to be able to readily adapt to a changing environment. Other reasons include: Resilience; Predictability; Risk Reduction; Morale and Retention; Early ROI; Predictability; Customer Satisfaction and Simplicity. Consider how Blockbuster adapted to online video, or how the taxi industry is responding to Uber/Lyft. Control-focused organizations struggle to adapt rapidly enough to survive, compared to their competitors who embrace change. Traditional/hierarchical organizations work well when problems are clear and solutions are repeatable but, unfortunately, those that thrive in those conditions are fragile when the situation changes and they can’t adapt. The structure of traditional organizations is one which evolved in a world where the pace of innovation and change was much slower. Changes could be spotted years out, and a response could be crafted and the organization would do well. That world no longer exists. Whole industries die in only few years if their response to change isn’t rapid and flexible. Which is where Cynefin can come in to the conversation. Cynefin Cynefin is a way of understanding the problem domains in which we find ourselves, and identifying which tools would be appropriate in response. At first blush it can look a little daunting, but bear with me and you’ll see that it doesn’t have to be. It’s merely a matter of “cause and effect”, and how simple or complicated that plays out within the context of your organization. The Cynefin Framework breaks down into 5 different domains to describe different types of relationships between cause and effect – from straight-forward, to complicated, to non-existent. The first of these is, well, Obvious. Obvious (formerly called Simple) is just as the name suggests. These contexts are clear to all involved. If X, then Y. At any stage in a process, it is clear what the next steps are. Examples are aspects of banking (interest calculations), insurance (calculation of premiums), etc., Organizations in this realm gain value from a degree of structure to ensure that people follow the rules. Standard practices apply here. A simpler example? Let’s talk about growing things. Develop your green thumb. In an Obvious system, we have a sponge. If you apply water to it, it will swell and grow. Cause and Effect in its simplest form. Sponge + Water = Bigger Sponge. That’s Obvious. The next domain is a little less so. Complicated is where the relationship between cause and effect is harder to see. It requires analysis and, often, expertise to find and understand the relationship(s). Once understood, “best practices” can be developed in this domain. To return to the growing analogy, this is the system where we’re growing one plant in a pot, which is considerably more complicated than growing a sponge, but there is still logical cause and effect involved. Seed + Soil + Water + Sun + Food = Plant. In this world, there are rules of thumb (green or otherwise) and best practices. It’s important to note that one of the risks of a Complicated Domain is that we listen only to the experts. It’s vital that we also factor in our own observations and environment. The next domain is more Complex and, in these contexts, cause and effect relationships are only understood in hindsight. Given the unpredictability of this domain, we’re better off probing, sensing and responding instead of trying to control or plan. Instead of looking for complex solutions, seek simple rules or heuristics to help work well in this environment. Trying to help grow our kids is an example of the Complex Domain. We ask them to do something (probe), they respond (sense) in an unexpected way. It’s only in retrospect that we can see why they responded that way. Next time, we adapt (our response), changing the phrasing/tone based on our new understanding of them. Complex domains require many diverse viewpoints to help solve. Although challenging, they’re still much easier to navigate than Chaotic. In Chaotic Domains, there is no relationship between cause and effect. Emergency/disasters are examples of the Chaotic domain. In these cases, the goal is simply to try and bring them back from Chaos to the world of the merely Complex. We don’t often see this domain in the business world, so we’re not exploring it here. And the fifth and final domain is Disorder, which exists when it hasn’t yet been determined what the cause and effect relationship is.  It’s in this state that people are most apt to make decisions based on their own comfort zone. These days, businesses are usually working in Complex Domains, which means that traditional, old-school approaches aren’t realistic. We can’t afford to have the DNA of Simple organizations persist, if organizations want to thrive in this new, rapidly-evolving world. So we need to create organizations that can adapt – and even thrive – in a Complex world, and help Simple and Complicated […]

Taking Organizational Improvement Seriously – Case Study

(Presented as an accompanying case study to Part 4 in the Scrum Alone is Not Enough series.) In the previous post, we discussed how it’s not enough to practice Scrum at the Team level and expect that it will solve all problems. Senior Management has to get involved for real Agile change to happen and high performance to be achieved. An important aspect of that is Systemic Problem Solving, which we’ll look at closer using the World’s Smallest Online Bookstore as a case study for examples. Systemic Problem Solving Most teams that I encounter are very good at solving specific problems locally (at the team level). What is missing is a bigger picture, holistic view. Systems thinking (pdf) is a tool that helps you take a Systemic – or bigger picture – view of whole systems. Let’s look at a couple of common organization problems as examples – namely “Long Regression Cycles” and “Product Owner can’t seem to stay focused on the big picture”. Long Regression Cycles Hereafter: LongRegressionCycle The Org Team recognizes that it has a problem with the regression cycles as illustrated: When long regression cycles are an issue, without a systemic approach the organization might first try adding more people to do regression testing. As a second step, they might try automated testing through the browser/GUI using a special team who has access to an expensive tool. Unfortunately, as we see below, this will likely lead us down the wrong path: This is a simple causal loop diagram –it’s intended to help us look past the initial problem and see deeper causes. Variables create cause and effect within a system. In a causal loop diagram, you start with a single part of the system that you can already identify and just keep asking “what influences this part?” then draw links between the interconnected parts using arrows pointing in the direction of influence. Once you can no longer think of additional parts or influences to add, you have a closed loop. In this example, we can envision what may happen by playing through the loop, starting at “Features added” and following its influence to the “Regression Cycle Length”. Keep going, and we can see that the often-used simple fix of asking a special team to automate regression tests through the Browser/GUI influences many variables and eventually exacerbates the problem that it was intended to solve. The diagram makes it clear that GUI based automation is fragile, and having all the work done by a special team is creating an island of knowledge. These two problems combine, increasing the time it takes to find bugs and eventually even increases the number of bugs themselves. To solve the underlying initial problem, we would have to also find an approach that doesn’t recreate these same issues! Instead of a special team doing all of the test automation, the work should be done by every team. Instead of doing all the automation through the browser, do most of it through public api’s (or their equivalent) that exist at the boundaries of the system. Before making any change, the team creates a new version of the causal loop diagram to see if their proposed solution is an improvement on the original. Product Owner Can’t Stay Focused on the Big Picture Hereafter: UnfocusedProductOwner In a second example, the Team sees a Product Owner making frequent revisions to the Team’s work in Sprint. We can talk to the PO about this, but we can’t just expect the PO to change unless we also identify and fix the underlying problem. As this image illustrates, we can see that the real problem is that the PO is under daily pressure from stakeholders to solve real and perceived customer problems. The challenge is how to set aside enough time to deal with those issues, while still making progress in the bigger goal. A causal loop diagram like this should help the organization discover the need for Portfolio Management, which would give the Product Owner some boundaries on how much short term work they should accept from the Team. In each case, the key point is that the Org Improvement Team must make sure that they’re solving the systemic – and not just surface – problem. So let’s look at how the World’s Smallest Online Bookstore teams might do that, using a Scrum-like framework to achieve it. Our World’s Smallest Online Bookstore Organizational Improvement Team is working in two-week Sprints to stay in sync with their Development Teams. As we learned in this post, the Org Improvement Team operates in a manner similar to a regular Scrum Team, just with a few slightly relabeled components. Let’s see how the Organizational Improvement Team will tackle these problems. Organizational Improvement Queue (aka Product Backlog) Since the causal loop diagrams above showed us that creating special teams for test automation and simply asking the Product Owner to change weren’t going to solve the problems. The Org Team can avoid wasting time on ineffective, localized solutions and focus the Improvement Queue on finding specific things that will contribute positive systemic results. Such as: LongRegressionCycle – Involve more members of each Development Team in test automation; LongRegressionCycle -Find alternate means to test automation that don’t involve the browser; UnfocusedProductOwner – Support the Product Owners in saying no to more expedited customer requests… Organizational Queue Refinement (aka Product Backlog Refinement) After discussion with the Development Team representatives and the Team level Product Owners, it is agreed that the pressure that the POs feel to respond to all customer issues within two days is getting in the way of the Teams delivering on both quality (which leads to more customer issues) and the big picture. They also identify the need for site license JetBrains IntelliJ and “Reducing Product Build Times from 15 minutes to 5 minutes”. Sprint Planning The Org Improvement Team commit to running several experiments to resolve the UnfocusedProductOwner challenge. Since this problem will need several months to address completely, they decide to do the following: […]

Red, Yellow, Green or RYG/RAG Reports: How They Hide the Truth

What is Red Yellow Green? Red-Yellow-Green (or Red/Amber/Green) is a status reporting mechanism used to help executives understand the current state of a project. Green means everything is good; we’re on track both with time and budget. In some cases, green means within 5% of budget. Yellow means there is some risk that there are scope or time problems, but with sufficient re-planning we can come back to target. Yellow is usually measured by some number crossing a predetermined threshold. Red indicates the project is in serious trouble. Models RYG is just a model of reality (in truth, all reporting simply models reality). All models hide details with the goal of making the situation easier to read and understand. Some are hidden so much that the truth gets lost. A team’s Task Board, Scrum Wall, or the overall Portfolio Kanban Wall are all first-order models of reality. While not perfect mirrors of the current state of the work, they’re fairly close. They help demonstrate qualitative information; i.e. which stories are complete, not just how much. A Release Burndown Chart, Burnup Chart or Cumulative Flow Diagram are all second-order models of reality. In other words, they summarize information contained on the Walls/Task Boards. They’re useful because they help spot trends. The Cumulative Flow Diagram provides the most information on trends, but it still has less information on it than the Portfolio Kanban. Red Yellow Green Reports are models of the charts, in that they summarize the charts, hiding even more informational details. They assume that a plan’s scope, budget, and time are fixed and unchanging. Models might be adequate in a world where these are true, but in a world that accepts change as the norm, colour-coded reports are dangerous. At best, these reports don’t measure truly done so much as whether a team is on track to make a target. In addition, since RYG reports usually have green as a default state, often there are too few questions that are asked until it’s too late. Charts Even burndowns, burnups, and cumulative flow diagrams are imperfect because they focus on output (# of Stories or story points achieved) and not outcomes (the right features delivered to the customer.) Charts of all forms appear to promise certainty, when there isn’t any, which creates a false sense of security. If we’re going to chart at all, we should use forecasts and not precise lines, and make it clear this a forecast. If your chart just shows the average velocity, then you should provide a forecast that says we have a 50% chance of achieving this rate for the foreseeable future. If you want to get more sophisticated, you can track error bars as well. Measure your best and worst three Sprint’s Velocity in the last six months, and use these as your 20% and 80% confidence bars. Then you can say that you’re 80% confident you will do at least as well as your worst three sprints, and 20% confident that you will do as well as your best three sprints. Even this model has a weakness in that it assumes your velocity will follow normal distributions. The reality is likely that it won’t. However, forecasting with error bars (or lines) usually gets the idea across that we’re forecasting a range of possible outcomes. Genchi Genbutsu Finally, all reports discourage people from leaving their offices. They give us the false feeling of safety. The report seems real and so it gives a good model of what is actually happening. Toyota has the practice of Genchi Genbutsu – go and see, literally. Review the charts but then leave your office and go to the place of the work. Watch, listen, ask, and review the Portfolio Kanban wall with the team(s). This will bring you back in contact with the reality of which features have been truly done. This will help you see if all the Story Points in the charts delivered the value that they claimed. Stop/Do So stop using RYG reports. They hide too much information. Do use Burndowns/Burnups/Cumulative Flow diagrams as a tool to help you spot trends, but don’t rely on them alone as the source of truth. And most importantly, review the Portfolio Kanban Wall with the Team(s) on a regular basis, as this is our best measure of reality. http://www.drdobbs.com/dr-dobbs-agile-newsletter/191600661 Other have taken up on it as well: http://www.solutionsiq.com/greenshifting-and-redshifting-within-projects/ http://www.edmundschweppe.com/2013/12/the-green-shifting-anti-pattern/ http://calleam.com/WTPF/?p=1205

Scrum Alone is Not Enough

To be successful with Scrum in the long term you need more than the basic framework. This is intentional. Scrum provides the structure as a starting point, but it’s designed to work well when applied with other effective patterns. Like the Design Patterns movement of the late ’90s, a pattern can be used by itself or with others. E.g. the Command Pattern and the Memento Pattern can be combined to build an effective undo/redo system. Scrum is only one pattern for one team. It gives you the bare minimum framework that could possibly work, however in many contexts you will need to incorporate other tools/patterns to build more effective systems. Beyond Scrum you should consider: –       Effective Agile Engineering Practices – such as Unit Testing, Continuous Integration, Test Driven Development, Acceptance Test Driven Development (or BDD), Pair Programming. Without practices like these, the health of your codebase will degrade over time. –       Kanban – (a tool to understand and improve flow) to help understand the flow of work at both the team and organization level. Without a good understanding of flow of work through the organization, we might make a change that is a local improvement but harms the whole. –       Portfolio Management – the art of making big picture decisions about which major chunks of work the business would like focused on next. Organizations need portfolio management to ensure that major priorities are understood by the team’s Product Owners and worked on in priority order. –       Organizational Improvement – many issues that Scrum helps to find can’t be solved by the team or their ScrumMaster. Instead, organizations need to establish an ongoing improvement team dedicated to resolving these problems. –       Intra Team Coordination – How will you coordinate the work among teams? Scrum of Scrums is the most well known pattern and yet is rarely the best choice. –       Team Organization – How will you organize your teams? As Component Teams? As Feature Teams? Using the Spotify model of Squads, Tribes and Guilds? There are no best practices. Scrum itself could prescribe all of this, but that would be missing an important Agile point: there are no best practices. A practice that works well in one organization (or context) may not work well in yours.  This is especially true when it comes to working effectively at a large scale where repeatable patterns are only just starting to emerge. Even where consistent patterns are starting to emerge (i.e. Large Scale Scrum, Enterprise Scrum, …), it is often unclear which one will apply in a specific context. Finally, remember that Scrum isn’t intended to fit your current organization and its existing structure. It is intended to force us to consider what is working and what needs improvement. Scrum is just the starting point.   In the next few months, I will explore patterns that can be effective when attempting Scrum at a larger scale (more than three teams). What topics would you like me to explore?

Welcome to the High-Performance Teams Game

Your team is working on the World’s Smallest Online Bookstore, a site that provides the best results (just a few) for every search, not every result on earth. We’re a vulture capital funded company, so if we don’t deliver, our funding will be cut. So begins the opening of the High-Performance Teams Game. My goal is to help you see the effects of choices/tradeoffs on productivity and team cohesion. While some of the benefits of Agile happen at the individual level, there are many things that affect the relationships between team members, and therefore the overall cohesion and productivity of the team. The game is played by a team of 5-9 people, in a series of  5-6 rounds. During each round there is a little bit of teamwork, a little bit of discussion of the science, and some game play. Each round represents 6 weeks, or three 2-week sprints. In each round you have budget for the amount of work/stuff you can do based on your team’s capacity. Some of that budget must be spent on delivering features, otherwise the business will threaten to let you go. Some of it should be spent on growing the team and their engineering skills, otherwise you don’t get more budget capacity. Some of the leading research [1][2] suggests that a key requirement for high performance teams is Cohesion. Cohesion is a measure of the strengths of the relationships between individual team members. In this session we will use this research to discover: ·      Simple communication patterns we can monitor to spot the health of the team. ·      Simple tools we can use to measure and track those patterns. ·      What effect does the location of the watercooler have? What effect do lunch tables have? ·      Can cohesive teams get you into trouble? ·      The importance of dissent and diversity within teams. ·      Bonuses – the negative effects of individual bonuses are well understood by the Agile community. However, we’re left with the question: Are there good bonuses? Downloads Available Game Material (Dropbox folder): Team Member Handout Team Actions Worksheet (1 per team)   Facilitators Material: Teams Game Sample Games – four possible paths through the game played out Slides Magic and Science of Teams Game Edition from Mark Levison   In addition to the game material, I’ve written a paper on the “5 Steps Towards High-Performing Teams”. Enjoy playing with your team.   Feedback from GOAT (Gatineau Ottawa Agile Tour 2015): During game play at the conference, only the facilitator knew the benefit/effects of each action while the game progressed. As a result, in the 90 minute session some teams had a difficult time keeping track of the calculations. Future editions will reveal all the calculation details on paper to the attendees in the round after they’ve played. [1] Sandy Pentland – The New Science of Building Great Teams [2] Ben Waber – People Analytics  

JIRA is Not Agile

I’ve heard people say, “We started using Jira and GreenHopper, so we’re Agile now”. Similar things are said of Rally, VersionOne, LeanKit, TargetProcess, etc. In making those declarations, it’s clear that they don’t understand Agile at all. At its core, Agile is a set of Values and Principles: …. ·      Individuals and interactions over processes and tools ·      Working software over comprehensive documentation ·      Customer collaboration over contract negotiation ·      Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Underlying these is a mindset with a focus on self-discipline, self-organization, and adaption to change. The Practices of Scrum (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), the Roles (ScrumMaster, Product Owner, and Development Team), and the Artifacts (Product Backlog, Sprint Backlog, and Product Increment) only help the team support the principles and achieve the goal of delivering working software. Electronic tools (Task walls, Development Environments, …) or physical tools (Task walls, …) are only useful in so far as they provide support for those principles and practices. If your Agile adoption starts with a tool and a scattering of practices, then the whole point has been missed and the core – the essence – of Agile needs to be carefully reviewed until that is obvious.

ScrumMaster Tales – Stuck Waiting for Other Teams

John (ScrumMaster) and the team are humming along nicely building great new features for the SmallestOnlineBookStore. With the huge success of the first big release nine months ago, venture capital money has come flowing into the company. Significant investments have been made in Operations, Security, and Networking in addition to creating several new Development Teams. Unfortunately, all these new people are making it more difficult for the team to get the software they built deployed. The new groups are often imposing their own reviews and processes on the software before it’s deployed. Some changes are going to increase the load on the network and require review by the network team. Other changes affect the payment gateway, backend administration, and the services team who have a lead time of three weeks. All of these reviews, while increasing safety, have greatly slowed the delivery of new features. The Development Team is getting frustrated because they feel their work is slowed artificially by the teams downstream of them (i.e. Networking and Security). The customers are getting annoyed because the previously great flow of features has slowed down to a crawl. In addition, the team has created a Work in Progress (aka WIP) of one story per developer. This is both exacerbating and revealing the problem. It’s exacerbating because the team doesn’t have background to work on whenever their main task is stuck. It also reveals that the real problem isn’t at the team level where the work is getting to “almost” done. John creates a short list of options for the team: Increase individual WIP limits to 2; Change the Definition of Done so that Security and Network reviews aren’t part of Done; Add a column to their Scrum Task Wall to account for both other groups and start working with the other departments to clear work more quickly. Analysis Before we explore options in a situation like this I prefer to gather data. The best way in this case would be to create a Kanban wall that tracks the progress of a Story from initial idea to the moment it’s deployed and is delighting customers. This, combined with a Cumulative Flow Diagram, will help the source of the Team’s stress. John, being aware this might be an issue, has been tracking the data for just over a month: From the data we can produce a Cumulative Flow Diagram that looks like this: So what does this chart show? The team isn’t the bottleneck in this case. A simple test I use to tell is this: “If we had a magical way to double the rate at which you deliver stories/features, would that make any real change in the rate at which customers get the features?” At the development team level – Code, Code Review, Testing – clearly that isn’t the case, the bottleneck is in “Done in Development”, which is really just a buffer, and Network/Security review. Rather than make changes at the team level, we need to see what we can do to optimize the downstream work. Based on this data, let’s re-examine the team’s options: Increase Individual WIP Limit from 1 to 2 – This really just masks the problem giving something else for someone to work on when their original item is stuck in Network or Security. As we’ve already seen the limit isn’t at the team level, so optimizing there won’t help. Change the Definition of Done so that a Story is considered Done when it’s handed off to an outside team. – This doesn’t really help the customer since the item still isn’t deployed, it just makes each individual developer feel better. However, in creating an additional column for the downstream groups, we have effectively created a Definition of Done for each column. Kanban calls these “policies”. So we have changed “Done” but only in the name of making our problems more apparent. Add a column to the Scrum Task Wall – We didn’t quite do that, instead we created a Kanban wall that acknowledges some of the work is beyond our team’s span of control. So let’s add a new option: Start working with the other departments to clear work more quickly – In a Kanban oriented world, teams swarm downstream blockages. This would definitely be a good idea in our case.   Were I coaching John, I would get him to setup the Kanban tracking wall with the other teams and departments so that the entire company gets a view of where the work stands. I would invite people from each group to come update the wall every couple of days. By getting their involvement in set up and tracking, people from the other teams (i.e. Security and Networking) will appreciate that the data reflects their world and they will be more open to acting on the data. In addition, John (and his team) will gain greater insight into what is affecting Networks and Security – perhaps the company was suffering from a Denial of Service attack at the end of June and for a few days both teams were pulled from reviewing to handle the operational problem. The team might also discover that they’re found to frequently be violating security practices. In this case, mentoring from Security might increase the team’s level of skill in this area, and reduce time spent in the review phase. Very often in cases like this, cross-training the team (see: The Team Gets Bottlenecked) to help reduce the downstream bottleneck will help, however we won’t know until we’ve gathered data and worked with the other teams to find out what the real problem is. As an aside, I don’t recommend individual WIP limits when working as part of a Scrum Team – instead focus on the WIP for the entire team. It’s a small change, but it makes it clear that the productivity of the team is more important than that of any one individual.

Lifecycle of a User Story

User Stories are often used as a lightweight form of Agile requirement. Their goal is  to replace heavy weight-specification documents with “a Card, a Conversation and a Confirmation”. When people first discover User Stories it’s hard to see how they work because we often take a static viewpoint – i.e. we only see them at Release Planning or during implementation. We’re left with many questions: Where do User Stories come from? When are they created? Who is involved in their creation? To illustrate this I will use vignettes from the WorldsSmallestOnlineBookStore. Each vignette will show what happened to one User Story.  “As a frequent book buyer I want to save my address so that I don’t have to retype it every time I visit the bookstore” During the team’s first Release Planning Session (aka Initial Product Backlog Refinement) this Story was identified. After a few rounds of planning poker the consensus estimate was that it was size 20, allowing for both the initial entry of the address, updating and deleting old addresses. Since this Story appeared to be low priority in the short term, the team moved to other items. …. In Sprint #5, during a Backlog Refinement session, the PO Sue revisited the Story and asked the team if their understanding of the problem had changed in the past two months. They conferred for a few minutes and decided that it was still a 20. Sue grumbled and suggested it was a fairly small piece of functionality for such a large number. Doug suggested a Story split – using CRUD (Create Read Update Delete), he proposed in the short term that the User be allowed to add a new address and use it. However, they wouldn’t be able to update and delete. This would separate the Stories. After a few minutes of conversation around the implications Sue asks them to estimate the three split Stories: “As a frequent book buyer I want to save my address so that I don’t have to retype it every time I visit the bookstore.” “As a frequent book buyer I want to delete old addresses so that I don’t have to worry that my books will ship to the wrong house.” “As a frequent book buyer I want to update my existing address to correct small errors so that I don’t have to retype them from scratch.”  The team determines the “save address” Story is size 8, the “delete address” Story size 5, and the “update address” Story size 8. Based on this Sue moves the “save address” Story to the top of the Product Backlog, “delete address” about 15 items further down and “update address” has been moved so far down it will never be tackled. Since the slimmer “save address” is now the top Story in the Product Backlog without acceptance criteria, the team spends a few minutes creating criteria for it. They start off by drawing a quick pencil sketch to get the key points across. Based on this sketch they start creating a table of examples: 1 Sussex Drive, Ottawa, Ontario, Canada, K2K 010 Valid Buckingham Palace, London, UK Address outside of Canada/US 1600 Pennsylvania Avenue NWWashington, DC 20500 Valid Rather than try to create an exhaustive list at this point they just create enough to outline the boundaries of the problem. During the team’s next Sprint Planning session, Sue asks if the team can commit to this Story. They give it the “thumbs up”. Before the team starts work on the Story, Tonia (QA specialist), Brad (BA), Doug (Developer) and Ian (Developer) meet to finish hammering out the acceptance criteria. 915 E 7th St. Apt 6LBrooklyn NY 11230 Valid 24 Willie Mays Plaza, San Francisco, CA 94107 Valid 24 Willie Mays Plaza, San Francisco, CA No Postal Code 24 Willie Mays Plaza, San Francisco, 94107 No State 45 Rosenfeld CrOttawa, ONK2K 2L2 Valid 45 Rosenfeld Cr, Ottawa, ONK2K 2L2 Valid 45 Rosenfeld CrOttawa, ONK2K 222 Invalid Postal Code 45 Rosenfeld Cr, Ottawa, ON  Missing Postal Code …. (This style is referred to as Specification By Example – where the emphasis is that it provides the specification before something is built). Brad goes off to see if there are any edge cases that the examples don’t cover. Ian and Tonia pair off to turn the examples into Executable Specifications (i.e. acceptance tests) in Fitnesse[1]. Doug starts to take a crack at the GUI, seeing what parts he will need to assemble. Once the initial tests are written Ian tries build the business logic to support the examples. A few days later when Ian and Doug think they’ve completed the Story and it meets the examples, they show it to Tonia. Once she sees that satisfies the test cases she spends a while doing some exploratory testing – seeing how the application behaves when a real User plays with it. Satisfied, she calls Sue over for additional feedback. Sue is delighted with the behavior but asks for a few changes to the layout. Once those are made she agrees the Story will be complete. During the Sprint Ian demonstrates the different ways we can now support accepting addresses from both Canada and the United States. At the end of the Sprint the team takes the completed Story off the wall and archive it in the filing cabinet (they keep them around for later auditing). ——— During Sprint #6, Brad (BA) sees Ian (Developer) in the hallway and they start chatting about the warehouse runners, i.e. the people who fill the book orders. Brad comments he’s seen the runners spend a lot of time retracing their steps because the list of books in for an order is alphabetical – but unfortunately the warehouse isn’t laid out in alphabetical order. They create a new Story: “As a runner I want the list of books to be printed in the same order I will find them in the warehouse so I don’t have to run as far” During the Backlog Refinement session a […]