Agile Development Blog

When I am coaching a team through their first iteration, I often have a Scrum Master and/or team lead pull me aside prior to the retrospective to express concerns.

Sometimes its about things they know the team should address in the retrospective.
(e.g. “we need to get better at estimating”)

It may also be about things they wish the team wouldn’t bring into the retrospective.
(e.g. “we want longer iterations”)

These team supporters are coming from a place of concern for the success of the team and their Agile adoption, but they aren’t trusting that the team will make the right decisions on their own.

They want me to make sure the team talks about - and only about – these specific items, sometimes asking me to explicitly bring the issues in with a softer (i.e. manipulative) approach. I tell them I can’t and I won’t.

I tell them they need to trust the team and trust the process to determine where to focus their collective energy, passion and time in order to improve their process and product. And almost always, the issue a compassionate and involved leader hopes the team will focus on is exactly what the team ends up discussing and moving forward with.

This isn’t just about the team taking responsibility for their work and their improvements, it’s about creating sustainable decisions the team can own.

Good team leaders and Scrum Masters create a space where teams can inspect and adapt safely and successfully, so they can continue to find ways to improve.

Making New Agile Teams Successful breakout with Erika Peace of ICS and Chris Browne of Rally

Having now returned to Boulder and unpacked my bags, I wanted to reflect on the great experience I had moderating our most recent Agile Success Tour event in DC.

Our 5 executive panelists provided such great insight into their Agile adoptions, each with a different perspective.

The Q&A session that followed brought out puzzles and challenges from the participants, and it was great to feel their energy and passion to learn more. This flowed so wonderfully into the 5 breakout sessions that no one even wanted to take a break afterward!

In fact, the energy stayed so high through our final remarks and lunch that it fed even more insights from our panel. And, the audience was so highly engaged that many chose to stick around after the event to continue one-on-one as well as group discussions.

It was a pleasure and an honor to once again be a part of an Agile event that provided such genuine value to its participants.

One other note from DC: as usual, Israel Gat did a great job with his pre-event engagement work with the panelists. And, he has continued his tradition of capturing pivotal moments and pithy insights in his post-event blog entries. I encourage you to read his Threads from Washington, DC post for a breakdown of some of his favorite discussions from the event.

Stay tuned to the Agile Blog for videos from the DC event as well as details about our next round of FREE Agile Success Tours!

“The greatest obstacle to discovery is not ignorance – it is the illusion of knowledge.”  – Daniel J. Boorstin

Here’s something your team should look to avoid – Cargo Cult Scrum.

Members of the John Frum cargo cult

Cargo Cult Scrum is what happens when you adopt the practices, vocabulary, and artifacts of scrum but you don’t understand why or how they work. Cargo Cult scrum is bad. It is accidental and is based on ignorance.

Here’s a tiny piece of what Wikipedia has to say about cargo cults:

“A cargo cult is a type of religious practice that may appear in tribal societies in the wake of interaction with technologically advanced, non-native cultures. The cults are focused on obtaining the material wealth of the advanced culture through magical thinking, religious rituals and practices…”

When we talk about cargo cult implementations of scrum we are talking about people who seize on the advanced ideas of scrum and expect magical, unexplainable benefit to come from them, not realizing that informed usage is required in the bargain.

Craig Larman and Bas Vodde talk briefly about Cargo Cult Scrum adoption in their excellent book “Scaling Lean & Agile Development” in a section titled Avoid…Fake ScrumMasters. Fake ScrumMasters are created by “…Changing the title of someone to ‘ScrumMaster’ while he acts like – and is encouraged by the organization to act like – a project manager.”

They go on to describe the ultimate cargo cult scrum implementation:

“We adopted Scrum. Our Sprint length is the length of our project. The Product Owner decides the items in the Sprint and the project manager acts as ScrumMaster. He makes the Sprint Backlog and assigns the tasks to people in the team.”

So what does Cargo Cult Scrum look like?

Here are some examples that I’ve seen in the field:

• I recently attended a meeting at a company that considers itself to be agile. It was a regular meeting that occurred every two weeks. It was not attended by a scrum team, but instead by a bunch of people from two different groups. The three questions were not used. The meeting was scheduled for, and took, 30 minutes. Yet the meeting was called a scrum. Other meetings at this company are called scrums, so much so that ’scrum’ has become a synonym for ‘meeting’. This is a cargo cult. The true meaning of ‘daily scrum’ has been lost, if it was ever apprehended in the first place.

• I’ve also seen organizations in which people call every item on the Product Backlog a User Story (which is not the same thing as every item on the Product Backlog actually being a user story).

• Another example is this actual [paraphrased] conversation I had with a potential customer:

Customer: Oh yes, we’ve been doing agile for a while.
Coach: That’s great! So you haven’t had any trouble getting the Product Owner to work closely with the team?
Customer: Well, we…uh…don’t really have a Product Owner.
Coach: Oh. Well, who keeps the Product Backlog in shape?
Customer: Well, we…uh…don’t really have a Product Backlog, per se.
Coach: Oh. So how do you plan your sprints?
Customer: Well, we really don’t do that in a very formal way. But we do meet every morning. That’s what it’s all about, right?

• And my all time favorite. I was once told by a manager of a supposedly Agile group: “We like things the way they are. We know it’s not perfect. We don’t want to change.”  Yikes. So much for Continuous Improvement.

Though you shouldn’t do Cargo Cult Scrum for any reason, the reality is that any step down the road to scrum is usually better than whatever preceded it.

Don’t feel bad if your scrum implementation isn’t the same as what’s in the books. Feel bad if you are have stopped trying to make it better.

About the Author: Alan Atlas is a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

And the number #1 Characteristic of an Agile Organization is…

“The Commitment to be Great”

The ability to make the commitment to be more than just good comes from the ability to drive a culture of discipline that balances the metrics of profitability and reputation.  Hopefully you have seen and heard that message come through in the other items in our top 10 list; I applied these concepts from Jim Collins’ in “Good to Great.”

“Greatness is not a function of circumstance.  Greatness is largely a matter of conscious choice and discipline.”

In the world of software development, an agile organization does not settle for having agile stuck in ghettos.  An agile organization makes the commitment to go up the learning curve and blow past amateurism.  As Jim describes this takes an organization that can increase the discipline to support increasing levels and scale of agility. Discipline to:

• Regularly plan at the five levels (daily, iteration, release, roadmap and long-term vision)
• Regularly make and meet the commitments you make based on a sustainable pace
• Regularly inspect the progress & metrics and adapt the plans at each level
• Make decisions based on the data, culture, and purpose

As Alan talks about at Amazon, it was just the OK from management that was needed.  As Israel talks about at BMC, it was a Social Contract.   You know what kind of commitment you need at your organization to scale agile.  You need to get it to really improve and make your transition happen.  Please, don’t settle for a weak commitment.  It leads to isolated adoption,  ghettos, and a slow, muddling adoption process.  Scaling agility beyond just the development teams can be simple and rewarding, as long as you start with the commitment.

Here is a quick refresher of the complete Top 10  list:

#1 Commitment to be great; disciplined culture and metrics

#2 Creating Your Own Reality and Corporate Vision

#3 Quality and Faster

#4 Personal Flexibility and Rhythm

#5 Bottom-up and Top-down Decision Making

#6 Collaborative and Smart

#7 Contributing to the Community and Maintaining a Profitable Company

#8 Sustainable and Successful

#9 Servant and Leader

#10 Work/Life Balance and Consistent Delivery

I hope you have enjoyed our series on the top 10 Characteristics of an Agile organization, it was a pleasure doing this with Jean, Anne and Grant.

Let us know if we missed something?

Last week, I ran our quarterly planning session and was very positively surprised with the results of testing Toyota’s A3 method in the meeting. Before the meeting, I was convinced that I was trying to “push” too much, but instead the team sucked them up.

Breakout groups at Rally quarterly planning

If you don’t know what an A3 or problem sheet is, I recommend starting with John Shook’s article in the MIT Sloan Management Review.

What is an A3?

John says in his article, “At Toyota, there exists a way to solve problems that generates knowledge and helps people doing the work learn how to learn. Company managers use a tool called the A3 (named after the international paper size on which it fits) as a key tactic in sharing a deeper method of thinking that lies at the heart of Toyota’s sustained success.”

An A3 is a problem sheet in which the owner attempts to:

1. “Establish the business context and importance of a specific problem or issue

2. Describe the current conditions of the problem

3. Identify the desired outcome

4. Analyze the situation to establish causality

5. Propose countermeasures

6. Prescribe an action plan for getting it done

7. Map out the follow-up process”

There is much more information on this topic on the Lean.org blog.

Introducing A3’s to the Rally team

At Rally, we started using A3’s to diagnose issues due to growth and market maturity last summer.  I hired a trainer and friend from my US WEST days Jay Arthur and focused our first effort on product marketing and product management.  In that three-month effort, we had very positive results from working 4 simultaneous A3’s and built a well prioritized backlog of countermeasures.  We knocked off the highly feasible and highly effective ones that next quarter, but we continue to work off that list today.  After product marketing and product management, we brought the technique to operations team, too.

Given this foundation and 25% of our team trained on A3’s, we brought them into quarterly planning as part of our rock prioritization process. Jean and others warned me that it was a ton to grasp in fully packed day of checking the last quarters results and adapting for the next quarter. For that reason, I was prepared to fall back to our old way of working and prioritizing.

Homework is good?

What happened was even more than I could expect. Instead of throwing out this process, the team embraced it and even worked through breaks. Using A3’s to structure your thinking requires discipline and critical thinking.  I guess there was more pull waiting in the room than I expected; maybe it was the required reading of John’s article that helped?  My conclusion – homework is good?

As Jean and I continue to explore what makes an Agile organization, I am curious as to what others are using in their business planning processes to prioritize their quarterly or annual efforts.

About the Author: Ryan Martens is an avid outdoorsman, founding board member of the EFCO, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

#2 in our list of the Top 10 characteristics of an Agile organization is about the great combination of “Create your own reality” and Corporate Vision.

At Rally, one of our core values is “Create your own reality.” In this 3 minute video, I talk about how successful Agile organizations embrace a practice of holding a corporate vision and yet encouraging people to find where they can best bring their talents to bear. In a traditional organization, a corporate vision may be the source of very strict, very detailed role descriptions and role assignments. The corporate vision in an Agile organization acts as a guide for how to help people contribute their best work for the overall corporate goals.

Watch my video for more about why I truly believe in both “Create your own reality” and Corporate Vision as key success factors in Agile organizations.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company, #6 Collaborative and Smart, #5 Bottom-up and Top-down Decision Making, #4 Flexibility and Rhythm, and #3 Quality and Faster.

Stay tuned to find out the #1 Characteristic of an Agile Organization

The Agile Blog is proud to present the first post from our newest contributor, Agile Coach Ben Carey

As part of our coaching at Rally, we usually recommend that new Agile teams use capacity as a countermeasure for not having a historical velocity. Considering individual and team capacity can help the team make an informed commitment for their iteration plan if they don’t have a historical velocity.

One general way to calculate the capacity can be seen below:

A team can use their individual capacities to indicate the maximum theoretical amount of work that each individual can complete in an iteration. Reviewing individual capacities against task estimates can help the individuals not over-commit and also help the team determine the amount of risk in committing to the stories that have been chosen for an iteration.

You can see your utilization percentage in Rally by looking at the Team Status page. As a general rule, I usually recommend that a team try not to exceed 70% of their capacity for each individual on the team.

There are many times that this recommendation is met with resistance because of the basic assumption that 100% utilization (total work divided by capacity) is the ideal state. I’m often asked to justify my general rule of 70% and asked why I would pick a number that is lower than the maximum.

Why I recommend capping individual capacity at 70%:

At a basic level, it seems to makes sense that we want everyone to run at full capacity. If the capacity exists, why shouldn’t we use it? Why would we ever want someone to do six tasks if they have the capability to do eight?

The problem with the 100% utilization mindset is that we have assumed that our outcomes of the iteration are fully deterministic.

When we consider the delivery of software, we need to acknowledge that a given set of inputs do not always result in a given set of outputs due to various degrees of variation in multiple aspects of the process (e.g. fire-fighting, estimation precision, defect introduction, management directives, interpersonal interaction, et cetera). In reality, software development activities are stochastic in nature.

If we look at other areas that are defined as being stochastic, we can build a mental model that can help us understand why 100% utilization isn’t the ultimate desirable state.

Let’s use a highway as an example…

photo courtesy of devinkho

A few general observations, you’ve likely noticed:

• The highway typically slows significantly below 100% utilization (the maximum number of cars that can fit on the road).
• The rate at which the highway slows is non-linear. Traffic will start to slow significantly faster between 80% and 90% utilization that it would between 40% and 50% utilization.
• When accidents occur or a lane shuts down, the effect is much more significant at times of high utilization (rush hour) than at times of low utilization (late night).
• The likelihood of reaching gridlock in a fully utilized highway becomes almost certain if it fills to capacity.

These observations can all be attributed to variation in the process.

In many ways, creating software is very similar to driving along a highway. There are a variety of unknowns, a variety of random events that might occur, continuous minor corrections, and a variety of options in getting to our end goal.

Luckily, software development isn’t the only place that we can look for to get some guidance on how to effectively determine our utilization.The nature of stochastic systems has been studied in many fields (telecommunications, fast-food restaurants, transportation systems, manufacturing, processors, and many others). In many of these fields, the general approach at modeling the variation in the system can be found in the study of queueing theory.

If we look to queueing theory, we can find some level of guidance with the following general capacity model.

This model shows us that utilization in a stochastic system follows a power-law distribution.

As we reach the upper levels of utilization, the nature of the work we are performing will likely lead to intense thrashing and will likely have impact across all areas of the work that we are performing. If anything doesn’t go exactly to plan or any other non-planned items come into play, we are likely to jeopardize our commitment.

Given the rate that these items tend to occur, I recommend not aiming for 100% utilization.

Bottom Line: When I see a team of individuals that have (1) calculated a realistic capacity, (2) applied honest estimates to their tasks, and (3) targeted a maximum capacity of 70%  – then I feel good that they have done their best to provide a realistic commitment to achieving the completion of their stories for the iteration.

[ Check out more posts from Ben Carey by visitng his blog - The Sherpa Project ]

“You learn more quickly under the guidance of experienced teachers. You waste a lot of time going down blind alleys if you have no one to lead you.” -W. Somerset Maugham (1874 – 1965)

Filmed at Rally’s Agile Success Tour events, these videos detail the real-life agile implementations of software/IT executives who have taken the enterprise agile journey and are now realizing the benefits of enterprise-scale software Agility.

Our coaching and technical account teams (including Jean and myself) provided guidance to many of these panelists during their initial steps in their journey.  It gives me great pleasure to see them now become the teachers and share their expertise with the new generation of practitioners.

Don’t pass up this great opportunity to learn from the experiences of others!

click here if video player is not loading in your RSS reader

Catch the next Success Tour events in Boston, Seattle, Chicago and London this Fall
These events are free, but registration is required.

#3 in our list of the Top Characteristics of an Agile Organization is Quality and Faster.

Ryan and I have been talking about quality and faster as necessary components of an Agile organization for awhile. A non-Agile view of a successful organization would have us believe that pushing more and more features into a release and to the market necessitates a loss, or at least reduction or great variance, in quality. In an Agile organization, the thinking is quite the opposite.

Curiously, when we speak of quality and faster inside Rally or with clients, we talk about each being indispensable to the other.

For a traditional, non-Agile case study, let’s look at the RCA case study Ralph Aguayo brings up in his book “Dr. Deming: The American Who Taught the Japanese About Quality.” At its height, RCA’s business model focused on getting as many televisions into the hands of consumers as possible. (Did your family have an RCA T.V. when you were growing up? Mine did!) Quality was secondary to the savings RCA could make from cheap components and speed of product to market. Cheap and fast meant greater profits. Well, as it turned out, no…

Nipper on RCA's first color tv set - the CT 100

Unfortunately for RCA, their model began to crumble when television sets started being returned due to defects, lots of them all still in the warranty period. The cost of attending to these faulty sets ended up being as much as 25% more than the cost of manufacturing the existing set.

Do you have a similar situation in your software product delivery? Are you trying to get profits by pushing features out with “defective parts” because they are “cheaper”?

And to throw another wrench into the works, are you taking so long to get these feature sets pushed out that you have too much of a delay in your feedback to find either the defects or the value of the features you pushed? In other words, is your emphasis on speed, at the expense of quality, coupled with very large feature-rich releases, exactly the wrong way to create greater value and fewer defects?

In an Agile organization, the entire organization concentrates on value delivery and quick feedback on that value.

That is, “are we delivering the right features to the market?” In turn, a real Agile organization understands, “there ain’t no such thing as a free lunch,” and they do increase throughput without the traditional expense of decreasing quality. Defects held in check through a “stop the line” mentality free-up the organization to always respond to value feedback information faster. Think about RCA. If your scarce resources are tied up in managing defects and “returns,” they can’t be working on new feature sets. Or the feature sets delivered are being pushed on defects not yet resolved.

And so, the notion of “quality and faster” is not so counterintuitive as we may have once thought.

We need faster and faster feedback loops in time-to-market in order to continuously improve our ability to deliver quality (defect-free and valuable) features back to the market. Symmetrically, we need higher and higher quality features that are not defect-ridden or dubious in value in order to respond ever faster and more innovatively to the market.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company, #6 Collaborative and Smart, #5 Bottom-up and Top-down Decision Making and #4 Flexibility and Rhythm. Stay tuned for #2 “Creating Your Own Reality” and Corporate Vision.