by Paul Klipp
There are several agile process that are very well documented, of which the best known is Kent Beck’s eXtreme Programming. Others include Crystal, Scrum, and Feature Driven Development. They all share the same basic principles and have their own strengths and weaknesses. It is not my intention to compare and contrast or to criticize or praise. That has been done ad infinitum and is easily researched on the web. What I would like to do is to contribute my first agile experience to the current body of knowledge.
Lunar Logic Polska is a Polish software development company that was founded in 2004 by Mark Lipson (CEO of Lunar Logic, inc.) and Paul Klipp (former Senior Project Manager and Executive of Lunar Logic, inc.). It has a staff of twenty as I write, and is growing steadily. In the summer of 2005 we began to be presented with requests for projects that did not lend themselves to traditional RAD approaches (tight budgets, tighter timelines, no time for a formal specification, and clients who knew what they wanted to accomplish, but not how it should work). I had been reading about agile processes for years, but only now, as president of a small software company, was I in a position to put theory to the test. Now, after completing two agile projects with very different customers, I feel like Lunar Logic Polska has something to contribute to other software companies considering experimenting with the agile promise.
The first project consisted of a reasonably complex database-driven web application that collects purchase requests from users throughout a company and relays them to appropriate purchasing agents. It includes a workflow for authorization of purchases by managers and the CFO (in the case of large purchases) as well as a system for setting and managing department budgets and sending alerts when actions are needed or when custom budget-related alerts are triggered. It also features vendor management components and some specialized invoice-handling components requested by accounting.
I had another agile project waiting in the wings and I planned to develop both applications using similar technologies and the same development team. Scheduling was strict, with two-week development cycles, one week of testing, and a one-week Planning Game. The result was that at any time, the development team was in a development iteration while the other project was being tested and planned. Both projects were expected to reach a final state in two to three iterations and, being both greenfield projects, we also planned to deploy the first iterations.
Our specification for the purchase request application consisted of a single piece of paper, the purchase request form, and the instruction to eliminate it, fast. We made inquiries into the lifecycle of this slip of paper. Who fills it out? Who do they give it to? How does it get approved and by whom? What happens when the purchasing agent gets the slip and when the item is bought. A quick teleconference answered all of these questions. Based on the lifecycle of a purchase request form, we sketched a workflow for its virtual equivalent.
Our client appointed a single person, the head of the purchasing department, to perform the customer role. She approved the workflow and the first batch of user stories, which we wrote. We found it much easier to begin the collection of user stories by documenting our conversations in story format. This method achieved two purposes in addition to simply creating stories. It taught the client how to write user stories and by translating our understanding of the meetings into stories, we were able to uncover minor misunderstandings between the project manager and the client. However, the quality of our planning increased markedly when the customer began writing user stories in the second iteration.
The first iteration was a success in that we closed all user stories slated for that iteration and produced an application that fulfilled its primary objective of replacing the paper process. Ultimately, however, this first iteration was a failure. It failed because the client had not accurately identified the key stakeholders up front, and so soon after deployment we discovered that certain key executives, once they saw the application deployed, had unfulfilled requirements which they considered essential. It also failed, I believe, because it was built for maximum functionality rather than aesthetics. Over the course of our first two agile applications a recurring sense of discontent or perhaps distrust for the applications was a persistent issue, as the applications, though complete, sound, tested, and fully-functional, remained graphically unappealing. No matter how much functionality we built in, it was graphical enhancements that earned us the most praise from users. In the future, I have resolved to begin with graphic design so that the very first iteratations include design elements such as logos, borders, an attractive color scheme, and backgrounds. As developers, we consider such things to be of minor importance compared to functionality, but many users will always judge a book by its cover. We know that agile processes are aimed at achieving production-quality code at every iteration, but the user might not understand that unless the packaging reflects the quality of the contents.
As a result of our customer’s failure to identify the stakeholders correctly, the first iteration was never used, although it was deployed, and so we didn’t get the user feedback that we would have liked before embarking on the second iteration. In this case, the client set up an email alias that included many more stakeholders and appointed a new, more software-savvy, stakeholder to the customer role. As a result, the second iteration produced a much more useful product.
The new customer started writing user stories, and as I mentioned before, that had a distinct impact on the quality of the Planning Game. When the customer actually puts pen to paper and writes a user story, I believe that they are forced to think through their intentions more carefully and this consideration results in more distinct specifications. This customer was also proficient at Photoshop, and created mock-ups of ideas too complex to easily capture in words. While I don’t believe that a Photoshop wireframe is necessary, it became clear that a client who took the time to sketch out an idea would be more likely to get what they wanted without undue confusion. Also, like the process of writing user stories, I think that sketching ideas helped the client to visualize the user experience and to think more creatively about their true expectations.
We were still learning lessons about velocity and once again, closed every story slated for the iteration. Given that the developers are supposed to use best case scenario estimates, the fact that we were consistently closing every story on time suggests that our estimates were too pessimistic.
The second iteration produced a product that the customer decided offered enough value to deploy. Deployment went well, due to the fact that we had deployed the first iteration and in the process the System Administrators at the client’s location were familiar with the application. The application is now in use and functioning so well that there is not a need for a third iteration. Due largely to excellent direction provided by the customer, who was very engaged, thoughtful, and communicated well and in a timely manner throughout the second iteration, we produced a very solid and useful application not only well below budget, but at a lower cost than I have ever achieved using more traditional development processes.
We also learned some important lessons which I would like to elaborate on.
Looks Matter
Even a technology-savvy customer can be forgiven for lacking enthusiasm for boxes on a black and white screen. Certainly a larger stakeholder group will include people of varying degrees of technical sophistication. Based on our early experiences with agile processes, we now schedule UI design and graphic design in the first iteration of any project. It has to be done eventually anyway, and it certainly doesn’t hurt to make the best first impression possible.
Agile is not for everyone
The customer has to know what an agile process is and why it’s appropriate. If you do not spend time up front agreeing on a the method and defining the process and the vocabulary, you can build an excellent application below budget and still have a frustrated customer. For example, I had once had customer ask if we could extend an iteration after it had been successfully completed because he was enjoying the pace of progress. He went on to suggest that calling an iteration successful despite the fact that we hadn’t closed all the stories scheduled for the iteration was a bit like “smoke and mirrors.” He would rather not stop development, but continue the current iteration until all of the stories were closed. That is a very reasonable point of view, but it clearly shows that we didn’t have a common vocabulary or full buy-in for the values of an agile process.
The problem, of course, is that we couldn’t continue with that iteration, because it was done. The purpose of an iteration is not to close all the stories, but to produce production quality code and create a fully useable product by the appointed deadline. That deadline having been reached and the code passing all tests, the iteration was over, and successful. I explained that there is no reason to stop development, but that since that iteration was successfully over and the new task was to work toward another working build at another set date; if we resume development without an extended Planning Game it must be a new iteration that we are working on.
The beauty of iterative development combined with continuous integration is that if we approach a piece of software with the intention of working until all features are done (traditional approach), then at no point in the project is there useable code except at the end. Whereas with iterative development, the client can pull the plug at any time and have a working product, even if not fully-featured. For example, halfway through a large, waterfall or RAD (Rapid Application Development) style project we might have had a working administrative interface but not working user interface, or no user authentication system; in other words, a fundamentally flawed and unusable product. Halfway through an agile Project (at the end of any iteration) we have a product which, though lacking some intended features, actually had all the essential components of a software tool finished, tested, and ready to deploy if desired. The customer is not married to the project and the developers can’t hold the project hostage until the bitter end; If it concludes early, the investment is not a sunk cost.
Agree on vocabulary up front.
As I wrote above, a misunderstanding of what iterative development means can lead to a lot of confusion. The software developer needs to learn how to help a customer understand the difference between methods (waterfall, RAD, or agile) and to choose and then appreciate the right method. Vocabulary works against us here. XP uses words that are easily misunderstood. For example “agile” is in Webster’s, but it means something very different when used to describe the twelve practices and four principles of eXtreme Programming. A customer can be forgiven for hearing the word “agile” and deciding that it means that anything goes when in fact it means very strict discipline and process. Likewise “customer” means to most people “the guy who foots the bill and makes demands” when in XP parlance it means “the guy who is responsible for writing user stories, acceptance tests, representing the business case, providing timely feedback, and making the decision after each iteration whether the product demonstrates enough user value to merit deployment.” So words that on the surface imply great freedom actually imply great responsibility. If you fail to communicate that to the customer up front when they sign on for an agile process, then you are bound to suffer from their frustration and/or dissatisfaction later, even if the product itself is successful.
It is possible to phase in XP
We did not implement several XP practices during the first project, though we learned why they could have helped. Test driven development (writing unit tests BEFORE coding a class) would have produced a more robust testing framework which would allow us to refactor with less fear. That didn’t matter so much in a small application, but now that we are applying agile methods to larger applications we have learned that developing a proficiency in test driven development is a real asset in the long run.
We have still not wholly bought into the idea of pair programming. I can see where it would have its place in a very complex project, but thus far, simply discussing architectural issues as a team daily and placing programmers working on the same project in the same office has given us sufficient opportunity to benefit from collaborative problem solving without actually putting two pairs of hands on one keyboard.
Suit the reporting to the customer
Initially, we maintained a daily build on the demo server for all projects. We still do that, and encourage customers to look at what we are doing anytime they like. It allows us to get stakeholder feedback when it’s most useful, during rather than after deployment. However, we initially expected the customer to review our changes as we closed stories to confirm that the goals of each story were met. Some customers approach this task with gusto, but others consider it a time-consuming burden. Therefore, we have taken to attaching screenshots of new functionality to our emails announcing the closure of a story. That way, all stakeholders can review our progress without having to log into the demo server every day.
copyright 2005 Paul Klipp
