Static, Thrashing and other Communication Dysfunctions

I was recently in a planning poker meeting which is a step in the release planning phase for agile software development projects where user stories are sized relative to each other. This is a critical step to estimating the cost and schedule of a project. By the way we typically call these meetings in our process "sizing" rather than estimating because we are specifically sizing the stories relative to one another, followed by another step to actually determine the estimate in terms of hours and therefore cost and schedule. 

This was one of the most painful meetings I've attended in recent memory. Painful because of the communication (or lack of) taking place during the meeting. While there was no shortage of experienced and talented developers and other stakeholders in the meeting there was a significant shortage of meeting etiquette which resulted not only in the typical thrashing that can plague such meetings but in interruptions, sidebar conversations and conversation threads that didn't pertain to the specific user stories or in some cases the project being sized.

We typically track the time it takes on average per user story across projects when it's feasible to do so in order to inspect and adapt and find ways to optimize the time we spend sizing each story.  What we noticed at the end of this particular meeting was that over 80% of the time spent was in the area of discussing items not specific to the story or in some cases far too specific, which was an indication for us that not enough time was spent in the most productive parts of sizing a story.

Based on this performance we have decided to display simple meeting etiquette rules similar to those types of rules we've seen in other corporate meetings reminding people to focus on participants as they are speaking and to try to limit interruptions unless they feel they're absolutely necessary in terms of understanding the point at hand and limiting side conversations, again unless they're seen as necessary. 

In the context of a user story sizing meeting we've also reminded ourselves of simple adjustments such as letting the customer read the story and then letting developers ask questions by taking turns. We'll ask those people not speaking to write down points or comments they feel they need to make. We hope these steps will go a long way towards focusing the conversation and reducing the needless amounts of static that we witnessed during this meeting and in general help optimize the time spent sizing stories across all of our projects.

While we acknowledge the fact that it's impossible to completely eliminate things such as interruptions and thrashing and even some sidebar conversations especially when you have very bright and creative people in the room such as we did for this meeting, we also feel strongly that if this isn't addressed it will result in not spending resources wisely.

Shaking Things Up

We talk a lot about our experiences in this column about our agile software development practice...so much so, that perhaps it sounds a little self-serving at times. After all, we're heavily invested in agile methodology. So here's a link to another developer's (Russ Nemhauser's) blog...a developer who joined an agile team at a Large Software Company Somewhere in the State of Washington. His background was in BUFD (big up-front design) and he therefore approached this Scrum project (in .NET) with a great deal of skepticism. Read about his conversion here. He also gives an example of test-driven development and talks about why he's now a believer...so much so that he's uncomfortable writing code before he writes the test(s)....and how (at least in this example) it was a time saver. (YMMV, of course.)

An interesting idea:

This doesn't solve the problem of some clients requiring large functional specification documents, but it does offer at least one potential change to the way they're written: the functional specification can be written AFTER the majority of functionality has been developed and delivered. This is a huge step toward an accurate specification and it also drastically reduces the amount of time it takes to write the document.

Say it in tests

Visionpace has been working with a client, providing agile coaching, over the last few weeks. Like all of our clients, the organization is full of bright people, making a viable product, and struggling to balance new development projects against existing legacy code. In this instance, the situation has lead to a few critical people wearing multiple hats and juggling a lot of different responsibilities.

Since these resources are in such demand for a lot of competing things, there always seems to be a bottleneck around them. As one might imagine, the responsibilities that involve human interaction (managing people or supporting customers) take a higher priority than those that are more technology derived (like testing).

Some of the common problems that we’ve seen in this situaion include:

• The team has spent a significant amount of time refining and re-defining what the scope of a story is during the iteration.
• During the iteration planning the developers work with the customer proxies to define the stories and acceptance tests for them, but the tests are not always captured at this time.
• The tests are sometimes too narrowly defined or too broadly defined to be of any use in validating the code.
• There is often the desire to select stories to work on that have not been fully clarified. They are the highest priority, or are the next logical step, but during iteration planning some questions arise that need outside input. At these times, the notion is to work on what we know now and we’ll fill in the blanks before we run out of defined tasks. Usually the answer to the unknown things changes the ‘known’ items and leads to more questions. This cycle is repeated a few times before the dust settles.

Some of the smells associated with these problems are:

• Constantly adding tasks during the iteration to account for missed features
• Running out of tasks in the backlog mid-iteration because the features were misunderstood.
• Generating a lot of code inventory during the iteration because it is waiting on testing (developers saying that ‘I think it’s done, but it needs to be tested.’)
• Switching gears from implementing tasks to iteration planning (user story discussion and task breakdown) mid-iteration. This isn’t always bad. It just shouldn’t be the norm.

So what’s the proposed solution to these smells you ask? Inspect and adapt. We’ve been including the expert user in the iteration planning meetings and asking them to review the user story with the developers. This causes the developer to get into discussions with the customer proxy about the pros and cons of what is or isn’t included in the story. It causes overall confusion as to what needs to be tasked out, and can lead to a feeling of uncertainty about what needs to be implemented.  The focus of the iteration planning moves to architecture possibilities and eventually a ‘code speak’ between the developers about where we should go. To avoid this we’re going to try something new on the project that we’ve used successfully in the past with other Visionpace clients.

We’ll break the iteration down into to steps; iteration prep and iteration planning. The goal is to define what the user story is (and isn’t) in the iteration prep. The output from the iteration prep is a set of written acceptance tests and some low fidelity models of forms, reports, etc. for the user story. The tests are then used in the tasking portion of the iteration planning meeting to refine the scope of the conversations.  The features of the user story are described to the development team via the list of acceptance tests and the low fidelity mock ups are used to explain the tests. (Say it in tests!) Another benefit of this approach is that the acceptance tests are refined in the iteration planning and when the developer feels that they have implemented the feature, they have a series of tests to confirm their belief. Finally the tests from the iteration prep are either added to a manual test script or incorporated in an automated testing tool.

The takeaway for all of this is that the roles and responsibilities are leveraged in this situation to minimize chaos. The customer (or proxy), the scrum master, and other appropriate parties work to define what the user story is without worrying about underlying architecture or developer centric details. This definition is delivered to the developers in the form of low fidelity screen mock ups and documented acceptance tests, so they can focus on defining what they are being asked to implement.