Thomas Crane, in his book “The Heart of Coaching” identified a model from an article in the November 1979 issue of the “Training and Development Journal”. Sadly, I could not find the original article, but I’ve adapted the diagram to communicate the model. If we think about change on two levels, we see that there are changes in behavior and ultimately changes in results. These two dimensions remain roughly proportional in a static system, as your behaviors impact your results. Things get really interesting once you try to change behaviors. We frequently see this done by sending people or a team to training. Indeed, the “Certified ScrumMaster” classes, are often this point of entry. Now we see that behavior changes, but once someone goes to apply this new behavior, the results are actually worse than when they were using the old behaviors. Many people are familiar with the idea of the “j-curve”, as we use a new practice for the first time, we’re actually quite clumsy and our outcomes are not as good as if we were using an old technique. For those of you who ski, when you first learn to parallel ski, it’s actually much harder to get down the mountain. In fact, when you ski an expert trail, you probably find yourself reverting back to the snow plow. It may be a less refined technique, but you’re effective with it. This is exactly what we see when people first learn and apply Agile practices.

Training with No Coaching

What we observe is that while one’s behavior change at first, they are immediately put back in their prior environment and begin to revert. Perhaps not everyone went to training or the boss doesn’t really care about Agile. As Weinberg observed, the cucumber eventually gets pickled. What’s really interesting as that at the same time, our poor change champion is not performing at a lower level as they try to use new practices. Thus, the “new” stuff actually feels worse than the “old” stuff they were trying to fix. We know some of this is a learning curve, but the observed behavior is that as one reverts back to the prior standard, results are actually getting better. Thus, one can settle at a level with slightly better behaviors and slightly better results, feeling like this is the proper place to be. David Douglas and Robin Dymand talk about a situation they call “we suck less” and I think this nicely summarizes how people can fall into that trap.

Training with Coaching

So how do we help people maintain, or even improve, their behaviors after a training class? Well it must be reinforced, and this is where coaching comes in. Having committed time and energy to learning a new way of doing things, people need ongoing support as they begin to apply them. No matter how good your training class, it will never be a substitute for the messy reality of the world in which we must all operate. Also, we need to remember that there are very real pressures that have driven us to our prior behaviors. We need to begin to apply counter pressures so that we don’t revert back to old habits. This second diagram shows the two dimensions, but now the team receives coaching after they complete training. The coaching helps reinforce practices so that they don’t abandon their behaviors as they move through the adoption curve. As results get demonstrably better, this can create a virtuous cycle where coaching can eventually ramp down and the team becomes self-sufficient, continuing to improve it’s own performance without any external support.

Like many things, this probably introduces more questions than it answers. How long is the right amount of time for coaching? What if the coach is hands on, or the team is supplemented with other experts to get through the adoption j-curve? Are there other ways to change the environment such that teams feel positive pressure to maintain behavior besides through a coach? These all probably merit further discussion, but let me leave it here for now. So I am curious, what are you experiences with rolling out Agile, or any type of change, initiatives? Is this model consistent with your experience?

Within the large organization, I can appreciate the desire. Indeed, there certainly are some benefits around transparency, consistency and institutional knowledge to be had when we get everyone to agree to a standard. This is a careful balancing act, as the benefits may prove elusive and the risk is very real. First with transparency, while working code is the best indicator of progress, as teams grow into the hundreds, that can become too much “product” for an executive to effectively review and understand. This closely dovetails with consistency, where teams need to have common understandings of how to exchange stories, what “done” really means, and even what technical standards they will follow.

Technical standards can be quite pernicious, as enterprise licensing agreements, technology stacks and other architectural decisions can place very real requirements on how teams operate. We do like to think of each team as a trailblazer, but at some point, if you have three web development teams, one chooses ASP.NET, one chooses Java and the third chooses PHP, it doesn’t take an expert to see there is wasted energy. Lastly we come to the idea of institutional knowledge. As a consultant I can certainly appreciate that companies have a desire to “do it on their own” and apply hard earned lessons in one project to future ones.

It is not that these are invalid desires or that some benefit can’t be reached from standardizing, or as I’ve been calling it “institutionalizing” a Scrum implementation. Rather, it’sthat we need to understand the cost of each decision we make and weight it against the benefit. I think back to one of my earliest experiences in project management. An aspiring PMP, I was kicking off a project and I took out my PMBOK to find out what tools I could use to charter and initiate a project. From analyzing stakeholders to managing risk, I’m pretty sure if there was a checklist or template, I used it. At the time I didn’t understand exactly how each one applied, so I compensated by using every single one. Surely, this is not Agile, nor how one would advocate something like the PMBOK be used. I took a list of possible tools and considered them a mandatory set of things to do. Just like that, a supporting resource became a requirement and my project was about following lists rather than delivering value.

I see a similar challenge if an organization begins to offer too many guidelines. So what is the right limit for acceptance criteria in a story? Well, in my case, I took a 3×5 note card and figured out how many sentences I could fit on one side. This brought me to the recommendation of 7, but does it mean if I only have 2 that my story is wrong? Of course not. A better measure would if it clearly articulates what the story needs to do, is agreed upon by the team and they can commit to do it in a sprint. Then again, even user stories are not explicitly part of Scrum, so are we now mandating that all project requirements be formatted in this construct? Just because something makes sense in one domain, doesn’t mean it should be applied elsewhere.

Indeed, using a framework for empirical feedback like Scrum provides one with infinite ability to inspect & adapt. Of course, a common challenge with standardization is that, we have two groups of people: one group who is defining the standard and a second group who is trying to use it. Thus we have one group using the process and getting feedback, but a different team is supposed to make adaptations to the process, but is not experiencing that feedback directly. This is the paradox I alluded to before. In order to get a large organization to use a highly flexible & adaptive process, we must take away some of that flexibility by taking decisions out of the hands of individual teams and delegating them to centralized committees. When this is done, does the value proposition remain intact? How do we go about confronting making consistent & transparent Scrum throughout a very large organization without fundamentally undermining the nature of this framework?

I know many people have talked about this topic and I will certainly have more to say about it, but for now I think the key is to figure out how to standardize on the principles and keep maximum flexibility, but I can see this blog post is already too long so let me leave it with that until I continue this thought later. I’d love to hear your thoughts in the meantime.

Personally, I find this question one of the most loaded within the profession, “so how much (faster/cheaper/in some way better) will using Agile make my projects?”

This is certainly a legitimate question, but there’s frequently an undercurrent that indicates a very narrow perspective on what one is willing to invest in such a process. I do not mean to imply that there are not tactical performance improvements to be gained from using Agile, they are legion and well documented. Rather, if we focus purely on simply spinning the wheels faster, we will surrender a significant amount of potential value and ultimately limit the success of such an initiative.

Just the Numbers

Before diving too far into the details of these “other benefits”, let me speak to the first question of tactical improvements. Mike Cohn put out a pretty authoritative presentation on the topic of performance improvements, it is available to all and licensed under the creative commons. Let me share a few highlights from sources he found, as well as some I’ve come across:

• According to QSM’s Agile Impact Report in 2008, Agile teams are 37% faster to market, 16% more productive and, most interestingly, able to support crashing project schedules by up to 50% without seeing geometric growth in defects.

• Several different organizations conducted surveys in 2008 asking respondents to identify the benefits they have realized from using Agile. These include VersionOne’s 2008 State of Agile Report, Tech Target’s 2008 Agile Survey, and Dr. Dobb’s 2008 Agile Adoption Rate Survey. I have included a summary of the responses.
  

• The Standish Group’s infamous CHAOS Report has shown a marked improvement in project success rates since 1994, having moved from 16% (1994) to 29% (2004), and many within that project have specifically highlighted Agile as one of major sources of that improvement

Faster Isn’t Enough

I am not one to  begrudge someone for desiring to spend less money in order to build software faster and with less defects, but I can’t help but think of that old joke about the expedition in the Amazon rain forest. After several difficult days in the forest, the team begins to make progress. They are moving much faster and are covering quite a bit of ground. One of the men is curious how fast they’re going. He climbs up a tree, surveys the surroundings, and shouts back down, “we’re going in the wrong direction”. Someone shouts back, “but we’re making great time!”

Indeed, this is the key challenge, and potential benefit, that the values and practices of the Agile Manifesto seek to address. It’s not about improving our throughput by 10%, it’s about building fundamentally better software in a collaborative way that maximizes the value of our business partners based on their circumstances. Let’s talk through a few dimensions in which to consider how Agile can help us.

Financial Performance

Many people discuss the value of time to market in the abstract, but sometimes it’s good to offer a concrete example. Imagine two projects, one delivered after 1 year (let’s call this one “Traditional”) and the other incrementally beginning at month 3 (let’s call this one “Agile”), with the following assumptions:

• Both projects yield $3 million every year, once they are up & running.
• Both projects will take 1 year of project work to complete.
• Both projects run perfectly and at the same rate, meaning the product is fully built after 1 year at the exact same cost.
• Upfront costs are $100k and the team costs $1.25M a year to run (20% of that in future years to support).
• The cost of capital is 15%, charged over 6 periods every year

What we see is that the Agile project, under the exact same circumstances, will have a NPV value of nearly double the traditional project, due entirely to the value of earning cash flow early. I must give credit for this spread sheet to John Scumniotales, who first put together a similar scenario here. I have modified his assumptions slightly to make it more conservative, you can see my version here.

Other than the return, there are a few other points that bear mentioning in this model. Note that the Agile project has a significantly lower financial exposure ($900k vs $1.4M) and that it reaches that exposure earlier than the traditional project (month 8 vs. month 16). This means that the Agile project will bear less financial risk, and we will know if we are going to break even much sooner. Now, of course, this argument is predicated upon teams being able to plan a product that can launch early and incrementally. This is not a given, and brings us to the next point that early feedback helps us build a better suited product to whatever the need its trying to fit.

Product Quality

I must be careful when I say “quality” as many of us have been conditioned to think that simply means “less bugs”. As we saw earlier, this is a real benefit of using Agile, but it is not what I’m talking about now. What I’m thinking about are those projects that were “paper successes”, where it is brought in on time, on budget, and too spec, but unfortunately it doesn’t actually solve the underlying problem. These are a pernicious challenge for IT professionals. My very first big project was delivered according to the plan, but it didn’t do what the business needed. Now my manager told me that it wasn’t my fault. They should have given us better requirements. This explanation never sat well with me, and it is one of the things that has led me to embrace the high levels of collaboration and empirical feedback championed by techniques like Scrum.

Let me offer another example, in 1994 Fox won broadcast rights for the NHL. They wanted to increase viewership and surveys of potential viewers showed that new comers had a hard time keeping track of the puck. Focus groups indicated that these people would like a way to better track the puck as it moved around, and responded very favorably to the idea of visually highlighting the puck on television screens. The network was under a tight deadline for the NHL All-Star game in 1996. A team was commissioned to achieve the task with $2 million. The outcome was far from certain, even up to a week of the event. The team tried a variety of technologies including radar before settling on a series of infrared LEDs to be contained within the puck and a relay of sensors around the ring hooked up to quite a bit of processing power in order to add visual effects when the puck was in the air or traveling faster than 70 miles per hour. Ultimately the team delivered on time and it was a technical success. Unfortunately FoxTrax has moved on to hockey infamy. As one reviewer lamented, “I watched a hockey game Saturday night and an episode of ‘Star Trek’ broke out” (St. Louis Post-Dispatch, 1/22/96).

While FoxTrax remained somewhat popular with people new to the sport, die hard fans hated it. The technology was used for about two years, and then retired shortly before ABC got broadcast rights in 1998 (more details are available here). Thus, we are faced with an ambitious technical project that was delivered, but was ultimately a market failure. Here’s where we need to be careful about the fine print, when we see things like the CHAOS report show project success rates of about 30%, they are measuring based on technical measures (budget, time, scope). They do not take into account situations like this, in fact, this project would be defined as a “success”. If we look towards Agile to simply make us “go faster”, we completely surrender the opportunity to leverage our incremental and iterative approach in order to make a better product and avoid situations like this. This is what I mean when I refer to product quality.

First, let me give a good non-IT example that I find most interesting. The America’s Cup is a series of sailing races held throughout the world. It is so named as the first ship to win the race was named the “America”, as well as the fact that the USA has the longest sporting record, having won the contest for 125 years from 1857 to 1983. For those not familiar with the sport, it is an intense contest, not only in the performance of the sailors, but also in the design and construction of ships. The only team to beat the Americans twice is the team from New Zealand and their boat “Black Magic”. What’s most interesting is the way they went about building this ship. While the Americans had invested immense amounts of resources in the best computer modeling available at the time, the Kiwis put their designers in the the shipyard with the those responsible for building the boat. They settled on a design and build two ships. Next they allocated 6 months to race the two whereby they would use one ship as a control and the other as a variable to test out different modifications. This is an elegant demonstration of using iterations to design a product based on empirical results, the performance of a boat with a given design modification. Nobody knew what the boats would look like coming out of that six month window, but it certainly was impressive. When the boat first debuted in 1995, it not only won the cup 5-0, but only lost one of the 43 races entered that year (more details here).

The Challenge of Iterative Delivery

I really do enjoy this example, but it illustrates a fundamental challenge we face when trying to run Agile projects: namely, how do we iterate on a product? Jeff Patton first highlighted this dynamic (to me at least) in a post and subsequent presentation he gave about embracing uncertainty. He articulates that there are two different things we do when we break apart a product: we can break it into increments, which would be a distinct and discrete component such as an engine, power train, and brakes, and we can break things into iterations, which are revised versions of a complete whole, such as the 2009 Civic and the 2010 Civic. If we focus too much on increments, then we lose the ability to actually iterate over an entire product and make improvements. This is frequently seen in those projects where someone says “we want to get this right the first time” or people are upset they must revisit a component that was already built out. If we plan our projects around building each part once, we will invariably fail. A truly Agile project, must be planned around iterating over an entire product, because we know that we won’t get it right the first time and the sooner we get the first time done, the sooner we can get feedback to maker it better.  This is born out in numerous research such as the CHAOS report, which shows that 80% of a system’s functionality is implemented in a subsequent release and 66% of all features are rarely or never used (think Microsoft Office). Now, in reality we have to blend approaches, but the fundamental point is that the sooner we get a functional product, the sooner we can get meaningful feedback to build a better product and financial benefit for the company. I will offer one more non-technical example.

Imagine a house, if we build a house increments (the foundation, the walls, the roof, etc.) then we don’t have something we can live in until the end. We also face maximum financial exposure upfront, and must make all design decisions at that time. Whereas, if we build a home and expand on iteratively (a dormer, a garage, a new wing), we can continue to refine and enhance the house all the while having a place to live in simultaneously. Of course this is not a perfect example, as software is infinitely more malleable than wood, brick and mortar, but I hope the analogy demonstrates the concept.

Personally, I think this is one of the most exciting and interesting things about Agile projects, as we must be creative in the way we frame them in order to take advantage of iterations. My first “aha’ moment in this field was with a financial service company building a new webpage. As time went on, they became increasingly frustrated over performance. We had not surfaced it at first, but the page’s performance was a primary concern. So we set up a new feedback loop, and ran a very crude performance test in the development environment with every hourly build. It did not extrapolate perfectly to a true performance environment, but it gave us an excellent tool to engage and discuss with the customer about just how much they wanted that next feature, as well as how much it would cost them. We had total transparency into how much each new component impacted the performance of the page and this led to a website that looked remarkably different than what people originally imagined, but it met their primary concern, and was better suited to their needs than what they originally conceived.

Responsiveness to Change

By now, I hope you all agree that we won’t ever get our requirements right up front and its a fool’s quest to try to do so. But, even if we were to have a magic wand that would give us perfect requirements, the exponential nature of change makes it a moot point. Several educators put together a video titled “Did You Know?” discussing the challenges facing modern educators. It has been wildly popular and I would recommend you see the latest version here. This presentation discusses several points that merit further exploration, but let me focus on just one, the adoption of new technologies. We are now at a point where industries can change in what used to be the cycle time of a traditional project.

Ultimately, this is our last benefit to be realized from Agile practices: the ability to change. If we work in a clear manner where we’re building just enough to meet our immediate goal, we undertake good technical practices like test driven development and we have good, frequent feedback on our product, we are in an excellent position to make adjustments to the vision of our product based on the reality around us. Now this is not necessarily efficient, and it doesn’t helps us with project success metrics if we’re looking to measure things as being on budget, on time and to the original specification, but it is profoundly valuable nonetheless. In fact, this is where we see virtuous cycles. As we saw earlier, Agile projects have less financial exposure, thus there is less at stake if we need to change path, this can be profoundly valuable when we talk about the human condition and our propensity to avoid realizing a loss. Second, we discussed how Agile helps us refine the vision of a product as we go if we don’t have a certain product vision, then change becomes significantly easier.

Conclusion

As I look at the history of project management, I can’t help but see how the legacy of scientific management as defined by Frederick Taylor has been a double edged sword. On one hand, he was the pioneer of using empirical feedback. He dubbed the term “scientific management” and proposed that all tasks be designed and managed based on verifiable measures. Unfortunately he was also the person who said that there should be a distinction between those who define the work and those who execute it. Sadly, I see this legacy in so much of what we do today in IT and it is an expensive piece of mental baggage. It implies that the truly valuable people must be “managers” thereby creating a career track that encourages people to give up their technical skills. It creates a schism between those who will do the work and those who will plan it, ensuring that there will never be full buy in. And ultimately, I think the spirit of that Mr. Taylor is in the question “how much faster will Agile make me”, as it implies that we are simply running a factory line when we build software and its simply a matter of getting the line faster. Some people have been very successful with this mental model, but my experience has been that it sacrifices a significant amount of value for the team and makes for a much less enjoyable workplace.

Thanks and I’d love to know your thoughts!

Incidentally, for those of your using Windows and MS Office, this was done quite easily with Wondershare’s PPT to Video application and Windows Movie Maker.

“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.”

It struck me it was ‘the’ perfect story. It has a role, action that had to be taken, and a goal.  But most of all it had a very tangible, clear, and explicitly well defined definition of DONE – “returning him safely to the earth.” What a story!  What an Epic! What a way to get a nation – a world – to focus.   But it wasn’t a user story – it had this timeboxing clause,”before this decade is out,” that started the clock ticking.

I refer to it as a Focus Story. It serves as the transforming agent changing a poetic visiony user story into a ‘Mission Statement” and a Commander’s Intent”. With it in place, at the top of Product Vision, enough guide rails are in place to make reasonable initial roadmaps, release plans, prioritization criteria, and definitions of done.  But most of all we have a means to understand core values criteria “safely to the earth”.

We also have triggers to inform us when we are losing focus –  Meetings get longer, Done isn’t understood. Pieces don’t fit and the conventional mindset you have been struggling to win over sighs and goes back to its safe place of waiting for the fad to die.  When these show up it is time to revisit the focus story and build a bigger focus or wrap up what you are doing.  Otherwise you risk having “O”rings show up on your Columbia launch.  Nobody wants to be part of that type of bad day.

Agile 2009: Mapping the Change Battlefied

Are you considering a coach?

If you aren’t, are your organization and projects at risk?

Fire! Ready, Aim…
Many organizations, thinking that they can’t afford or don’t want to invest in coaching or training, read a book and some articles, and tell their teams that they are now doing Agile.

I have never seen a team get great benefits from Agile in this way.  When I am coaching, and I hear other teams that aren’t being coached say “we’re doing Agile,” I raise an eyebrow (in my mind anyway), and find out if I can spend some time with them to see what they are doing.  Without fail, these teams are doing “Scrum but,” “CrAgile,” “Scrummerfall,” or some other thing that only resembles an Agile method minimal ways.   There are many articles on these topics.

How might coaches be engaged?
I’ve heard that some people use the analogy of a Soccer Team to make the point about what a coach is and how coaches might be engaged:

Wing It
Consider a soccer team.  You could read about soccer in various books and other references, and then attempt to play.  Chances are, though you may learn some of the basic rules, your team will not perform that well without great luck.

The Clinic
You could have this team go through a 1-week soccer clinic to improve their abilities.  They will probably learn some new tricks, maybe a bit of strategy if you’re lucky.  But rarely will such a brief improvement effort result in drastic, long-term improvement as a team.

The Ramp-Up and Check-In
Now consider the same team if they had involvement from the expert who held the clinic for 3-4 months.  The coach could provide the same techniques and training, and apply them to real situations as the teams go through them.  This is FAR more powerful learning – it is contextual, it is about the team and its real challenges.  They can follow guidance as they are working and incorporate it into the way they do things.  The coach can also keep an eye on things that are nearly impossible to observe in the clinic- team dynamics, organizational obstacles, and more – and help any time they find a need.  The team’s game can really improve.  If you have a good coach, the team actually may even get to the point where it is able to improve on its own- perhaps the team members have watched the coach and adopted his/her techniques to observe and question and find improvements.  After a few months of working together, the coach can scale down her/his involvement, perhaps to the point where she/he is called in as needed and to perform periodic check-ins and assessments.

Though this is a far more powerful model, it may not sufficient – for all large/complex/business-critical projects that cost lots of money.  These projects and programs are the “pro” league of the project portfolio, and any opportunity to mitigate risk should be considered.  There may be argument that it is not even sufficient for smaller projects and programs, because much of the value a coach could add happens real-time, as the project is going through its iterations, as challenges arise (unexpectedly).  Depending on how infrequently your teams have help available, they may not be getting the help when they need it most.

The Embedded (the “pro” league of product development?)
Sports teams expected to perform at any professional level follow a different model of coaching – they have coaches and experts that stay around all the time.  The level at which they are expected to perform  makes the cost of great coaches and trainers a good investment.  The risk of not having a coach far outweighs the cost.  How does this compare to your projects?

Do you have a project on which you are spending  millions each year?   That sounds like a risky endeavor, considering project success rates over time (See any popular project success rates research etc).  Having a coach on board or accessible at all times can help your team deal with the infinite number of challenges that it may run in to.   Are you an executive that has “shelved” a multi-year, multi-million dollar project?  This is about you.

The bulk of the coaching value-add is probably not in specific things like Agile practices and techniques, but in other, less concrete things – like dealing with situations that aren’t covered in the books, maintaining focus despite difficult situations, mentoring leaders in the team, facilitating brainstorming, guiding team members in problem analysis, and helping to identify goals for continuous improvement.  If your coach is effective, teams will make measurable improvements every iteration- much more consistently than without one.

Effective coaches are rare, and they don’t come cheap (if you find one that does, start asking around for references ).  But they are a force multiplier, and a massive risk mitigation technique.  The cost of this level of risk mitigation pales in comparison to the benefits  – in continuous team improvement, in mentoring of future leaders, and in the pursuit of organizational agility.

An example…(We have many…)
You may be doing a great job of allowing your teams to follow the guidance they’ve been given and execute Agile very well.  Great job!   Product owner (PO) of project X, one of the highest-budgeted projects in your organization, realizes that a feature set that was originally deemed extremely important has been exposed as a nice-to-have,  or maybe not really necessary at all (a very common situation on well-executed Agile projects).  What should the PO do?

Clearly, the PO should talk to the stakeholders and let them know that we could save $400k on the development of this feature set that we would have otherwise spent.  Is it that clear?  Is YOUR organization ready to handle this situation?  Would the project be deemed a success and the fact that it was ended early be treated as a win, or would the message be that it was ‘canceled’?  What would happen to the project team if they were done early?   Would your organization be able to get this high-performing team a new project that actually has critical importance, or would they be disbanded?  Would your organization be able to re-allocate those funds to the next most critical endeavor?  In many organizations I know of, there are many reasons why a PO in such a position might not choose to terminate the project early (would it be uncertain to the PO what they would move on to?).  These are organizations that have not taken Agile and Lean to the enterprise level.

A coach provides an objective, guiding voice.  Any coach worth his or her salt would help the PO and stakeholders realize the opportunity and the reasons why the opportunity might be tough to take advantage of.  They could then help the right decision to be made, and help the organization improve so that it will be better able to handle this situation in the future – by exposing this “organizational obstacle” to agility and helping the organization resolve it.  If there were a coach in the aforementioned situation, would that have saved the organization $400k in poorly-spent development costs and earned them $___ in benefits from the more important efforts that those funds could be devoted to (which otherwise would be opportunity costs)?

There are many things to consider when you are deciding about hiring a coach.  It’s not all about Agile, training, and practices.  It is about success and risk management, and about prevention of the common phenomenon of less-than-sucessful Agile implementations.

You can view the presentation here