Agile Development Blog

Walter: “So Sarah, I am trying to get started with this Agile stuff.”
Sarah: “Great, I am here to help. What have you done so far?”

Walter: “Well, I get that we deliver something every two weeks. Agile makes us hyper-productive.  And to do that, my job is to make sure everyone is busy all the time, right? We’ll get the most features if I get people to sign up for the maximum amount of work at the start of the two weeks. This is easy!”
Sarah: “Hmm, I think we better take a step back. You may be misunderstanding something about productivity. Have you ever heard about Slack or Done or Flow?”

Walter: “You mean like Slackers who just blow off work? Sure! And done means its coded, right? And Flow must have something to do with how you hide under the radar to get away with slacking how much you code. Gee, this Agile stuff doesn’t sound very productive after all!”
Sarah: “Well, Walter, I think we need to have a long talk. Coffee or martinis? Pick your poison.”

So What’s so great about Flow?

Walter is stumbling on how to get his teams started with Agile.  He holds the notion that it is HIS job to make sure everyone is fully allocated, super-productive. And for him, productivity is measured in lots of features coded.

Sarah has some great advice here guided by the Lean principle of Flow. Productivity is not about filling our plates to maximum capacity during planning meetings. Rather, we encourage team members to build in “slack” in their commitments. They seek Flow of value delivery versus 100% allocation. That is: “Of our total time at work in this 2 weeks, we really only have this much time available (e.g.  X hours). And because we need to allow room for discovering what we can’t know, we are only going to sign up for and commit to this much (e.g. 80% of X) work.” As for “done”, a team commits to a certain, attainable level of doneness that includes more than code: testing, documentation, code review, acceptance, etc.

When teams pull these two fundamental Agile practices together, they are invoking the Lean Principle of Flow as guidance.

This is important to understand. Agile teams paying attention to Flow do not bloat estimates in order to manage uncertainty. Nor do they use bloated estimates to artificially create 100% allocation within a timebox. Rather, teams give their most accurate estimates for the work. These estimates include what work it will take to adhere to their definition of “done”. Embedding slack in team capacity absorbs the uncertainty and doubt incumbent in new work. And, at the end of the timebox, a team truly committed to Flow checks in on how it delivered value. It then inspects and adapts how it can continue this smooth value delivery.

Sarah, gets this. New Agile teams that concentrate on Flow before moving to other rigors create a sturdy foundation for continuous improvement.

To be clear, here is what we mean by Flow.

A team commits to only taking on as much work as they can deliver consistently over time. Think of Flow as the work that can smoothly move through a pipe that delivers value to customers. If we fill the pipe to 100% capacity (as Walter is eager to do), we create at the very least turbulence. At its worst, value delivery stops entirely. When Flow becomes this turbulent, work becomes sloppy and quality suffers.

So how can you tell if your team has embraced Flow?

There are a few basic tell-tale practices you should see. Teams in Flow:

• Are empowered and collaborative in decision making
• Don’t over commit to what they can deliver
• Declare a definition of “done” for how they make commitments to value delivery
• Use a time-boxed rhythm with slack for high-quality product delivery
• Engage in inspection and adaption practices that amplify their learning about team agreements, process and their definition of “done”
  

Most importantly, teams in Flow have a smooth reliable rhythm of delivery.  They can be seen making and meeting their iteration commitments and thus have a stable iterative and incremental process.  This is the key first stepping stone to Agile adoption.

Sarah will stick with Walter and his team in their adoption of these Agile practices of Flow. She’ll check in with them for a couple of iterations to help them inspect and adapt while adhering to Flow.  Sarah knows there are tons of quick wins to find when teams move to true Flow. And she’ll be there to guide Walter and his team even when the roadblocks to those wins seem insurmountable.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

This and other great questions from the LA Agile Success Tour below. My next post will cover the open space breakout sessions.

Question: What would you ask your CEO to bring Agile into your organization?

Christophe – Are you ready to get rid of 50% of your managers?
Jean – Agile brings about organization change, 20% of engineers won’t adjust.
Israel – What are you trying to accomplish? Pick one and focus on it.
Chris – Why just Agile in engineering? The whole business can use Agile throughout the whole organization.
Laureen – Are you really committed to the change?

Question: What metrics do you ask the teams and upper management to embrace?

Chris – Measure what you want to improve and care about like: velocity, unit test coverage for the team. For the executives, align business metrics with your development metrics and make it as public as possible.
Laureen – Make sure you have a goal before you come up with your metrics. What do the metrics mean to us? Data should support your goals.
David – Had no metrics before Agile, now we can have value based metrics that the business can use.
Israel – Establish a baseline before you do any process changes – you need to know where you stand. Pick the metrics to help you know where you stand and establish that baseline.
Christophe – One tracked 3 metrics: dollars, customer satisfaction, and time to market.

Question: What do you believe is the #1 discipline that had to change or understand to enable successful Agile adoption?

Chris – The toughest and most important one is getting the development team to embrace continuous integration, it reveals so many of the improvement areas within the development team. This is hard because it can expose so many sacred cows within the organization. Getting to a point where you are always ready to release is key.
Israel – Changing how the sales force and marketing departments sell products. Getting these groups able to sell value and benefits to the customer rather than a pure feature focus. This is key to end-to-end Agile.
Laureen – Agile isn’t just another process with associated documents; it’s a change with how people interact with each other on a day to day basis. If people don’t want to grow and change with the business, then they may need to leave your organization.
Christophe – Are you good at multitasking? Instead ask: Are you good at single tasking? Limit the amount of work in progress! Nothing gets done when you focus on too many things. The most difficult thing is to get teams to focus on one thing at a time.
David – Moving away from an upfront requirements document to user stories that can change over time. A key piece was to break the stories down into smaller and smaller stories that can be worked during the iterations. Even people who thought they understood this process of breaking stories down struggled.

Question: How do you educate clients to Agile in a service provider based businesses?

Israel – Involve your customers with the iterations, the release planning events, and the end of iteration demos. The commitment is small from the customer and the benefits are tremendous in that the customer can be involved in the development process.
Chris – Agile is such a wonderful and easy way to get customer involvement. Each iteration, they deploy to an external environment where they get feedback. Create a feedback loop with your customer so they can see how their feedback affects the direction of the product.

Question: How do you do performance management in a highly functional organization?

Christophe – I don’t do formal performance appraisals in my organization. Do the right thing for your team.
Jean – Look at performance with this question: In what ways did you contribute to the success of this team?
David – Unlike Christophe, it’s a little different in big organizations with SOX issues. If you have managers that span Scrum teams, make sure they understand what’s going on in the Scrum teams. Your focus as a manager totally shifts from micromanagement to one of removing impediments, roadblocks, and preparing the team for the next project.
Israel – Keep information about how the team is doing secret to the team. Decouple the performance appraisal process from the process improvement within the team.

Question: How do you estimate how much work will go into a release and do more development and do it faster?

Christophe – Make sure you fix the date of your release and vary scope.
David – I agree, resources are fixed, time is fixed and scope varies.
Laureen – We use a train analogy. There is no question when the train is leaving, the question is what features will be on the train.
David – When we started we had about 60% estimation accuracy. We now have over 90% accuracy in our estimates. A key point is DON’T LOAD YOURSELF TO 100% CAPACITY. Give yourself some flexibility, someone might get sick.

(more…)

In my post “What’s with all the Agile Process Overhead? Part 1″, I reviewed the contents of the Sprint  Backlog. Hold, commit to, and track items of value there. Nothing else.

I eluded to two other perceived Agile Process overheads, one of which I’d like to peek at today: how do you allocate your time effectively?

This came about from the same client discussion that prompted the post on the Sprint Backlog. In conversation, I discovered that the team believed that they had to be 100% allocated for the entire duration of their Sprint. Hence, the lengthy, detailed nature of their Sprint Backlog. Time to back up.

Team Members determine their ideal effort availability

We’ve already covered one problem with this allocation paradigm: you are tracking the wrong thing in your Sprint Backlog if it is not showing value-add work completion. Now, here is the second villain. No-one can accurately account for all hours of every working day as “ideal effort hours”; that is, hours of completely uninterrupted, undistracted work. Ravi Jha stole some of my thunder on this with his great comment to my previous post. Heed his advice from February 27!

Teams preparing to plan their commitment for a Sprint/Iteration look at their capacity; that is, how much work do we believe we can take on and complete by the end of the Sprint? As Ravi pointed out, a good team assumes from the start that it cannot devote a full 8-hours a day strictly to product backlog value-add work. A good beginning capacity number is 6.  Why 6? Because it is not 8. Until informed otherwise, of our 8-hour work day, we believe each of us can truly be heads-down concentrating for 6 of those hours. The rest of the time will be swallowed up by interruptions, emails, unplanned meetings, and other distractions.

Now, here is the sticky part. As I mentioned in Part 1 of this series, Agile teams must also take into account slack for what they can’t know. This is different than the 6 hour number of ideal effort hours. When we make a commitment in a Sprint Planning meeting, the commitment is:

• We are committing to moving forward with what we currently know so that we can continue to learn by building a potentially shippable increment of the product.
• Our intention is to complete all of these Sprint Backlog items based on the analysis and conversation that has happened to this point.
• We think it will take these many ideal effort hours and we believe we have this many hours available.
• Everyday, we will honestly evaluate how we are doing with our commitment so that we can improve on meeting this commitment AND improve on how we make commitments in the future.

Therefore, a team, not knowing what it doesn’t know, applies a certain additional level of slack or buffer to how it commits. Call this the “Commitment – Buffer of Unknownables” (or C-BOUs). Now the team that has 6 uninterrupted hours per team member per day may additionally say, “Our C-BOU is about 1 hour person right now per day because we just don’t know this product or this process very well. We don’t know what we don’t know, though we know we want to get better.” As the team evaluates the Product Backlog Items with the Product Owner, and as they determine tasks and estimates for this work, they are keeping in mind:

• what ideal hours they will need
• what ideal hours do they have
• how much C-BOU should they hold back

By the end of the Sprint Planning meeting, a commitment then truly represents:

• Items of value we intend to deliver
• Commitment by the team to learn about commitment
• Intention to use the buffer for what they couldn’t have known
• Agreement to evaluate the C-BOU at each retrospective to see if it needs to be bigger or smaller

Some teams call for a bigger C-BOU due to the volatility of their environment. (Okay, they prefer to say their business is very “organic”.) Tracking this capacity buffer is a great way to enable getting to the root of that “organic” nature. Without paying explicit attention to the truth of unknowns and the amount of time they take, a team and the agile project management can create waste and overhead. Teams go into a frenzy mode to meet a commitment that allowed for no buffer, no unknowns. Management applies pressure to meet the commitment despite the clear and present issues that are eating up the efforrt. None of these tactics improve team commitment; they create overhead, waste, and low morale. And they add the cost of manaing all three of these.

That’s it for Part 2. In Part 3, I’ll talk about how you plan for unplanned work, without using a crystal ball :- )