Agile Development Blog

The Dream of the Cloud by Enrica Bressan

What is your dream for the cloud? 

Is it a blob that will cause you to lose all control, including your job?

Or, is it an amazing innovation that will save your company from this world-wide recession?

Or the it's The Blob - Buy the classic @ Turner by clicking image

On April 15th, I will be fortunate enough to join Sachin Saxena from Global Logic and Mac Devine, the AIM SaaS/Cloud CTO at IBM,  for a webinar to attempt to answer these questions (learn more and register here).  They are both experts in internet technology and hold deep knowledge (along with beautiful slides) on the topic of cloud computing.  Their goal is to help you understand the massive energy, time and computer savings made possible by the many cloud options.

Specifically,  they will define the cloud, its opportunities and roadblocks. They both plan to highlight case studies, and my role will be as a customer and extensive user of cloud solutions.  This is much the same role that I played at the New Jersey CIO summit in February.  (If you can’t wait for the webinar – don’t miss Troy Angrignon’s opinion post at Sandhill.com about the implications on cloud computing on software firms.)

At Rally, we are very comfortable with the application of these technologies.  As a 160 person SaaS firm provider, we have been in the early market for many of these technologies.  It was fun for us to benefit from the fast move to free of hypervisor/virtualization portion of this wave. Listen to Mike Cote’s podcast on the topic at RedMonk. He has been covering the Cloud/virtualization for years as an open source analyst.

As a result, I believe that 100% of the companies who attend this webinar will leverage these technologies in 2009 in a strategy to reduce risk and cut costs.  But what are the other rationales for the cloud?  What are your stories?  I think cloud/SaaS, Agile development and web 2.0 customer communities are an even bigger story, but one that will take longer to develop than the use of public/private clouds and virtualization technology.

Next up on this topic will be the actual energy savings reports from our virtualization and power management efforts lead by our internal green team.

Team 100% allocated commits to 8 Items for the Iteration

This is the final post in my series about a client’s consternation with regard to Agile Process Overhead. This last topic had to do with their Sprint Planning Meeting and how to make commitments.

The problem? “Jean, how do we plan for unplanned work?”

In this case, the team was referring to production issues that would come up that HAD to be addressed, even though they could not be predicted during the Sprint/Iteration Planning Meeting.

So, how DO you plan for unplanned work? If you look at my post about the 5 Orders of Ignorance, where would you place this issue? Well, it is the 1st  Order of Ignorance:

• 1st Order Ignorance: Lack of Knowledge
  • I do not know something

For this team, in their planning meeting, they truly can say with conviction, “We know that we don’t know something.” That is, for this team, they know that they can’t know all the production issues that may come up. Fortunately for this team, they don’t fall into the higher orders of ignorance. Most notably, they are not in the clammy grasp of the 3rd Order of Ignorance:

• 3rd Order Ignorance: Lack of Process
  • I do not know a (suitably effective) way to find out that I don’t know something

We have a process! It is called Agile software development! And here is how Agile helps us plan for unplanned work, the things we know that we do not know.

1. Do not commit all of your team capacity to the work you DO know about (i.e. Prioritized Backlog Items)
2. Track Iteration over Iteration the amount of unplanned production work that comes in (e.g. “Last Iteration we didn’t finish 3 of our committed items because we had 5 major production issues come in. The Iteration before that, we had 6 minor production issues come in; we did not complete 1 of our committed items.”)
3. Declare and hold a buffer that is an average percentage of time you have production/unplanned work arrive after Sprint Planning (Iteration = Sprint in Scrum) has completed (e.g. “Based on the last 5 Iterations, we have spent an average of 30% of our time on production issues. Therefore, we must hold back a 30% buffer from our Sprint Planning capacity this timebox.”)
4. During the Sprint/Iteration, continue to track how much unplanned work comes in that impacts the team.
5. Report this unplanned work and its impact in the Sprint Demo and Review meeting. Continue to evaluate its impact on the team’s ability to take on new, value-based, innovative work during the Sprint/Iteration.
6. If NO unplanned work comes in during the Sprint, consult with the Product Owner about the next highest priority items the team could invite into their commitment for the Sprint. (Some teams like to talk about this “back burner” work during the Sprint Planning Meeting. They plan it out with tasks and estimates but do not commit to it.)

Team buffers and only commits to 6 Items for the Iteration

Finally, a team that finds itself continually taking on more and more unplanned work needs to run a Retrospective specifically on this topic.

This is part and parcel of a real Agile culture: retrospect on items that are getting in the way of our ability to deliver value.

Where is all the unplanned work coming from? Do we really not know our priorities? Do we really not stick to our Sprint Plan?

Is our product technical debt so great that we are forever mired down in triaging the product? Is our testing strategy not disciplined enough with regard to how we declare “Done” items? What new agreements or strategies must we put into place to reduce the amount of unplanned work?

Now we have a process for how we deal with work that we cannot plan for. Hold your resolve around this. Do not be pressured into fully filling your Sprint/Iteration until you are able to successfully deliver committed items.

Your Burndown Chart will have a more gentle slope; your Sprint/Iteration backlog will have fewer items. AND, you will be able to absorb that work we know that we don’t know.

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.

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 :- )

This Friday, February 27th, I will be speaking on a panel at the New Jersey Technology Council’s 2009 CIO Conference called “Moving to a Virtual World” ( www.njtc.org). The panel is on Cloud Computing and it is a mixed collection of vendors and CIO’s talking about the rapid arrival, the clear benefits and struggles of adopting Cloud Computing.

At Rally, we have gained some firsthand knowledge of these technologies, platforms and applications as we try to find the most energy efficient, stable and cost effective solutions for us and our customers.  As a small fast growing technology company, we are an ideal customer for Cloud Computing and I am sitting on this panel as a user, supplier and leader on software development for the cloud.  (We use Amazon EC2, VMWare ESX, Salesforce and seven App-Exchange Apps, Google Apps Premier to run our business and manage our own multi-tenant SaaS/PaaS application in the cloud.)

In preparation for the panel, I was brushing up on some of the latest news and views on this topic.

Here are the worthwhile Cloud Computing links that I used to prepare my talking points:

• Cloud Computing – you have to start on Wikipedia to make sure your definition is grounded
• What is Cloud Computing - a wonderful video of a variety of folks from the Web 2.0 Expo
• Above the Clouds – is a new blog site, whitepaper and video from Cal Berkley Professors on Cloud Computing
• Cloud an Outsourcing Option in Troubled Times – CIO Insight article on using cloud services instead of more traditional IT outsourcing options (both development and operations)
• “What the hell is Cloud Computing?” - Larry Ellison rails on the whole idea as over-blown (see many YouTube videos)

(more…)