One Piece Flow

One piece flow is a concept from Lean and is the key to succeeding with Agile. One piece flow is exactly what is done when producing a hotfix. The only difference is that one piece flow is an intentional practice rather than something done in reaction to a critical problem.

There are four main concepts in “one piece flow.” Each story is done as if it was the only thing in the release, each aspect of developing a user story happens in rapid succession, there is as much done in parallel as possible, and each team member focuses on a single user story at a time. The result of one piece flow is that the time between when the team first starts working on a user story and when they can ship it fully developed, tested, and documented is very short. The timeframe is generally on the order of a week at most and usually days.

In one piece flow, when development starts on a story, QA should be creating test cases for that story (story testing) at the same time. When development is done, QA should then automate the test cases and make sure they all pass. At the same time, the user documentation is written. One last step that must be completed prior to considering the story done is that all of the artifacts connected to that story such as source code changes, documentation updates, new test cases, etc must be integrated into the source code mainline.

Ideally, when following one piece flow, you would have done everything required to release the product to validate that the story really is done. That’s generally an impossible goal when just getting started with Agile, but it is a goal to keep in mind as you go. When working on stories, try to adhere to the principle of one piece flow to the greatest extent possible. As you read on you will find additional practices which simplify and reinforce the practice of one piece flow.

One last point. It may sound from the name that you can only work on one story at a time when following one piece flow. But really it means that for any story that is being worked on, it is progressing as fast as it possibly can without anybody that is working on it switching between multiple tasks. Another way to look at it is that the team should only be working on more than one story if the second story can be worked on without affecting the total time it will take to complete the first story. Likewise, the team should only be working on three stories if it won’t affect the total time it will take to complete the first two stories on an individual basis, and so on. A good rule of thumb is to only be working on as many stories simultaneously as you have developers on the team.

Burning Down Hours is Anti-Agile Because Working Software is the Primary Measure of Progress

A burn-down chart can use anything for the units, such as hours or points, but originally Scrum's burn-down chart tracked hours of work remaining in the iteration. Many people still use an hours-based burn-down chart as their primary measure of progress during an iteration. That’s a useful tool, but it is similar to tracking yardage in an (American) football game. It measures activity, but not accomplishment. After all, what percentage of a touchdown is 30 yards?
Working Software is the Primary Measure of Progress
One of the principles from the Agile Manifesto is "Working software is the primary measure of progress". But burning down hours is measuring and reinforcing progress against a plan without any requirement to have working software until the end of the iteration. That's pretty much the same as not having to have working software until the end of a waterfall release! This is one of the reasons that many people have moved away from burning down hours or supplemented it with other tools, such as burning up story points.
Burning Up Points to the Rescue

The Burn-up by points chart is one of the very best tools in Agile. It brings together many of the best aspects of Agile all in one place and gives you an instant heads up as to how you are really doing. The way a points-based burn-up chart works is simple.

For the iteration you are about to commence, total up the story points in all of the stories you have targeted for that iteration. Let’s say it made up of two 5 point stories, two 3 point stories, one 2 point story and two 1 point stories. That’s a total of 20 story points. Make a chart with an X axis that represents all of the days in the iteration from the first day to the last day from left to right. Let’s say it is 10 days. The Y axis represents the number of story points completed and in this case would go from 0 to 20 story points.

At the end of each day you tally up the story points associated with all of the stories that meet your definition of “done” and record the total on the chart. For instance, if you completed a 1 point story on the first day, nothing on the second day, and a 2 point story on the second day, your chart would have a 1 point bar for the first day, a 1 point bar for the second day, and a 3 point bar for the third day.

A points-based burn-up chart lets you see graphically day-by-day how much progress you are making towards your goal. It only records accomplishment, not activity, and allows you to see if you are on track or getting behind. To me, this is exactly what is meant by "Working software is the primary measure of progress."

Won't The Chart be Empty Until the End of the Iteration?
At first you may think that the chart will show that you are behind for most of the iteration and catch up only at the end when QA is able to start testing and marking stories as done, but whenever the chart shows something other than a steady march to the end of the iteration, here are some of the questions you should be asking:

• Are our user stories too big? Is that preventing QA from getting involved earlier?
• Are people working on too many stories at once?
• Are we unable to produce a stable build for QA to test?
• Are developers producing a bunch of problems and then going on to the next story instead of helping QA resolve the problem?
• Should the developers drop what they are doing and lend a hand writing automated tests?

Using a points-based burn-up chart gives everybody, from team to manager to the organization as a whole, an instantly understandable picture of the health of the project and team. It simplifies the life of the manager because if it indicates a problem anybody can stand up and say “hey team, we’re messing up, what are we going to do about it team?”

A burn-up chart reinforces the following ideas:

• Use story points for estimation, it enables whole-team thinking such as this whole-team metric.
• Make stories as small as possible to get them done as fast as possible to keep the focus on accomplishment rather than activity
• Have as co-located and as cross-functional a team as possible to enable the fastest possible turn-around time on stories
• Enable the team to work as a team and to manage more things on their own

Unlike Burning Down Hours,  Burning up by Points is Fully Automatic!

You may not be ready to give up burning down hours yet, but there's no reason you can't use both. And most Agile Project Management tools, such as Rally , Version One, and Jira will generate a points-based burn-up chart for you automatically.

There's one more reason you may want to consider moving from burning down hours to burning up points, assuming your user stories are small enough in general and you are mostly getting stories done all the way through the iteration. In my experience, team members don't really like having to enter their hours remaining for their tasks every day, often forget to do it, and it keeps the focus on activity rather than accomplishment. Also, the only manual step required is to mark the story done, which helps to make the whole process much smoother.

Tweet

[Excerpted from my free eBook "Do It Yourself Agile Kickstart". ]

How I Discovered That Agile Can be Taught to 200 People at a Time

I was speaking to some fellow Agilists at an event recently about an Agile training course that I do that can accommodate up to 200 people at a time and they were pretty skeptical that it could be done. Later, I realized my path to creating the course might make an interesting story as well as be a good illustration of the power of self-organized teams. This is that story.

Marvin Toll Creates the First Bridge to Large Scale Training
At some point before the first Agile and Beyond conference, which was held in March of 2010, I was contacted by Marvin Toll and asked to present at the conference. He wanted to know which topics I could present on and I sent him my list.

Marvin chose "Hands on Agile" which had a title and an abstract, but no content. I just had an idea for a small hands-on workshop that might help people better understand what Agile is all about. I agreed to do it and took the first of many serendipitous steps.

You Want Me to Do This for How Many People?!
Luckily I was able to drawn on some material that I had already created for various Agile-related presentations. But then the second unexpected thing happened. One of the conference organizers sent me an e-mail letting me know that I should expect upwards of 100 people to attend my session and possibly many more. I had forgotten to let them know that I was planning on an intimate workshop of about 20 people. Now what was I going to do? I never would have set out to do a hands-on session for more than 20 people, let alone 100 or more!

I realized that all of the hands-on activities were structured around co-located whole teams. Everybody would be split up into teams with one team per table. Assuming that the instructions were easy to follow, each team would work together to figure out and perform the exercise.

I also realized that the question was, did I really believe in self-organized teams or not? Was it possible for just one person to keep over 100 people on track doing self-directed exercises? In the end I either believed in Agile or I didn't and if it worked out it would be another good example of how self-organization works and if it didn't I would learn some important lessons.

The Big Day Arrives
The day of the event I felt as prepared as I could be, but I really didn't know what to expect. Just before the session was about to begin I discovered that the sample user stories that I had so carefully prepared as handouts for each team were missing and I didn't have time to create new ones. And then I discovered that the easels and stickies for each table weren't set up for each table as I had requested and weren't even in the room! I was starting to get knots in my stomach. What would I do now?

I found one of the organizers and asked about my materials. Ten minutes later, all of the easels and stickies were at the front of the room and it was time to start. Approximately 150 people were all staring at me expectantly in 17 teams of 9. Necessity really is the mother of invention. After going through the preliminaries, which included explaining the role of a Scrum Master and having the room form into cross-function teams, two ideas came to me. First, I realized that I had 17 Scrum Masters that had materialized as a result of self-organization. I had them come up and get all of the needed materials for their teams and it looked like I had always meant to do that.

The second idea turned out to be one of the key reasons that the training is so much fun. Rather than use the pre-created user stories that I no longer had, I had each team pick a software project on their own. The only requirement was that it be something that the whole team thought would be fun and had nothing to do with anything they were currently working on. Two examples of projects: an on-line recipe creation website and a death ray. Apparently, one of the teams was made up of military contractors.

The Rest of the Story
After a successful debut, I've since repeated it at Agile and Beyond 2011 and will be doing it again at Agile and Beyond 2012 in March. Because it went so smoothly the first time with 150 people, I'm confident it will scale up to at least 200 people with a single instructor. I plan to test that theory in the near future. I also turned it into a full day training course which was offered all over the US last year. A brand new full day version, called Agile Whole Team Training is now available through Valtivity via public courses starting in Boston on March 20th and is also available privately on site or off site.

Exciting New Agile Training Option - Train Your Whole Organization!

Agile training is pretty expensive and generally targeted towards Scrum Masters. If you have a lot of people you want to train, it makes sense to just send the Scrum Masters. But now there is another option. Valtivity is proud to announce its new Agile Whole Team Training program. This course is being delivered in cities near you, starting with Boston, and can also be delivered as a private course either on site or off site.

Agile Whole Team Training allows you to train everybody in your organization (up to 200 people at a time) for the same price as just training the Scrum masters! Not only that, but people will only be away from their work for a single day.

This is a unique one day course which introduces Agile to the whole team and is also a great team-building opportunity. It is for anybody involved in development: management, product managers, business analysts, designers, developers, testers, DBAs, technical writers, project managers, etc. You'll form into cross-functional teams, pick your own software product to "build", and do hands-on exercises as a team. Bring an existing team or join a team during training.

Learn more about this new Agile training option here .

Panning for User Story Gold: Increase business value and reduce costs

Putting User Stories into business value order is a key tennet of Agile, but that's just the first step. There's much more value to be extracted from your user stories using specific story splitting techniques combined with reducing cycle time. By splitting user stories you can separate the gold from the dirt as well as reduce the cost of implementation.

Come check out my webinar on splitting user stories on March 6th at 1PM EST. The session will cover a variety of methods for splitting user stories and reducing cycle time including the "create/read/update/delete" method, the acceptance test method, the split by value method, frequent grooming, Kanban flow, and software tool support.

Announcing Valtivity!

You may have noticed that I haven't been very active here in a while. Over the last year I've been spending more time doing Agile presentations than blogging. Well, that's about to change. I've just started a new company, called "Valtivity". I will now be devoting my time to Agile full time which means that I'll not only be doing presentations, but also blogging in tandem with focusing on Agile training and coaching. Need to get started with Agile or move to the next step in your Agile journey? Check us out at Valtivity .

Valtivity enables companies with a software development component to find and implement their ideal way of working that maximizes value to the company and its employees and allows them to find and serve new market opportunities faster. Valtivity does this by using unique training and coaching methods to rapidly teach the latest Lean and Agile techniques.

For the curious, Valtivity is short for "Valuable Activity." It comes from Lean's focus on activities that provide value.

Valtivity will be hosting its very first Webinar, "Agile - A Focus on Value" on Feb 1st at 1pm EST. Register now!

Here's a little Agile Humor for you. I recognize a couple of these. :)



This comes from my friends over at SmartBear

Introducing Kanban Into an Existing Scrum Implementation

By far, the talk that I am most requested to do is "Scrum and Kanban Like Chocolate and Peanut Butter". I've given the talk all over the US and Europe, most recently in Kiev for Agile EE. Invariably, people come up after the talk and ask how to get started with Kanban. I've given book and coach suggestions, but they are primarily pointers to pure Kanban resources.

Scrum and Kanban Like Chocolate and Peanut Butter
There doesn't seem to be much material specifically geared towards introducing Kanban into an existing Scrum implementation as opposed to going from non-Agile to Kanban. So, I've decided to write a short and concise guide to folding Kanban practices and principles into an existing Scrum implementation called "Scrum and Kanban Like Chocolate and Peanut Butter." I will write the guide via a series of blog entries over the coming weeks. I hope you will follow along with me, asking questions and offering feedback.

Who is "Scrum and Kanban Like Chocolate and Peanut Butter" Intended For?
The first question is: when does it make sense to introduce Kanban where Scrum is already in use? It turns out that is a very complicated question. Rather than answer that question, I'm just going to gear my posts towards folks that match a certain set of circumstances. My material for introducing Kanban into an existing Scrum implementation is geared towards folks for which the following is true:

• You have already been doing Scrum for 6-9 months
• There is a general feeling that things are going better than before Scrum was introduced
• You are using user stories
• You have a definition for "done"
• Your user stories are relatively short with no stories that take longer than 1/2 of the iteration to get to done
• Most stories are "done" at the end of the iteration
• You have an iteration length of 4 weeks or less
• You have a cross-functional (though not necessarily self-managed or co-located) team
• If there is a "business unit" that previously served as "the customer" then you've integrated the business unit and software team at least to the point that there is a product owner on the team which talks to the customer of the business unit, and the business unit is no longer considered to be the customer for the software team.

If you do not have all of the above, you may want to consider getting to this point first prior to taking any of the steps that follow. Over time I'll come back and update some of the points above with links to resources for addressing these points if they are not already true. The first post will be available over the next few days. The guide will be based on my talk "Scrum and Kanban Like Chocolate and Peanut Butter". If you want to get a head start you can check out a recent video of the talk which is available on vimeo.

Agile Book Recommendations

The following books are the main books that I recommend as starting points for learning about the various aspects of Agile. While their is a fair amount of overlap each of them covers a specific topic. The one on leading self-directed teams is not strictly an "Agile" book, but it is one of the few books talking about self-managed/self-organized/self-directed teams that I have found. The Toyota way is also not an "Agile" book but does a great job of explaining the concepts of Lean which I believe are the foundation for Agile.

Click to enlarge.

Sticking to Estimates

I got a great comment from Kelly Waters on my recent post "Scrum: No commitment required" via his web site. After responding I realized that the response was a good basis for this follow-up to my original post.

In the original version of Scrum, the commitment of the team for the sprint is dependent on two things: a good work ethic and good estimates. If either one is an issue, then the work won't be done on time. The “no commitment required” title of my previous post was a bit tongue in cheek. Absolutely commitment is important, but I don’t think that making it part of “Scrum” will suddenly make team members with a poor work ethic suddenly have a good work ethic or team members with problems estimating better at estimating. Nor will having commitment part of Scrum automatically improve a bad team/PO dynamic. 

People with a good work ethic will work hard. If you have folks with a poor work ethic, I believe Agile will expose this more clearly and then you can use your management skills to address it one way or another. Hopefully, with a win-win solution.

Estimates are just that, estimates. They are a good-faith representation of what the team believes it will take with the information they have at hand. When something is discovered, then it is important for the team to communicate that to the PO, but I don’t think it means that they have to stick to the original estimate. Is that “letting them off the hook?” I don’t think so. Let’s face it, if they estimate 8 hours, but it turns out to take 24, the only way to do it in 8 is to do 8 hours “on the books” and 16 hours off. To have the team absorb those extra 16 hours means that they will have to take it out of their own time which is violating the idea of sustainable pace.

If you have a team that consistently misses their estimates, that’s something different. Missing estimates should be the exception rather than the rule. When it becomes the rule, the question is what’s going on? Is team morale low? Why?

When using story points combined with tracking velocity, there shouldn't be a problem with estimates because story points and velocity should make the issue of estimates a moot point. What I mean is that if all estimates are suddenly off by a factor, the result is simply that velocity goes down. If estimates have always been "off" then velocity will not be going up or down, it will just be fairly constant. Since story points and velocity are relative, estimates that are "off" by a factor aren't a real problem.

Instead, the “problem” may be manifesting itself more as a general feeling of “this team just doesn’t seem to be as productive as it could be.” But then you are back to “why not?” I don’t think an enforced framework of commitment will change anything if the team has, for instance, low morale.

On the other hand, if the problem is wildly varying velocity (perhaps due to wildly varying accuracy of estimating stories) then I would venture there is a good chance that the stories are just too big in general and a good remedy to consider is to aggressively split stories into smaller stories.