From the Agile Transformation Trenches

What Good Are Pigs And Chickens?

Recently I received an email commenting on David Anderson's "Where Everyone's a Pig" article.  The author agreed to let me share part of their message along with my reply.  They said, in part:

To a significant amount Scrum is intended to put a protective shell around a group of persons to ensure that the vulnerable process of self organization is not disrupted from outside forces. The metaphor of chickens and pigs is intended to underline that notion. I don’t see chickens and pigs as opponents at all.

To which I replied:

As with many agile practices, the pig/chicken distinction must be adapted to fit the organizational context and maturity of the team.  In early stages of agile adoption this "protective shell", as you call it, is a defense mechanism intended to help the team counteract the larger organization's resistance to, or even hostility toward, agility.  This is often based on fear and misunderstanding, but it can still be a real threat.

David's point is that a mature agile organization does not have that problem.  He suggests that one way to remove the opposition to agile methods is to include the rest of the organization in your agile process.  Viewing participants as pigs/chickens maintains an us/them attitude and therefore can undermine full organization-wide collaboration.  Although it may be useful to provide some degree of safety to new agile teams, the need to "keep management at arm's length" is a symptom of a larger organizational dysfunction.

Ultimately, if anyone, inside the team or outside the team, is an impediment to timely delivery of value to the customer, we need to ask why they are doing that and what goal (presumably more important to them) is being served by their actions.  Problem-solving based on whole-system thinking is not served by the pig/chicken distinction.

What do you think?  Is there value in the pig/chicken metaphor?  Does it encourage dysfunction?

He's got a roadmap of Jupiter, a radar fix on the stars

One of my teams recently went through a session to develop a product roadmap, using a technique based on the teachings of Luke Hohmann in his book Beyond Software Architecture. A roadmap is the oft-forgotten second level of agile planning—vision being the first, and release planning, iteration planning, and the daily plan being the other three (and comprising the bulk of agile texts). The roadmapping process got high marks from everyone involved, and at many times it was great fun!

We’d allocated two days for the exercise and invited an even wider group of aspects than usually participate in our scrums: development, QA, documentation, product management, sales, usability, marketing... you get the idea. Numbering almost half the crowd, the engineers were by far the largest contingent. Most of the broader dev team is new to agile and had never experienced a roadmap session, and frankly were rather skeptical. They saw this activity as largely a Product Management (PM) function and were expecting to be bored at best, with two days wasted at worse. Instead, they found themselves engaged and active participants, helping to plan not only the individual features but the aggregate product itself.

Like many agile practices, the benefits of roadmapping were not predictably obvious. What looked to dev like a gathering where they were going to sit at the back of the room and text their friends while the PMs and marketing folks argued turned out to be quite interactive; even those folks that didn't speak up during the two days commented afterward how illuminating it was to "see how the sausage was made". Before the session, the engineers were not looking forward to the meetings; afterward, they are asking when the next one will be!

Post title is a lyric from Dreamline by Rush.

Putting People First in the Transformation

Hi! I am Stephen R. Palmer, a principal consultant at Borland (the middle initial helps separate me from the multitude of other Stephen Palmers on Google and Yahoo, etc.). My work at Borland revolves around two main themes, model-driven software development and agile process coaching. My interest in these areas really started when I worked as the development lead on a major project in Singapore in the late 1990’s.The project was the first to use Jeff De Luca’s Feature-Driven Development (FDD) model-centric agile process and Peter Coad’s ‘modeling in color’object modeling technique. In addition to the privilege of working closely with Jeff and Peter, the project team also included other agile practitioners like Paul Szego and David Anderson.

More recently, I have written a book about FDD, worked with enterprises developing model-driven service-oriented architectures, and coached teams adopting agile processes based on Scrum (I am a Certified Scrum Practitioner) and Smart Agile.

One team I coached this year was a large defense client. The client was keen to see if an agile approach could improve their productivity and give management a better handle on the status and progress of projects.

The agile manifesto states that it values “Individuals and interactions over processes and tools”. It puts people and the ways they work together at the center of things. Processes and tools support these collaborations. For organizations undergoing an agile transformation, this ‘people first’ idea is proving useful in introducing and establishing agile practices.

In nearly twenty years of working as a developer or consultant, one thing I have learned is that simply deploying a software product or mandating a particular process rarely produce the desired transformation in the way people work. It is all too easy for people to continue applying the same thought processes and working practices while using the terminology of the new tool and process. ‘Play it again, Sam! … but this time call it something different.’

This is not something particular to agile approaches. I have seen the same thing happen when introducing UML modeling tools as a replacement for generic diagramming tools, requirements management tools for monolithic requirements documents, and configuration management tools for basic version control of source code. A shift in paradigm needs more than a switch in technology. Those old enough to remember the switch from structured programming languages like Pascal and C to object-oriented programming languages like C++, Java and C# will remember that for a long time, developers simply used these new languages in much the same way has they had the old ones. What we needed to realize the benefits of these new languages was a change in the way developers thought. The programming languages supported this new way of thinking but they could not cause the change. The same is true of the shift from traditional software development management to agile approaches.

For my defense client, the ‘people first’ principle has worked well. We decided to concentrate initially on establishing the values, principles, and practices of a Scrum-based approach within the team, postponing any discussion about the use of software tools to manage the project in which they would be piloting the agile approach. Instead, we started with index-cards and a large corkboard.

The idea was for individuals to get a feel for the new ways of working without having to worry about operating a particular software product. With this approach,the team was able to concentrate on establishing the new ways of communicating and interacting, instead of learning the idiosyncrasies of a particular user interface.

Once the team had two or three iterations (sprints) under their belt we started to discuss how software tools might help improve management of the project. For example, one member of the team was having difficulty because he worked from home - in another country - part of the time. He had to attend standup meetings by phone, call or e-mail his daily updates for the corkboard to the scrum master, and so on. Another problem this team had was the growing size of the backlog. The product owner was struggling to manage the stories coming in from multiple different sources. Because we had established the new way of thinking, the selection of tooling focuses on addressing real problems experienced by the team.

From a vendor’s perspective, it might seem counter-intuitive not to push your product hard from the start but it actually makes considerable sense. It is all too easy and common to blame software tools for frustration caused by lack of understanding, bad communication, and poor process definition. Agile transformation programs are no different. As a vendor looking to establish a lasting relationship with a client, you do not want to see a process-improvement program struggle or fail. You certainly do not want your products cast wrongly as one of the causes of that struggling or failure. And yet, ‘Play it again, Sam!... but this time call it something different,’ is likely to happen if a tool is viewed as the key to transforming traditionally managed teams into agile teams.

It is not a coincidence, therefore, that all consultants in Borland UK are Certified Scrum Masters or Practitioners. We have recognized that for us to be successful we cannot simply throw our products at people and expect them to transform the ways they work. We have to help change the way people think if they are to realize the larger benefits from using our products.

Agile Development Practices conference take-aways

I've just returned from the superb Agile Development Practices conference in Orlando, Florida.  One of the most inspiring sessions I experienced was Brian Marick's opening keynote.   It set a pretty high bar for the rest of the conference.  I'll try to give you my impressions and take-aways from Brian's talk, but I would strongly encourage you to read the original, which Brian has posted on his blog.

Looking back on the movement christened by the publication of the Agile Manifesto, Brian shared with us his perspective on how that mission statement should be enhanced and extended.  Brian focused on agile values as a way to resist the temptation to chase short-term gains at the expense of long-term benefit.  The eight values he discussed were:

• Courage
• Working Software
• Ease
• Reactive Behavior
• Fast Feedback
• Naiveté
• Visibility
• Joy

Courage is needed to overcome the many kinds of Fear that can distract us from our goal.  It allows us to question the rules, and break or change them when appropriate.  Working Software is our goal.  This means software that fulfills the needs of the people who use the software.  This implies both quality and fitness for purpose.  Brian emphasized that small increments of this goal should be produced very frequently, citing Kent Beck's advice to have no more than 15 minutes of discussion before someone makes the ideas concrete by writing code.  In all the work we do, we must strive for Ease.  Taken in an appropriate context of long-term value, this means making many small investments along the way so that our work becomes more streamlined rather than bogging down under the drag caused by allowing barnacles to accumulate.  Ultimately, this allows us to avoid Yak Shaving, but you'll have to see Brian's transcript for more on that.

A pervasive thread through the presentation was the idea of keeping software Soft.  This was especially emphasized by valuing Reactive (rather than the traditionally valued Proactive) Behavior.  This does not mean that we don't have a plan, but that we retain the Softness required to bend our plans while constantly moving forward.  Fast Feedback helps us become aware of important information that we should integrate into our plans as we react to what we learn.  The faster the feedback, the better we will do at staying on target, so we should strive for feedback on the order of minutes, such as that provided by Test Driven Development and Pair Programming. 

The value of Naiveté really amounts to what Eastern martial artists refer to as Beginner's Mind.  This is the transcendence of what we "know" about what is possible, so that we are open to succeeding with the seemingly impossible.  Visibility is the art of simply exposing the problem and letting our human nature generate a solution.  In this way we find that people can be soft like software.  When the consequences of our choices are visible, we become motivated to change, where we would have resisted exactly the same change if it was imposed on us.  Taken together, these values lead to a sense of Joy.  As David Anderson said in his closing keynote, we can create a place where we want to work, rather than have to work.  From a motivational perspective, this kind of environment captures Discretionary Effort, which is the hallmark of high performance.

At the end of his talk, Brian invited a panel of agilists to offer their thoughts and values.  This list included:

• Simplicity (J.B. Rainsberger)
• Integrity (Linda Rising)
• Questioning (Rachel Davies)
• Angst & Purpose (Jeff Patton)
• Experience (David Hussman)
• Community (Anthony Marcano)

J.B. began with a story about Simplicity that encouraged us to ask ourselves what it would take to start making money sooner.  Linda followed with admonitions to avoid Delusion—a lacking of Visibility, Courage and Ease that leads us to overlook challenging, yet often obvious, opportunities for improvement.  I interpret this as the value of Integrity—doing what we know is right even when it's not easy in the short term.  Rachel asked us to have the Courage to say "No" to taking on too much work, illustrating the value of Questioning. 

Jeff contributed the value of Angst—the motivating sensitivity to things that could be better, and the value of Purpose—to make sure we all understand the strategic vision that guides our tactical decisions.  David offered potential manifesto additions like "Success over Dogma" and "Description over Prescription", ultimately focusing on the value of Experience communicated through sharing our stories.  This really resonated with me as there always seems to be some nuanced understanding to be gained through listening to the struggles and triumphs of others.

Anthony concluded with the value of Community—a kind a Family Spirit that keeps us looking out for each others' best interests.  For me, this relates to the value of Collaboration, which is mentioned in the original manifesto, and seems central to the culture change required for successful agile adoption.  Focusing on Collaboration means replacing win-lose relationships with win-win relationships.  In asking how we all can benefit, we find the path to sustainable success.

What values do you think should be added, removed, clarified or modified?

[Special thanks to Joey McAllister of SQE for allowing me to review the tape of Brian's session and capture the comments of the panelists]

A Good Place to Start

As an Agile Evangelist for Borland, and an officer of Agile Austin, I am often asked for good references on getting started with agile.  This usually goes beyond what can be found by applying your Google-skills, although that's a good way to get a taste of agile thinking.  The best way, of course, is to learn agility from experienced practitioners.  There is nothing more effective than hands-on mentoring.  However, this question is usually asked in a context where direct full-time exposure is not available.  In this case I recommend another old-fashioned technique—reading books.  This narrows my challenge to identifying which books, from the dozens on my bookshelf, to recommend.  Many are excellent treatments of particular aspects of agility.  Some are particularly relevant to specific circumstances.  Over time some newer titles rise above their predecessors.  There are a few that I find myself recommending more frequently as striking an especially good balance between breadth of coverage and depth of details.  I include four such examples below.  Each addresses a somewhat different, although not necessarily distinct, audience.  I leave it to you to self-select which may be right for you.

Agile & Iterative Development (A Manager's Guide) by Craig Larman provides an excellent survey of agile methods and practices.  It is organized for easy self-directed exploration, with extensive margin references to sections that expand on topics mentioned.  It includes an excellent section on the historical foundations of our current software development practices that leads to building a solid business case for agile methods.  About half of the text is devoted to comparative case-studies of Scrum, Extreme Programming, Unified Process and Evo.  This provides a fairly objective overview of each process.  The book concludes with agile practice tips and frequently asked questions (with answers) common to the whole family of agile and iterative development methods.

Implementing Lean Software Development (From Concept to Cash) by Mary and Tom Poppendieck takes a principle-based approach.  The seven principles of Lean Software Development are; Eliminate Waste, Build Quality In, Create Knowledge, Defer Commitment, Deliver Fast, Respect People and Optimize the Whole.  Each of these principles is discussed in detail.  The theoretical foundations are supplemented by real-world examples, case studies and experience reports.  Each section ends with a list of concrete exercises called "Try This", which invites you to put your knowledge into practice.  This book is an excellent way for agile leaders focus on the most significant factors for success.

The Art of Agile Development by James Shore and Shane Warden is an excellent guide for the agile practitioner.  It consolidates years of experience with agile practices based primarily on Extreme Programming (XP), which has long been considered a good set of engineering practices to compliment the management practices of Scrum.  The specific practices are well organized, clearly explained, extensively cross-references and presenting in an appealing "pattern language" format.  The "Getting Started" section provides a solid foundation for understanding agile mechanics and even deciding if it is right for your situation.  The "Mastering Agility" section gives a good description of the values and principles that make agile work.  This makes a good concluding section because it provides a good roadmap for developing more agile maturity once you've had some success applying the specific practices.

Agile Software Development (The Cooperative Game) 2nd Edition by Alistair Cockburn is a tour de force describing the working principles of agility.  Interviews and analysis of dozens of agile projects is distilled into a series of powerful observations and recommendations.  This is the book you need to guide the tailoring of agile methods to your particular environment and circumstances.  Many  inexperienced teams lose much of the value of their agile methods by adapting them in inappropriate ways before they understand the subtle interactions between various agile practices.  This book helps you to stay in the "safe zone" or the "sweet spot" when you are starting out, and to get the more effectiveness from your ongoing process improvements as you gain more experience and maturity.

These references should give you a good place to start.  Then you'll have to put what you've read into practice.  That's where I've found that the real learning begins.