RT @chadholdorf: 1st large scale #openspace today at work. 60+ ppl accepted. Theme is “mastery.” Inspired by http://t.co/y1t0zdkw #agile

RT @RallySoftware: “When dev teams understand the “why” of what they are working on, they make better decisions,” @tolson http://t.co/4X …

RT @RallySoftware: “Just try it” Chris Haley from CBORD Group on Agile Portfolio Management #AgileNewLevel

RT @RallySoftware: RT @aremsan: Managers in charge of performance & leaders in charge of power. Can’t manage to leadership. @geoffreyamo …

RT @jeantabaka: Excellent! Just posted a blog about how little I know. Okay, not EVERYTHING I don’t know just “N” things :) http://is.gd …

“Because stick figures are too complicated” RT @abbotofunreason: Old Skool Webcomic: http://tinyurl.com/4dl4kes

Many of us have heard analogies to help us think about delivering value in the form of real working software at the end of each iteration.  One of my favorites compares value to a slice of cake.  I’m not sure where I first heard the comparison, but here’s the version I like to tell:

Say there’s a baker (delivery team) whose customers come in craving a slice of five layer cake (desired feature) with all its promised yumminess in the chocolate ganache, chocolate mousse, white chocolate, coconut, raspberry, and strawberry filling, but they share with us that they are on a restricted diet (time) and therefore they need our help in being mindful of their calorie intake (what is delivered). 

Which path of the knife will they value more?  The one that slices horizontally and delivers only the first two layers but is 4 inches wide?  Or, the vertical slice that offers all five layers of goodness and is only 2 inches wide?

WARNING!  Any attempt to stand between me and my five layers in a real scenario carries danger of having knife yanked out of hand and applied to throat.

Each layer of cake is likened to a component of system architecture from the front-end software down to the hardware it’s embedded on.  We can think of the filling as the integration points.  In order to say that a feature is really valuable - is really done and potentially shippable - we need it all.

When coaching new agile teams, some will challenge this notion of vertical slices with comments about the complexity of their environment and the impossibility of delivering all layers for every feature in a two-week iteration.  It’s usually then that we have an in depth discussion about the art of splitting (or, “slicing”) user stories. We walk through a few of their real-life examples and “aha” moments typically ensue.

And as the concept is starting to sink in, someone might say,  “But what about design?   I’ve got to think about the database as a whole or performance will be terrible.  The UX designer needs time to gather user feedback before they can answer the team’s questions about the UI.  Somebody has to have the overall architecture in mind - you can’t just piece it together.”   And that’s when we talk about “just enough”, “last responsible moment”, and “real options”, and how the team is in the best position to decide just what those terms mean for their situation.

One day I was searching for a metaphor to prompt thinking about how to tell what’s just enough but not lacking?   I like Dean Leffingwell’s allusion to planes taking off and architectural runway.  And it got me thinking of another mode of transportation:  trains and the tracks they run on.

If the delivery team is likened to a cargo train -  a train that needs to start moving and keep moving if it is to have any hope of reaching its destination in a reasonable amount of time - then we might compare the development environment and infrastructure to the tracks.  Without enough track in place, the train might be stopped or worse, completely derailed.

Let’s say a train starts in Seattle and is destined for Canada.  If we knew almost for certain that our destination was Vancouver B.C. and no track had been laid yet, then we might be tempted to put down all the ties and rails to get us there.   But what if we need to stop into a station or detour onto a siding to load more freight?    What if all the sudden we learned that instead of Vancouver, B.C, the cargo is expected in Vancouver, WA?

Fortunately for us, railroads are now built in sections and with switches that make it less costly to change direction than it was years ago.  In software, some of our most powerful switches consist of automated testing and continuous integration.   

For maximum agility — flexibility, adaptability — and minimum cost of rework, we would be laying track down just a few ties at a time, putting ourselves practically under the train while it’s moving.   Now some you might be thinking, “Sounds dangerous!” However, the idea is to think critically about just how close you CAN get.  

In a place where the delivery team has all the access they need to make necessary database changes to implement a desired feature, the distance equates to keeping time with the train.  On the other hand, for teams that need to submit database change requests eight weeks in advance to an external operations department, they look just far enough (perhaps 8-10 weeks) ahead in their product backlog and start preparing the ground to lay the needed track.  Obviously, the first case gives us maximum agility and more real options.  There’s less agility in looking ahead 8-10 weeks…but it’s still a whole lot more than trying to anticipate needs 6-12 months in advance.

For a closer look at this agile mindset, read how Katrina Lindholm described her approach to UX design at Rally Software.  

What do you think of this concept?  Have you seen it applied to hardware and embedded systems, as well as to software?

RT @bencarey: http://thefuntheory.com … um… amazing.

In 2001, an experienced group of software professionals were looking for a word to describe the values and principles that they had come to recognize as foundational to building better software. It was a toss-up between ‘agile’ and ‘adaptive’, in the dictionary-sense of the words. Of course we all know which word won; the group‘s position was outlined in the Agile Manifesto.

In the nearly 10 years since the original declaration, hundreds of books have been written to describe Agile practices and patterns in more detail. Today, however, many still debate what “agile” really means. Sometimes it feels like a game of Telephone, where simply going back to the source is all that‘s needed to clear up a misunderstanding or misinterpretation. In my work as an Agile Coach, I also see confusion when individuals, teams, or organizations equate “doing agile” with “being agile.”

Doing agile might mean adopting certain practices from Scrum like meeting daily to discuss progress or expressing requested features in the form of user stories on a prioritized backlog; or practices from eXtreme Programming like pairing to write code. A team can do all these things and not be agile; likewise, a team could be agile and do none of these things.

I like how my colleague Ken Clyne describes some of the key characteristics seen in high performance delivery teams and organizations. To help teams learn what it means to be agile, we coach them to:

•  Focus on customer value. For every bit of work we undertake, understand “whom are we building this for?” and, “why are building this?”  Then prioritize our work to deliver the highest value first.
• Deliver early and often to give ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that help us improve.
• Continuously inspect and adapt. Establish a rhythm of taking small, incremental steps towards improvement until we are perfect…in other words, forever.
• Create a collaborative culture with self-organizing teams to foster innovation and a shared commitment.
• Reduce batch size. With large batch sizes, we tend to deliver late and infrequently. It‘s worth the fight to work on smaller and fewer pieces of value at a time.
• Pull quality forward. If we don‘t complete our work as we iterate with testing and integration, then we are creating technical debt that will affect our ability to release.

Don‘t get me wrong. As agile coaches, we also teach teams how to “do agile” and we might recommend specific practices based on what we‘ve seen work well in other organizations. However, context is critical. When in doubt about whether a particular practice is right for a given team, we ask the team first. What would they like to do? Could they try a time-boxed experiment — understanding that they‘ll stop to inspect outcomes and adapt accordingly? It‘s what a truly agile team would do.

As I was writing on the plane, the young man sitting next to me asked what I was working on. So just for fun, I asked, “What does ‘being agile‘ mean to you?”  Jon replied,

“Hmm…a person who is agile is quick on their feet, fast to react; nimble. It‘s a characteristic and a lifestyle; it might be seen in what they do physically or how they approach a situation. Being agile goes hand in hand with flexibility and adaptability.”

I told Jon that he practically just wrote this article, and if he ever retires from the US Air Force, he should consider becoming an agile coach.

—

* While the Agile movement may have begun focused on software development, over the years many have found success applying Agile and Lean principles to all types of product delivery and business operations.

[Post originally published in an IIBA Newsletter, October 2010]