Agile Development Blog

In my last post I discussed the awesome workshop I attended called Leading and Learning for Sustainability and why I think it was so beneficial.  It changed me.  This post is about how it changed me.

While at the workshop, I learned from deep reflection that I get things done by example.  I also learned that I like to work with my team and my customers.   In other words, my strategy for leadership is “walking the talk” and sharing it.  (It only took me a year of blogging to figure out why I blog and to whom I am writing.  I feel my best posts are the ones written to my team and customers that are based on my own personal experiences.)

As a result, I have learned to articulate my strategic roadmap toward sustainability and restorative economies in these steps:

1. Get Rally and our customers effective at Flow, Service and Lean in software and product development
2. Get myself and my family to a zero carbon footprint lifestyle
3. Mature the software & hardware development practices as a highly valuable, joyful, respectful and humane profession
4. Get Rally to a zero carbon footprint
5. Get our High Technology industry to a 80% carbon reduction in total footprint
6. Grow High Technology as a leading sustainable industry and critical enabler of green technologies and as an 80% carbon reduction in other industries

Step 1. Back in 2002 when I was working on the initial concepts for Rally, it was Paul Hawkin’s Natural Capitalism book that really shaped my long-term vision for Rally. We basically committed to to bring service and flow, and lean to the high technology industry. I would declare our first 6 years as a success. We have succeeded at introducing the concepts of Flow, Lean and Service into the software and hardware development industries.  In addition, we have made many of the worldwide leaders in this space very successful by realizing the benefits of enterprise agile software development.

New Baby Goats this Spring

Framed Greenhouse on Barn

Step 2. We have been incrementally investing in solar-based solutions to make our personal life more sustainable.  It was PV’s, hybrids, chickens, goats, an e-bike and now this year a new in-ground greenhouse.  A solar hot-water and pre-heater is up next in 2010. (Hopefully, I will even get a cool Tendril home monitor from one of our customers for Chirstmas!.)  I think our home life will be over 80% of the way to zero carbon footprint by 2011 with the final addition of electric vehicles.

As a well paid worker in the executive in the High Technology field, I figure it is my role to help these new green technologies move down the marginal cost curves.  In addition to actually doing something about this problem, I am learning about living in close-loop, sustainable value chains. (I will tell you there is something very grounding and joyful about starting the day by feeding animals who provide for you.  Even on a day like today that was -1 F outside.)

Step 3. Through our 1% volunteering model, folks at Rally have been involved as members, volunteers, speakers, sponsors and board roles at the Scrum Alliance, Agile Alliance, Agile Product Leadership Network and the Project Management Institute.  Our work in growing this industry is just beginning.  In 2009, we hit our 1% goal with 2,800 hours of volunteer time and won the Best Company to work for in Colorado and a top 10 ranking from Outside magazine. In early 2010, we hope to announce a number of clear steps at helping to grow our industry though more educational partnerships in Agile and Lean.

Step 4. In 2006, we started a green team with the help of Boulder’s Be Climate Smart audit team.  In the last three years, we have continued to benchmark our climate impact as well as the community impact of our volunteering hours.  We know that our SaaS application currently puts 8 tons of CO2 into the atmosphere per year for every 100 users. More importantly, we know where that carbon comes from and we are conscious of the impact and thus the opportunities to curb this for Rally and our industry.

Step 5- 6.  These steps will come as we share our experiences based on our own relentless pursuits of steps 1-4.  Right now I learn a bunch from work shared by Interface carpet’s mission zero, Google.org’s RE<C and as a member of NRDC’s E2 program.

It was as a direct result of this workshop that I learned enough to articulate my choices, what to conserve, what to let go of, my leadership approach, who I need to do this with and ways to bridge the creative tension between my personal vision and reality. It was a very powerful workshop.

In closing, I would like to share two of my favorite quotes:

• Edward Deming: “The prime requirement for achievement of any aim including quality is joy in work.”

• Humberto Maturana: “Emotion is the bedrock of all that we do and love is the only emotion that expands intelligence.”

Thank you again Peter Senge, Sherry Immediato, Darcy Winslow and all the other great folks who attended the SOL workshop on Leading and Learning for Sustainability in DC.

About the Author: Ryan Martens is a trail runner,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Climate Change due to the increase of carbon from human activity is a “Global problem,” thus it has a couple of unique attributes compared with other world problems:

It affects everyone

You can act on it anywhere

I choose to act on this problem at home and at work.  As part of this action,  Tim and I chose to attend the Society of Organizational Learning’s (SoL) workshop based on Peter Senge’s book Necessary Revolution.

This three-day workshop leveraged long-time SoL content on leadership and mastery into the context of the global climate change.  It was a fantastic workshop that I highly recommend – as it has changed me and my mental models.

Tim, our CEO, Peter and myself at the end of day three

Living in Boulder Colorado with tons of the worlds best climate scientist and a University that helps you Lean More About Climate, I am familiar with much of the science behind climate change.  But, in this workshop we got to take our understanding up to the larger system level through system archetypes, multi-player games and simulations.

On the third day, we played with and did mock negotiations using the climate change system simulators that were built for negotiating teams going to Copenhagen in the next two weeks.   The systems dynamics models baked into the C-Lean simulator are made more apparent in the Seed Simulator on Carbon flows. (It is a simple bath tub model of how carbon flows through the natural system.)

For your information, the answer to the simulation puzzle of putting climate change in check and keeping average global temperature from rising more that 2 degrees involves three things:

1. have all countries in the world (un-developed, developing and developed) reduce there carbon output by 80% from 2005 levels by 2030
2. stop deforestation efforts
3. maximize reforestation efforts

To do this, the world will have to cross the threshold to a new game;  an infinite game of win/win behaviors that measures success based on ecological restoration and social well-being.  Finite game behaviors coming from zero-sum game thinking and patterns of shifting the burden and escalation will have to stop.  I like to think of this an maturation of our species from wildly growing adolescents to young adults.

Peter’s 5th Discipline Fieldbook and The Dance with Change, come with tons of exercises, tools and guest lectures that are all helpful at understanding organizational learning and systems thinking. However, as Peter said in the workshop, understanding the concepts are easy, but practicing them can be much harder.

Part of the success of this public workshop was working with these concepts in a context of a global problem that we all share.  We got to work on ourselves and a shared global issue.   And as a result, we seemed to all have limitless energy and worked from 8:30 AM to 7 PM each day.

I encourage you to visit these sites, they give climate change a face and a shorter feedback loop.  Both of these benefits can lead you and your teams to better understand and more easily act on this Global issue.

Thank you Tim, Peter, Sherry, Darci and all the other great folks who attended our workshop in DC.  I have my joy and I will share it and my personal learning’s from this event in my next post.

About the Author: Ryan Martens is a telemark skier,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

As part of our goal to have a zero carbon footprint by 2020, we calculate our total carbon footprint each year including building facilities, travel, commuting, IT and waste.  As we get more accurate every year, we are adding in the impact of using Software-as-a-Service (SaaS) to that calculation. I have been unable to find a benchmark of other SaaS companies carbon footprints, so I am putting out a call for SaaS companies to share their footprint per user.

Rally’s benchmark – 8 tons of CO2 per year for every 100 users

At Rally, we have been growing steadily (227% in 2005-2007, 242% in 2007-2009) at the same time working hard to limit our carbon footprint.  Unfortunately, as a company grows, its carbon footprint often grows with it.

We have been able to keep carbon per 100 users flat at 8 tons per year for the last two years – the same amount produced by a single person flying from New York to Deli, India round trip 4 times. In addition, we estimate that our SaaS customers are avoiding an additional 1 ton per year of CO2 as compared to running an application in a robust manner in their own data center.

What is your SaaS carbon footprint per 100 users?

Lacking any other information, I used our figure – 8 tons per 100 users per year – to calculate our carbon use per 100 SaaS seats for each of our SaaS suppliers including: Google Enterprise Apps, Salesforce Unlimited, NetSuite, Big Machines, Eloqua, Xactly, and Open Air.  I assume our numbers are conservative because we are not the scale of the Google or Salesforce, and we count airline miles and employee commute in our footprint.  Can any other SaaS providers tell me your carbon per 100 users to increase the accuracy of our calculations?

Like Salesforce, we buy renewable energy credits from NativeEnergy to offset the carbon of hosted operations.  This is a very small portion of our overall carbon footprint -  about 7 tons per quarter.  However, it does a couple of things for us: 1) It supports our SaaS service being carbon neutral since 2008,  2) It keeps us learning about carbon credits at a national and local level, and 3) most importantly, it keeps us focused on our goal of zero carbon by 2020.

Do you want to partner?

In addition to our efforts to battle climate change in our industry, we are also working hard in social responsibility by following the 1% model started by Marc Benioff and Suzanne DiBianca at SalesforceFoundation.org.  Last year, we hit our 1% target of volunteer time with over 2,500 hours helping 90 charities.  This year, we are in search for a strategic non-profit partner to help us focus our corporate social responsibility efforts and volunteer time in one of three areas:

1. Reducing the environmental burden from the IT industry (carbon, e-waste, toxins, take-back efforts)
2. Decreasing the digital divide in society (universal access to the Internet)
3. Increasing the level and engagement in corporate social responsibility behaviors

If your non-profit believes it can leverage the 3000+ volunteer hours from a company in Colorado, North Carolina and the UK to help on one of these efforts, please contact us.  We are looking for a true partner who wants to start developing a relationship in 2009.

The importance of sustainability at Rally

Our efforts are based on trying to stand on the shoulders of Ray Anderson from Interface. See Ray’s Fortune interview on pushing through on sustainability in light of the current economic crisis that is radically affecting his commercial carpet business.  Since then, Google’s efforts and Salesforce’s efforts in the SaaS IT space have kept us moving forward.

We look forward to driving zero footprint data centers, increasing remote collaboration technology and having a zero footprint campus in the next decade. We are preparing a sustainability report for 2008, following the Global Reporting Initiative format.  It is not a small project, but it was the clear next step for our sustainability efforts that started in earnest in 2007.  Our goal is to release it by July 1st so stay tuned.

ADDED After Publishing and based on comments:

A better video of Ray Anderson is his speech at TED in 2009, it gives more background, and more data.  – Thanks to David Koontz

Graphic below to provide clear breakdown on sources of Carbon in our business – 6/17/09

#8 in our list of the Top 10 Characteristics of an Agile Organization is about finding the balance between sustainability and success.

In this 3-minute video, I share how organizations can achieve this balance through (1)  stability, (2) sustainable pace, and (3) redefining success based on what the customer sees as most valuable, not just meeting the plan.

See my previous coverage of #10 Work/Life Balance and Jean’s #9 Being a Servant and Leader. Next up is #7 Contributing to the Community and the Company.

In an earlier post, I asked an Agile test question, “Are PMOs Obsolete in Agile?”

While the answer MAY be “Yes!”, I posited that there may be a way to save our PMOs from going the way of the now extinct dodo bird.

8 Ways To Re-Tool a PMO in an Agile Environment

1. Have the PMO involved in helping rollout Agile on several pilot projects

   This experience forms the roots for how the Agile PMO will engage throughout the organization with other project teams.

   Besides ensuring that Agile training occurs, the Agile PMO can become the coaches of coaches, training the ScrumMasters of each team. They can also be the Agile voice into the business to ensure the Product representatives are fully bought into their role in Agile.

2. Learn from Lean: start a Kaizen and Gemba mentality now

   The PMO should be the shepherds of continuous improvement so that the Agile adoption is not only sustained; it is vibrantly organic, every improving. This means moving beyond team-level iteration-focused retrospectives.

   Kaizen events create cross-team learning. This learning exposes team practices that can be useful at an organizational level. In such cases, the team practices are elevated to the organizational “Standard of Work” (see later item). Moreover, the Kaizen event clarifies when a practice does not serve the entire organization and can remain a team practice, supported by team agreements and adhered to by the team.

   In addition, in between Kaizen events, apply “Gemba”. An Agile PMO learns about the organization and spreads knowledge through the organization by being involved in projects. That means going to see, or “Gemba” according to Lean practices.

   Being engaged with teams rather than dictating from afar may be a dramatic shift in PMO behavior. And, it is pivotal to teams’ respecting the role of the PMO in creating a successful Agile adoption.

3. Change your definition of “Standard of Work”

   This is not a set of standards defined by and enforced by the PMO for project conformance.

   In Agile, as guided by Lean practices, a standard of work is a statement of what is currently useful, how things are currently done. It provides a team a backdrop from which to perform continuous improvement through Kaizen events such as retrospectives.

   (In my previous post on the PMO, Brendan Flynn has a wonderful comment about how he and his PMO engage teams at Shoplocal in doing this work.)

4. Facilitate and be a Servant Leader

   Don’t control.

   The Agile PMO, rather than controlling and patrolling, engages in facilitating teams in continuous learning. This PMO encourages empowered teams and amplifies the learning that arises when such teams are truly empowered.

   A great way to provide this facilitation and to engender cross-team involvement is to help organize and facilitate program-level and multi-program release planning meetings and product councils. The Agile PMO formulates a rhythm and a continuously improving agenda to help these meetings deliver the greatest benefit across teams.

   Along with being facilitative, Agile PMOs act as Servant Leaders. They serve their organizations by finding out what they need and getting it for them.

   They lead by serving. They remove impediments. They measure what is a problem for teams so that they can serve teams be removing the problem. They don’t look for status from teams; they look for how they can serve teams.

   So, for an Agile PMO, leading the Agile rollout means finding out what teams need and delivering that. It is about creating collaborative plans, not collecting statuses. For more about Servant Leaders in Agile, check out the first section of my book Collaboration Explained.

5. Provide guidance on regulatory adherence

   In organizations that must adhere to Sarbanes-Oxley, FDA, HIPAA, or other regulatory guidelines, the Agile PMO can represent these “red” (immutable) stories in each team’s Product Backlog.

   The PMO governance work can be the guide to each Product Owner on how to deliver the documents or features that help the entire organization remain in compliance with these regulatory constraints. Governance is now a service to project teams versus being a control mechanism.

6. Seek guidance from Lean to use Flow, Pull, and Innovate as guidelines for organizational-level Agile adoption

   Much of the guidance here has a hint of Lean about it. That is because PMOs work at an organizational level. Moving Agile beyond one or more pilot teams requires guidance for maturing and scaling.

   I recommend applying a 5-step approach which is based on Full, Pull and Innovate principles from Lean Thinking.

   Our Rally whitepaper about Applying Lean Pull principle for Program level Agile is a great guide for the Agile PMO working with programs of teams.

7. Guide non-IT/Engineering organizations

   Once Development group is working with the business to deliver prioritized, valued items, the Agile PMO can bring in other ‘back office” functions to help ensure a growing Agile adoption.

   Finance, HR, infrastructure, the executive team, and others must eventually all accept the Agile approach for true organizational change and value.

   The Agile PMO has an opportunity to be the mentors and guides for this growth and maturation.

8. Foster useful metrics

   Let go of that Waterfall security blanket around what are useful project or program metrics.

   Determine which metrics to track that directly help organizations concentrate on value delivery.

   Whatever does not deliver value is waste. It may be temporarily necessary waste. Or it may be a pernicious, embedded waste that has been assumed to be necessary.

   An Agile PMO ferrets out these “false friend” metrics and works with teams to determine metrics around value: test coverage, team velocity, agile adoption assessment, defect counts, definition of done.

   Look in the Appendix of our whitepaper A CIO’s Playbook for Adopting Scrum for more ideas on useful metrics in Agile adoption.

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.

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.

Original F4 Technologies logo 2002-2004

I know what you are thinking with the title of this post – I am drinking the Kool-Aid. Just bear with me  for a minute. Back in 2002, when I started working on Rally, it was originally known as F4 Technologies. It was known as F4 because I did not want to work on anything that did not have the potential impact of a Factor of Four, for example a 4X increase in productivity or effectiveness.   There are two reasons for this:

1. Andrew MacAfee and John Gourville at HBS have shown that you need a 9X improvement with a new tool, technique or method to un-seed the incumbent.
2. According to Paul Hawken in Natural Capitalism, we need a 4X productivity increase in the use of natural resources to get to a sustainable place with the current population in the world.  Chapter 7 of that book helped form the core purpose and mantra of Rally – “Muda, Service and Flow.”

Now seven years into Rally, we have the proof that teams – including large and distributed teams – can be 4 to 10X more productive by following Lean principles and effectively implementing Agile development.  Like the story of “Good to Great”  from Jim Collins, you can’t leap here, but you can put yourself on that path by adopting a continuous improvement approach like Agile.  If you do that, you can be a “great” software development organization that dominates your market and is 10X better than the good ones.  Great organizations that dominate in their industry also have the knowledge and resources to change world, a la Google.org, the Salesforce.com Foundation and or through my favorite the Entrepreneur’s Foundation.

My summary take-away from Good to Great is:

“Right people building the right things right”

“Disciplined people, Disciplined thought, Disciplined culture “

If you are working toward this, I believe you increase your business value by 4 to 10 times.  I am going to make the case with the help of ROI models from David Anderson.  (BTW, I love his book – it does a great job explaining the simple physics of Agile.)

From Chapter 2 - David Anderson's "Agile Management for Software Engineering"

This is a very simple model of software process.  David shows more complex ones that model all the loop backs of large shipping software, but let’s work with this one.  So, the rough equations to calculate the business benefit of the process are the following:

Net Profit = Throughput – Operating Expense 
ROI = Net Profit / Investment

In the following four pages, I am going to look at how this equation plays out for four different scenarios:

1. Good waterfall team, on the mean line of the QSMA Agile Impact Report
2. Beginning Agile team in Flow benefiting from the 25% productivity savings of an Agile teams in the same study
3. Intermediate Agile team in Pull with incremental releases of value
4. Advanced team in Innovate that cuts time-to-market in 1/2 to end early after delivering 50% of the work but 80%the value

What you will see in this hypothetical modeling exercise is the true power of Agile to dramatically impact the software development teams in the organization. For a deeper understanding of what I mean by Flow, Pull and Innovate, please Jean and I’s white paper on moving to Program Pull.

Here is the summary:

1. Good waterfall team – ROI – 0.8
2. Beginning Agile team in Flow  – ROI – 1.4 (1.6 factor better than good waterfall team)
3. Intermediate Agile team in Pull  – ROI – 2.6 (3.2 factor better than good waterfall team)
4. Advanced Agile team in Innovate  – ROI – 6.3 (7.7 factor better than good waterfall team)

Factor or Four or better – that is why there is such a rush towards Agile development.  Of course, you can’t have your cake and  eat it too.  Moving up this maturity curve takes long-term dedication to increasing discipline and agility across the entire organization, but there are dramatic benefits if you can get on the continuous improvement path and stay there.

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