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.

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.