Register for the Last 2008 SSA Course-Nov 13,2008!

I’ll be delivering only one more public course of Scaling Software Agility: Best Practices for Large Enterprises yet this year. It will be held at Agile University in Boulder, Colorado November 13, 2008. You can see the abstract and register for the course here. While the course is based on the book, the material is constantly updated based on my ongoing experiences helping some of the world’s larger software companies transform themselves to become an agile enterprise.

In addition to the delivered content, the small group setting provides an opportunity for informal discussions of some of the real world challenges that attendees face. And since most attendees face significant challenges of agile adoption at scale, the shared learning environment facilitates experience sharing and practical problem solving in the enterprise context.

Hope to see you there.

–Dean

Enterprise Agility- The Big Picture (13): Portfolio Vision & Epic

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing posts, too numerous to highlight here (see the Big Picture Category on this blog for an orderly summary)we have been gradually working our way from the bottom (stories, iterations and the like) towards the top from where the enterprise vision originates. In this post, we’ll briefly discuss the Epics that drive so much of the behavior of the agile teams at Level 1 and 2.

Epics, Features and Stories

In an earlier post, we took the liberty of putting labels on the different types of system behaviors (stories, features, epics) that drive our hierarchical, Big Picture model.

Agile Enterprise Big Picture 13- Epics

I also took care to note that there is no “UML for describing agile things” so I’ve simply tried to apply usage models that appear to be fairly common, providing us with at least a tentative language to describe what we are trying to describe. In so doing, I picked the word “Feature” to represent things much bigger than a User Story as this is mostly consistent with other agile uses of the term including Feature-Driven Development and the organization of delivery models based on the agile feature teams construct. It is also consistent with the language we used to describe such system services in earlier software requirements texts, including my own – “a feature is a service provided by the system that fulfills a user need”- (Managing Software Requirements: A Use-Case Approach, Addison-Wesley, 2003).

Sizing of Features and Stories

When it comes to sizing, we sized User Stories arbitrarily so as to fit in an iteration (leaving no dangling participles of work at the end of the iteration). This is standard agile practice and is a point of agreement in the various methods. For the Feature, we simply expanded the paradigm to this larger service class and again forced Features to be sized arbitrarily to fit inside an Internal or External Release boundary. This helps assure that teams focus on larger-scale value delivery while again, not leaving the user hanging with an incomplete, non-holistic chunk of functionality. In addition, this forces Product Owners and Product Managers into the same incremental thinking (what’s the simplest thing that can possibly work for the user to fulfill that need, and how soon can we deliver it….?) that agile teams use (with XP being the most extreme case of incremental-ism). Indeed this one-piece-of-user-value-at-a-time is the most basic construct of agility at the team level and we build on it continuously to create the agile enterprise.

Epics – Managing Relative Investment

As we reach the top of the pyramid, however, and discuss the highest class of user benefit, the Epic, there is no need to force arbitrary sizing as these are portfolio vision items that take multiple releases to deliver. Indeed, some epics take years to deliver, even in agile enterprises. For example, the Epics such as “video streaming” and “integrated on-line music stores” will likely consume hundreds of person years for mobile phone manufacturers and will be delivered in stages over a number of years.

The question that arises is “given their large scope and size, even if prioritized how would we know when we will deliver what”? The answer has to come from the Portfolio Management function (represented by the Portfolio icon on the left). There the decisions are made on a relative investment basis based on the business case for the Epic. In other words, enterprises decide what percentage of the total resources they want to invest in an Epic to achieve the ROI of the business case. Given that data, teams can decide at Release Planning time, (where they divide the Epic into Features that deliver user value) what percentage of their resources they can assign to the Epic. With resources as a given, the highest priority Features for the Epic are delivered first, gated only by the resources available. Then Release by Release, the Epic makes its way to market in Feature-size chunks, with reprioritization occurring at every Release Planning boundary.

Summary

In this Epic post (sorryJ), we’ve introduced the Epic container as the vehicle to describe the major initiatives that we need to deliver to the market. In so doing however, we’ve left at least one stone unturned, which is how Epics can be sized and estimated (assuming that they can be). We’ll discuss that in the next post.

In addition, we’ve opened another Pandora’s box at the top of the Big Picture, which is “what the heck is Agile Portfolio Management” and how does an enterprise achieve that?” So fortunately or unfortunately, the Big Picture series will continue a little while into the future, with a few upcoming posts on Agile Portfolio Management.

Join Me at Voices that Matter: Crafting Software Conference

Along with Kent Beck, Stacia Broderick and many others, I’ll be speaking at the Voices that Matter: Crafting Software Conference to be held in San Francisco, December 1-4, 2008 in San Francisco.

Her’es the description from the website:

“The Pearson Education Voices That Matter Conference series gives voice to the most important thought leaders in technology, design, and business today. These conferences give our readers access to those who have devised new technologies, new approaches and new inventions. Our speakers are the individuals who have made the strongest contributions impacting their industry. They are highly visible practitioners and luminaries who lead the way, spawn new technologies and inspire passionate communities.”

If you register via clicking the picture above and use the Priority Code CSNPKRA, you’ll receive a special discount with your registration.

Hope to see you there.

–Dean

Jeff Sutherland’s Sprint Emergency Landing Procedure

Last week, I gave a talk on Scaling Agility at Agilis 2008 in Reykjavik, Iceland. Yes, Iceland has an active agile community within their population of some 300,000-400,000. A local consultancy Sprettur, hosted this conference and invited guest speakers including Jeff Sutherland and myself. I was somewhat surprised to see the advanced level of agile adoption in this community and I had the opportunity to meet a number of agile masters who were in the process of implementing and expanding agile and Scrum.

Jeff gave two separate talks on Scrum which I enjoyed immensely. It was a learning experience for me to be able to benefit from the depth and breadth of understanding that this co-inventor of Scrum possesses. In one talk entitled “Your money for nothing and your change for free” he mentioned, almost in passing, that as a former fighter pilot, one always had to know the emergency landing procedures that came into play while attempting to land a jet on an aircraft carrier. He used that analogy to remind teams that they needed instant recall of their Sprint Emergency Landing Procedure of they ever saw this shape to their burn down chart:

Sprint in trouble

When this is the case, the teams should immediately fall back on its four-step emergency procedure:

1. Innovate/remove impediments – quickly analyze the root cause of the problem (blocked story, resources diverted to emergency, or whatever) and see what ideas the team has to correct the problem. As always, the collective minds of the team are the first and best resource.
2. Get Help – can help be found outside the team? If so, apply these resources to accelerate the burn down.
3. Reduce scope – cut lower priority features and re-plan based upon what the team can accomplish. While the team might not be able to deliver all the stories, it may not be too late to fulfill the objectives of the sprint and still end up in an acceptable state at the end.
4. Abort – if the deck is still pitching and the glide path is still too high, then lastly, it may be necessary to abort the sprint and simply start over. Not every sprint can be a winner (unless the team is too risk averse) so the learnings and completed stories can launch you into a new, more realistic sprint. This is the last resort, but it could still be better than an unfortunate landing.

The Agile Enterprise Acid Test – Updated

In a prior post, I referred to a post by Paul Beavers of BMC (Is it Possible to be Half-Agile?) which gave his perspective on the agile acid test- the quintessential test of whether or not an organization is truly achieving agility at enterprise scale. In my post, I also provided my viewpoint on the subject. Recently, I tested that viewpoint with a few others. As a result, I’ve modified my version a bit as you see in the graphic below:

Agile Enterprise Acid Test

As amended, the three elements of my version of the Agile Enterprise Acid Test are now:

Variable scope. Fixed quality.

• Can the teams vary scope? – Does the team have the authority to vary scope even as the release deadline draws closer?
• Is quality acceptable and fixed? – You can’t go fast building on crappy code. Agile accomplishes little without the requisite code quality which must be built into the process through TTD, continuous integration, test automation, coding standards and the like. If you see your teams iterating or sprinting with a primary objective of working down code-level defects, then you are not truly agile.

Incremental Value Delivery

• Is software delivered incrementally? – If your teams are sprinting but there is no feedback until the final delivery (one form of “waterscrumming”) then you are not achieving agility as there is no meaningful feedback to drive the solution to an acceptable outcome
• Is it valued and evaluated? – Demos are great, but you need real value delivery to assure fitness for intended use and early and continuous ROI. If the incremental code is not being actually used, you are not very likely to get the results you seek.
• Is feedback continuous? – In addition to customer feedback, product owners, product managers and other stakeholders have a responsibility to continually assess the current result. This is achieved through story-level acceptance and iteration-level demos.

Empowerment and Accountability

• Are the teams empowered? – Are the teams truly empowered and able to modify and improve their own software processes? Do they self organize and self-manage? Are resources routinely moved to the most critical bottlenecks?
• Are they accountable for results? Empowerment and accountability are two sides of the same agile coin. Are the teams delivering reliable quality code in incremental fashion? Do you they commit to iteration and release objectives, subject to responsible scope management?
• Do they regularly reflect and adapt? – Do the teams adhere to Agile Manifesto Principle #12? – At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
• Does management eliminate impediments? – is management also engaged in continuous improvement? Are impediments routinely surfaced, addressed and eliminated.

That’s my current definition.

–Dean

Note: Readers may also want to note Jon Strickler’s view on this definition, perhaps from a somehwat “leaner” perspective, in the comments on this post below.

New Book: The Software Project Manager’s Bridge to Agility

I just finished reading this recently published book by Michele Sliger and Stacia Broderick (both of whom I’ve had the pleasure of working with in the field). This book fills a critical agile enterprise gap – that is how to transition from traditional project management to agile project management. Michele and Stacia, two long-time (neither will say how long….), certified project management professionals, describe how project managers can successfully transition to agile by “refocusing on facilitation and collaboration rather than command and control”.

For those with traditional project management training, Chapter 2 provides a framework for mapping the PMBOK (the Project Management Institutes Guide- Project Manager’s Body Of Knowledge) to agile techniques. The book is a unique perspective from two project management professionals who have been-there-and-done that and are now dedicated, over-the-top agilists (I mean that as a compliment). If you ever find yourself using any four or more of the following things – PMI, XP, PMBOK, Gantt, WBS, Scrum, PMP, PMO – in a single sentence, this is the book for you!

Balancing Traditional and Agile Belief Systems- Israel Gat on the Equipoise of Agile

Recently I’ve again been pondering the balancing act of implementing new agile practices alongside extremely well entrenched, existing enterprise practices. While it’s always fun to criticize our past behaviors from the perspective of the rear view mirror, it’s also the fact that most of these prior practices actually worked dang pretty well pre-agile. After all, as most every software enterprise is by definition, successful prior to agile (or they wouldn’t have gotten as big as they have!), a healthy respect for what-it-is-that-got-us-here is an element of agile wisdom. And yet, if we don’t address many of these legacy practices and mindsets, we will not receive the full benefit of the new model.

So we are constantly faced with the dilemma of “how much to change” and “how fast to try to change it.” Too much and we risk the entire initiative as the organizations antibodies set in; too little and the benefits will be mitigated.

In thinking about a current project, I remembered that Israel Gat, BMC VP, discussed just this issue in a post entitled the Equipoise of Agile. It is located at the Agile Thinkers Blog, but it isn’t a stand-alone post so you’ll need to scroll down a way to find it. Here’s the intro:

Equipoise is the equilibrium formed by offsetting conflicting forces. The equipoise of Agile is the skill of an Agile leader to orchestrate conflicting forces and pressures in and around Agile in a manner that utilizes Agile principles, without denying the realities of the non-Agile world. It is the ability to function and get teams to function amid contrast and ambivalence that are systemic. – Israel Gat

It bends your mind a little bit to be able to intentionally operate with conflicting belief systems, at least for a transformation period, but I’m convinced that is the right mind set with which to approach the enterprise transformation. Patience helps too.