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?

Out for summer, out 'til fall; We might not go back at all

Photo by sunchild_dd Watching my kids rejoice in their summer vacation I'm struck by the irony of our situations: as children we all disliked school; as adults we crave new learning opportunities. In the workforce, this usually means either conventions or training classes, but not always. Books remain a low-cost (and my favorite!) way of obtaining information, especially when coupled with a discussion group. Blogs, listservs, and podcasts are all excellent methods of finding new viewpoints and new voices in the community. A more social way of getting exposed to new ideas is to join a local organization such as a user group or technology incubator. Attending a BarCamp gathering is another great community learning opportunity. After all, meeting new people can be just as rewarding as understanding a new concept!

While my boys are excited they don't have any more homework for a few months, I look forward to my next opportunity to learn. What do you do to acquire new knowledge?

Post title is a lyric from Schools Out by Alice Cooper.

Agile is Fragile

I recently had the pleasure of seeing David Douglas and Raj Vaidyanathan presenting "Integrating into the whole...embedding agile processes into all aspects of S1's business model" at Agile Austin.  During that presentation, David was lamenting the fact that agile is fragile.  He related several experiences where, despite visible indicators of success, agile adoptions had ultimately failed to be sustainable.  This lack-of-sustainability pattern is certainly a familiar one, and we should look hard to find root causes so we can address them.

I think the lack of sustainable agility can be traced—in large part—to a loss of trust.  "The first thing to build is TRUST!", as Brad Appleton says.  Trust is critical to the proper functioning of an agile organization.  Where there is less trust, we see more dysfunction.  On the surface it can appear that everything is going well.  We all have a lot of real-world experience with putting on a façade of trust.  Ultimately the actions of the team will reveal how much, or how little, trust actually exists.

Trust is slow to build, and quick to destroy.  Since trust is a foundational element of agility, the fragile nature of trust makes agile fragile.  However, there is hope here as well.  Trust relationships exhibit a plateau behavior.  Once established, they achieve a degree of stability that allows trust to survive sort-term attacks.  A slow erosion of trust, or a catastrophic trust-breaking event, will still lead to dysfunction.  If you are feeling a loss of agility, it may be a good time to check on the level of trust in your organization.

Agile Scope: A picture and a few words

A couple of weeks ago, I was peer reviewing some work by a colleague. I was struggling to communicate what was and what was not covered by the popular agile processes  - what I call the scope of the process. For example, Scrum and eXtreme Programming essentially focus on a single small, cross-functional, development team. At a fundamental level, they do not cover larger teams or projects or organizations consisting of many small dependent teams. They say little about how customers or product owners decide on the business value and priority of the user stories or backlog items they create. Neither do they say much about working with a formal testing organization.

While there are plenty of suggestions and some popular approaches to extending Scrum and eXtreme Programming to cover multiple dependent teams, they are just that; extensions to the original core set of rules or practices. 

Anyway rather than try and explain this by waving my hands around I resorted to drawing a picture to communicate what was in my head. Although very simplistic, it seemed to help so I thought I'd share it. If I have done it correctly, you should be able to click on the image below to see it full-size (legibly in other words) in a separate, pop-up window.

The circles represent perpetual activities all running concurrently taking input off lists (or queues, backlogs, or whatever) and generating results on subsequent lists/queues/backlogs.

The green dashed box represents the scope of Scrum/XP and supporting tools like Borland TeamFocus today; sets of small independent teams working from their own backlogs.

The red dashed line represents the space where more and more organizations that have been using agile successfully for a while seem to be focusing. In these organizations individual development teams are working well. The result is that inefficiencies in working practices around the individual teams are starting to show up. This enlarged scope is closer to that covered by an approach like Feature-Driven Development (FDD) with broader demand management aspects informing the individual team product backlogs and collaboration across teams around an overall domain and technical architecture where appropriate. It is the space I see the combination of tools like Borland Team Demand and Team Focus being applicable, for example. Of course, we can't forget Borland Togetherfor recording and communicating the overall architecture as it emerges from collaborative design sessions.

Outside of the red dashed line are the activities that trigger new projects or changes to existing systems, and my colleague's interesting contention that this should all be inspired from a business process improvement perspective. He asserts that all IT development work should be about improving one or more steps in a process somewhere and if we understand our processes or our customer's business processes well enough we can use that knowledge to identify and prioritize development work. For example, Borland as a software tools vendor needs to understand the end-to-end processes involved with developing and delivering software. Identifying pain points, bottlenecks, opportunities for increased efficiency, etc,  in those processes enables us to deliver genuinely useful and easy-to-use products.

What the picture does not show explicitly is the current interest in more sophisticated agile testing with tools like the Borland Silk suite. The idea is included implicitly in the Design, Build and VERIFY activities.

Also not shown are the measurement and analytic aspects that I view as another dimension to the picture entirely.

All suggestions for a better picture would be gratefully received.

Agile and Object Modeling? Surely Not!

I have been told unofficially that my submission for a session on managing large product backlogs at Agile 2009 has not been accepted.  That is a bit of a shame. The topic seems to resonate with many teams that have been successfully doing Agile for a number of years.

However, I am not too downcast because I have also heard a rumor that two sessions on ‘modeling in color’ (or ‘modelling in colour’ as we call it in the UK) have been accepted. Given the choice, I probably would have chosen a ‘modeling in color’ session over a backlog management session too. Much more fun. In fact, I may end up co-presenting one of them if David Anderson gets his way.

For those that have not met it before, ‘modeling in color’ is an object modeling technique developed by Peter Coad in the late 1990’s. It involves categorizing classes representing problem domain concepts into one of four ‘archetypes’ and employing proven patterns of these class archetypes to rapidly construct object models of the problem domain.

Talking about object modeling in an Agile context is often contentious. For many Agilists it conjures up memories of elitist analyst/designers wasting months creating incomprehensible diagrams in purpose-built modeling tools and then throwing the so-called models and next-to-useless generated skeleton source code over the wall to developers who generally ignored it – the antithesis of Agile in many peoples’ eyes.

Although, ‘modeling in color’ models can be constructed in UML modeling tools like Borland Together, the favorite ‘modeling in color’ tool is a packet of four-colored sticky notes, and the recommended means of constructing a ‘modeling in color’ model is in cross-functional, collaborative sessions.

Before I get into too much trouble with the Borland Together team, I must point out that Borland Togetheris my 'very favoritest' software tool for object modeling and one of the main reasons I joined Borland. I especially love its LiveSource technology that I believe makes it one of the best modeling tools on the market for Agile teams.

If you cannot wait until Agile 2009 to find out more about modeling in color there are some old introductory notes written by yours truly hanging around odd places on the net such as:

• Object Modelling in Colour
• A New Beginning
• Accelerated Analysis

There is also a book by Peter Coad on the subject, Java Modeling in Color with UML. Don’t be put off by the title. There is very little about Java in the book and only a very small subset of UML is used. However, the writing style is a little unusual so worth flicking through chapter one available here to see if you like it before spending hard-earned cash on it.

Borland Agile Assessment 2009

Recently at Borland, we participated in a second-annual self-assessment of our agility.   The survey itself was internally developed, inspired by the Nokia Test (which sets a nice minimum bar),  and cross-referenced with the Agile Manifesto, as well as summaries of agile principles from Alister Cockburn, James Shore, Scott Ambler, and Tom & Mary Poppendieck.  It consists of 12 questions answered (anonymously) on a 5-point agree/disagree scale.  The results create a diagnostic profile that can be very helpful in identifying areas to focus on for agile improvements.  Here is the assessment survey itself:

Please answer the following Agile Assessment questions based on the rating scale below:

1 = Strongly Disagree
2 = Disagree
3 = Neutral
4 = Agree
5 = Strongly Agree

1. We deliver valuable software early and often (on the order of weeks rather than months) in order to satisfy our customers.
2. We welcome changing requirements that represent our improving understanding of customer needs.
3. We measure progress in business-valued terms such as time-to-value, cost/benefit ratio and customer satisfaction.
4. Stakeholders and team members work in close collaboration (on a daily basis).
5. We work in an environment of trust and respect, where individuals organize themselves the best way they know how to accomplish the organization’s goals.
6. Our leadership supports, rather than directs, our work (as demonstrated by our immediate supervisors)
7. We encourage collaboration rather than competition (focus on what to improve, not whom to blame).
8. We use the most effective means of communication available to coordinate our efforts (usually face-to-face).
9. We can sustain our development pace for an indefinite period of time without loss of quality.
10. We invest in technical excellence and good design to keep the cost of future development low.
11. We automate repetitive work (e.g.: regression tests) to eliminate human error and speed delivery.
12. On a regular basis we reflect on ways to improve, expecting that improvement is always possible as learning increases.

Instructions to the assessment participants included these statements:

There is no "score" to this assessment.  It is administered anonymously with results reported in aggregate.  This is a diagnostic tool to help us all reflect on our processes and identify ways to improve.  It cannot measure "improvement" from a previous assessment, only relative importance of potential improvements to our current situation.  
 
As such, we ask that you answer in the context of your current organizational structure, teams and projects.  We are asking "what is", not "what should be".  When answering the survey questions, "we" means yourself and your immediate co-workers, "leadership" means your management chain, with most emphasis on your direct manager, "customer" means the people who will use the results of your work, and "stakeholder" means those who are funding and sponsoring the work.  
 
Finally, this is not a competition.  The results will be most useful in helping you reflect on your current circumstances and establish priorities within your teams on areas of potential growth.

Every time we apply this assessment internally, we gain a lot of actionable information that helps us focus our attention to the right areas.  We hope that by sharing our assessment instrument, we can encourage others to use this tool as part of their continuous process improvement efforts.

Does a million dollars worth of good for you; get rhythm when you get the blues

Rhythm is an important part of an agile team. Release planning, sprint planning, and daily planning all happen on a regular basis and allow a team to find the sweet-spot of operation: a comfortable and effective way of working together. Running a sprint for three weeks one time, two weeks the next and four after that feels clumsy and prevents a team from finding that natural rhythm, their runners high. If rhythm is so sacred though, then how does the retrospective fit in the agile picture?
Photo by TW Collins Why allow an opportunity to change things after every sprint and release if a main goal is to keep the team heartbeat steady?

The answer is because it works. Like with many agile techniques, this seemingly contrary approach not only works, but works well. In fact, I believe the retrospective is one of the most important parts of the agile cycle. The retrospective is the tune-up opportunity in the agile world, the method of discovering the peak operating efficiency. Because the discussion is conducted by the team itself, the likelihood of making changes that screw up the rhythm is low—a synergistic group isn't going to mess up what is already working. If it does manage to change something for the worse, during the next session the error should be recognized and corrected. I guess you could say that an agile team is like a washing machine; if it gets overloaded the results are spotty and if it gets out of rhythm then the banging will alert folks that something is wrong. The retrospective meetings are where a team figures out why things got out of balance or crammed in, and fixes the system so the all-important rhythm remains steady.

Post title is a lyric from Get Rhythm by Johnny Cash.

What is a Product Owner in Scrum

Scrum defines only three roles for particpants on a Scrum team; Product Owner, Team Member and Scrum Master.  In my experience, the Product Owner role is the least well-understood.  Some even call into question the need for this role at all on some projects.  I believe that "Product Owner" is a label for a cluster of responsibilities that may resident in individuals with such wide-ranging titles as "Procurement Manager", "Program Manager", "Product Manager", "Business Analyst" or "Chief Architect".  This role represents what a fast-moving development team needs to maintain maximum velocity while delivering maximum business value.  When I was asked to identify the key success factors for a Product Owner on a Scrum team.  This was my answer:

 

The core responsibilities of the product owner are:

• Be available (especially to the team) to clearly explain the product requirements and communicate exactly what will be acceptable to the stakeholders. 
• Have the authority and responsibility for consolidating all stakeholder needs into a coherent prioritized (and constantly re-prioritized) requirements backlog.

There are many supporting responsibilities that ideally are handled by the product owner, but may be handled by other supporting members of the organization as long the final decision, and responsibility for the results of that decision, rest with the product owner directly.  These include:

• Developing relationships with key customers and representatives of important market segments 
• Understanding the details of the problem domain that the product addresses 
• Understanding the technical trade-offs of various potential solutions and strategies 
• Balancing the timing of feature delivery to maximize cost/benefit over time 
• Coordinating the product strategy with collaborating products and teams 
• Coordinating dependencies and contributions between products for collective benefit

This requires strong leadership and negotiating skills.  Close trust-based working relationships with the team members is greatly beneficial.  Management and incentive structures must be in place to balance the desire for functionality with the realistic constraints on the resources required (especially time) to deliver that functionality.  This is most often seen in the form of "pressure" to deliver more in less time, with the implicit reduction of quality that leads to non-sustainable development practices and higher costs over the life of the product.

 

Here are links to a few online articles that add important details to this description.

• www.scrumforteamsystem.com/ProcessGuidance/Roles/ProductOwner.html
• www.scrumalliance.org/articles/44-being-an-effective-product-owner
• blog.lundak.org/2006/12/15/the-under-rated-product-owner-role/
• www.agilejournal.com/articles/articles/the-product-owner:-choosing-the-right-person-for-the-job.html

Principles vs. Practices

If you hang out with agilists for long, you'll inevitably hear accusations that some team or other is 'not really agile' because they do not precisely follow the established practices--scrum, XP, etc. I've criticized this thinking several times on my Agile Testing blog.

Here at Borland we have an agile process evangelist, Dale Schumacher, who works with the various scrum teams. Whenever a team that he's working with considers changing an agile practice, Dale grills them on it. I used to describe Dale's questioning this way: Dale's job is to represent the ideal of the practice; if the team in question is going to deviate from that ideal, Dale is there to make sure they understand the ramifications of the deviation.

As my understanding of agile changes (matures, I hope), I would describe his questioning this way: Dale's job is not to represent the practice, but to represent the agile principle(s) behind the established practice. If the team is going to change the practice, Dale is there to make sure that the team understands whether and how the changed practice still fulfills agile principles.

The Mature Agile Organization

Here's a quick note about a recently published technical note from the SEI: CMMi or Agile: Why Not Embrace Both? There's talk about it from some of the authors: David Anderson, Hillel Glazer and Jeff Dalton.  I saw them and Mike Konrad discuss the draft at an impromptu session at last year's SEPG Conference and am heartened to see the progress being made in the communities working together. 

I'll have some more thoughts on the technical note itself, but a bigger question in your mind may be "CMMi and Agile?  Those can't go together."  I heard that comment from a colleague the other night at dinner.  I disagreed and my answer was "A poorly implemented CMMi based process improvement- one that mistakes the model for a process description and that doesn't keep a firm eye on the goal of delivering business value- won't be very Agile.  And, a poorly implemented Agile based improvement effort- one that doesn't recognize the amount of discipline required, for example, or doesn't address what's necessary to scale up to an enterprise level- won't look good from a CMMi view.  But, I don't want either one of those things!"

Do you agree that there's value to an Agile organization in looking at the CMMi?