Steele Bit programming & development musings by Andrew Steele

My team is in the process of transitioning our development methodology. We have never had a formally documented development process. At best our practices have been most akin to waterfall and at worst haphazard. We have succeeded in developing this way because we have been in a perpetual maintenance mode, tested relentlessly, and new development has largely been completed by small groups of developers. Over the course of the last year we have been slowly transitioning to agile practices while incorporating the interaction design philosophies espoused by Alan Cooper. As we are beginning a major redevelopment effort we felt we were finally ready to take the next evolutionary step, adopting an agile methodology, Extreme Programming (XP) and more fully utilizing Cooper’s personas.

In Extreme Programming and Inmates I argue that the use of personas can assist XP teams in generating user stories. What I do not explain is that on the morning I set that post to publish my team was gathering to do exactly that. We spent all of last Thursday in a conference room. Our meeting began at 8:30 AM with a roughly outlined agenda.

In the weeks prior to the meeting we had worked to create a cast of characters representing our identified user personas. These personas were based on the demographics and unique goals of our intended user base. At the meetings outset our intent was to identify those personas which were positive and negative. After some deliberation we identified three positive personas and nine negative personas. Of the three positive personas one was clearly primary.

Having culled our cast of characters we began a traditional brainstorming session. This brainstorming session was not like others that we have had as our discussion and ideas were focused. Knowing who we were talking about allowed us to quickly generate a valuable mind map. After a morning in a conference room we decided to take a break for lunch.

Even after the successful morning I was nervous to return from lunch. While my team had responded well to the use of personas for brainstorming I feared their unfamiliarity with user stories and some lingering tentativeness toward personas would hamper our productivity. I had visions of us sitting around a table just staring at each other.

To my great pleasure I discovered that my fears were unfounded. The team adapted to creating user stories quite readily. We had the same experience that we had had in the morning in that the personas focused our discussion and allowed us to zero in on who a particular story was for. We turned on music and laughed our way through the remainder of the afternoon.

At our meetings conclusion we found that we had generated over a hundred user stories. Many more than we can complete in several iterations. I am happy to report that using personas in conjunction with story cards has thus far been a resounding success.

Story cards and use cases are both mechanisms for documenting user goals. Story cards are part of the agile software methodology Extreme Programming (XP). Use cases are part of the more formal Unified Process (UP) methodology. The two approaches share similarities but differ in their application. It is these differences that make one method more appropriate than the other depending on the type of project.

Story cards are user goals written in the form of two to three sentence stories on index cards. A story card contains enough information for the customer and developer to understand the story’s intent and estimate its implementation difficulty. In contrast, there are three use case “dressing” levels. A “briefly dressed” use case does not differ greatly from a story card in the amount of information documented. A “casually dressed” use case captures additional information but is not as detailed as a “fully dressed” use case-- a highly detailed document including pre/post conditions, alternative paths, and exception handling.

While story cards and briefly dressed use cases resemble each other in the amount of information documented, their function differs. Briefly dressed use cases are essentially placeholders for future fully dressed use cases. Fully dressed use cases are the final result of many customer and developer implementation conversations. While not every use case must be fully dressed before development begins, generally no development work towards implementing a particular use case begins until that use case is fully dressed. Conversely, story cards act as a conversation starter allowing programmers to begin development while still engaging the customer for implementation details. Establishment of user acceptance criteria for the story cards occurs during these conversations. From these criteria developers are able to create automated user acceptance tests. Automated user acceptance tests are a code form of the formal written documentation in a fully dressed use case.

XP story cards enable concurrent conversations during development, while UP use cases enable preemptive conversations prior to development. The difference between preemptive or concurrent conversations goes to the heart of the differences between agile and formal development methodologies. Agile methodologies and XP in particular attempt to engage the customer throughout a project’s development lifecycle. Story cards are a means to continuously engage the customer while developing a product. Formal methodologies like UP primarily focus on detailed documentation before implementation work begins. A fully dressed use case attempts to detail all possible usage outcomes creating a blueprint for a developer to work from.

Whether story cards or use cases are more appropriate for a particular project depends on whether an agile or formal methodology is most appropriate for the project. Projects that are life critical, require a very high degree of precision, or the development team is highly distributed will benefit from the use of fully dressed use cases and a formal methodology. Projects that allow for repetitive iterations, have a low fault tolerance, and lend themselves to close developer/stakeholder collaboration will benefit from the use of story cards and an agile methodology.

Much like agile and formal methodologies, story cards and use cases have advantages based on the type of project under development. Developers should be aware that while they may prefer one methodology over another, project requirements may determine which methodology is more appropriate.

In The Inmates are Running the Asylum Alan Cooper makes a compelling argument for interaction design which Cooper contends requires thorough exploration and documentation before any programming begins. Kent Beck in Extreme Programming Explained describes that the methodology uses a pull development model which specifies stories in detail immediately before implementation. When juxtaposed these two assertions seem contrary but upon reflection can be made complementary.

At their core agile methodologies like Extreme Programming (XP) emphasize creating good products, not just good programs. This distinction while subtle is important. By embracing the external input of customers, users, managers, and stakeholders XP practitioners acknowledge that a product is more than just a program comprised of features. Cooper similarly believes that a successful product is not just a feature compilation arguing that achieved goals, not features, compel users. Cooper’s advocacy for goal driven design leads to his suggestion of utilizing personas-- hypothetical archetypes of actual users. In XP projects developers can use personas as stand-ins for onsite customers. Personas allow XP teams to vet features through the lens of accomplishing a persona’s goals.

XP developers document external input in the form of user stories. An XP user story is a mechanism which estimates and describes units of customer-visible functionality. In his Agile 2008 Conference keynote, Cooper contends that creating user stories is arguably an agile programmers’ weakest skill and is an interaction designers’ strongest one. Cooper goes on to conclude that while agile methodologies like XP bring outsiders into the software construction process it is interaction design that makes the contributions of outsiders effective and useful. Simply stated, XP puts developers and stakeholders in direct collaboration while Cooper advocates placing an interaction designer in-between stakeholders and developers. Utilizing an interaction designer in conjunction with an XP team seems reasonable; allowing developers to focus on technical problems and interaction designers to focus on human factors. XP programmers can take Cooper’s advice by investing time to fully frame user stories, which ultimately speeds up programming and reduces costs.

Both Beck and Cooper are advocates of an iterative process. In Chapter 3: Wasting Money Cooper warns against using iterative product delivery as a means of product refinement. Later he declares that “getting to the right product is always a matter of iterating” (Cooper p240). What Cooper does not stress in Inmates but does so in his keynote at the Agile 2008 Conference is where the iterative process should take place. Cooper believes it is folly to iterate where customers are subject to abuse by those iterations and instead urges iteration during the design and engineering phases. While Beck urges that in an XP project the product should be in a releasable state at an iteration’s conclusion, he does not suggest that it must be released.

Incorporating Cooper's goal driven design with Beck's XP practices improves software product development. Beck acknowledges that there is no litmus test for certifying a development team extreme and Cooper is ultimately a proponent for the tenets of agile methodologies. While at first glance Beck and Cooper may seem to be in conflict regarding iterative software development, in reality they both offer valuable suggestions which should be leveraged. It is therefore up to an agile development team to incorporate the suggestions of each practice in a sustainable and effective way.

I have been kicking around the idea of starting a blog for a couple of years, but with this post am jumping in feet first. One of the reasons it has taken me so long to begin blogging is I could never commit to a name. Generally, the names I came up with were too restrictive and locked me into too specific a topic. I did not realize the problem with one name until after I had registered the domain and realized it was a dirty word in Dutch. To have reaped the benefits of blogging earlier I should have damned the naming torpedoes and proceeded at full speed ahead, but am glad I did not because I am exceedingly pleased with the name I finally selected: Steele Bit.

Steele Bit covers everything I want my blog to be about. I imagine that some posts are going to be personal in nature, including my last name covers that. That said bit is the more interesting part of the name.

The word bit is fun because it has a long list of definitions. I use it here primarily because the relation bits have to technology. I intend to focus my writing on programming and related topics. Further, as a card carrying geek I will not be able to keep myself from posting on new technology. Finally, the word bit invokes the sense of something small which is to say I do not intend to be unnecessarily verbose in my posts.

In summary Steele Bit will primarily be a blog about programming, a smattering of technology, and with a bit (see what I did there) of personal anecdotes thrown in for good measure.