Agile project management makes the client an integral part of the development process. This article explains what your responsibilities and powers as a client are, and helps you to understand project management the way we see it.

In the traditional (waterfall) model of software development someone writes a specification of the whole software and then the programmers fail to implement it within the given time/budget. To be honest I don’t know a lot about this way of doing software, but I’ve seen it fail.

But I do know a bit about how we write software. In contrast, agile development works in small steps. There is no upfront specification, as we acknowledge that this specification would be incomplete and quickly outdated by changing requirements. Instead we work in short iterations (at upstream typically ~2 weeks) where we only plan ahead for a short amount of time.

By aggressively prioritizing what is most important we are able to release software that fulfills the needs of the business with less clutter in a shorter amount of time.

For me this sentence is really the essence of agile project management as it shows its most important point: prioritizing what is important for your business.

What is software the fulfills the needs of the business? It’s a software that solves your specific problem. If you want to sell something online it allows your customers to click a buy button. If you need to send invoices it will put a bunch of numbers on a sheet.

What is less clutter? Less clutter means if you want to sell something online it neither has a tag cloud nor a facebook like wall for every product where users can post their video reviews. If you need to send invoices it will not let you upload pictures for it.

What is less time? Less time means we deliver your product faster because we spend less time on implementing features because there are fewer features. It does not mean that we can program faster because we are doing agile (seriously we can’t).

What is prioritizing? You do the things first that are most important.

So what is important? And here is where it gets difficult.

What is important is your – the client’s – decision. The problem is that a lot of things can be (thought of as being) important. For a web site, the start page has to have a maximum conversion rate, SEO is important, scalability is important (isn’t it?), usability is important, choice of technology is important, the database schema is important… you get the idea.

But do you know what’s really important? That your business problem is solved. And do you want to know how many kinds of business problems there are? Well, there’s exactly one: make (more) money.

I think it actually is that simple, but from what I’ve seen it can become really hard to focus on that one goal, when you think you have to consider all that other stuff as well, but let me say this again: as a client it’s not your responsibility to think about the database and scalability (you won’t have to scale in the beginning). Your one and only problem is: how do I make money with this. Everything else comes after it.

A good way to focus on solving that problem might be to ask yourself this question: How do I make (more) money?

Case Study

Let’s stick to the example of an online shop and let’s assume you want sell e-books. Of course you look at the competition first, and there is amazon.com. They sell e-books and from what it seems they are making a whole lot of money from it, so that must to be a good starting point. From their site you collect a bunch of requirements you also want in your shop:

• Categories: Books must be in categories so people can find them.
• Tags: With tags people can click on tag clouds and then see all the books to that tag.
• Related books: “People who have bought this might also like…” – I love that feature
• User reviews/ratings: when users review the books we can make a top list and then everyone will buy the top books.
• Licensing: You have talked to the publishers already and they have these complicated licenses where you may only sell a certain book in a certain country but only at full moon when it’s raining – so the shop needs to take all this into account.
• Internationalization: We need at least English, Spanish and Mandarin to reach more markets
• Statistics: You want to know at what time and weather conditions people buy books from where, on which browser and operating system and which IP address they used to do it. From that data you will be able to optimize the hell out of the start page.

So, that looks like a reasonable list of requirements doesn’t it? With this shop you could steal a nice market share from amazon right? Well, let’s take that list to the test: does it help me to make money?

• categories: no
• tags: no
• related books: no
• reviews/ratings: no
• licensing: no
• internationalization: no
• statistics: no

Surprised? I hope at least a little bit. So what would make you some money?

In order to make money
as the owner of the shop
I want people to buy a book

With all the fancy features above you forgot (sorry, I forgot) the only important feature of the site: a button that says “Buy this e-book”. By the way the format of that feature request comes from the BDD (behavior driven development) people. This is the generic template:

In order to <business value>
as <role>
I want <feature>

This is a brilliant template that you can use to take all your feature ideas to the test. Remember that the only valid business value here is to make money. And that the only role that is important here is you as the stakeholder of the project.

Let’s look at your features:

Categories

In order to make money
as the owner of the shop
I want categories

How is a category going to make money? A category is a means to, well, put your books into categories. You might at some point decide that you can sell more books by putting them into categories because that big list of 1000 books on you start page crashes people’s browser and they can’t buy your books anymore, but for now you haven’t even sold a single book yet, so categories are definitely not going to make you any money right now.

Tags

A few years ago someone declared that if you want to be “Web 2.0” you need tags. That’s why a lot of websites have tags nowadays. Like categories you can’t make any money out of tags.

Related books

While this is a popular feature at amazon, your yet to be launched shop wouldn’t even have enough data at the beginning to make any sensible claims about what books are related. Again, at the beginning this won’t matter at all. You can always add it later, when the money making assertion becomes true.

Reviews/Ratings

While reviews can be a good way to promote books and build trust for your customers, when you launch your site there won’t be any reviews because nobody has bought a single book yet. So unless you charge people for being able to write reviews this is not going to pay your rent.

Licensing

Sure, we can build you a system that grabs the weather from weather.com, can calculate the moon phases over the sahara and figure out people’s countries by their IP address, but it’s going to cost you. How about this: You start and market your shop in only one country. This can be your home country or the country with the simplest licensing model. After you have sold enough books there we can start working on the rest (and you can pay us from the money you have made already).

Internationalization (I18n)

Again, we can build you any system you want, but be warned, some people read and write from right to left or top to bottom. WIth I18n you are opening a whole new can of worms. How about we do I18n later, after you have proven that your business model works in one country (or language region, which might cover a lot of countries (thinking English/Spanish/Mandarin)).

Statistics

Sure it’s important to measure the success (or failure) of your business. But before you have a business there isn’t really much to measure is there? And how about this: for now every time someone buys a book you open up your spreadsheet app on your computer and put a date and a price in it. I know it may seem archaic but it works. If you want to go crazy you can even use a real book made of paper, but since you’re selling e-books you probably don’t want that.

All these examples boil down to this: test your features agains the BDD template: can I make more money now when we implement this. A lot of them are really not that important now and you can use something simpler instead.

Conclusion

Deciding what is important is the one big way that you can control the project. Programming takes time and we don’t usually have a lot of ways to make that faster within a project. But choosing wisely the features that you really really need to start selling your products can make the difference between a 4 week and a 6 months project. We do the best we can to help you with those decisions but ultimately they are yours.

If we spend 6 months working on your project and it’s still not done then that’s not a programming problem, it’s a management problem, because we have been working on too many features, of which many probably weren’t as important as you thought (no offense). On the other hand if we make it in a few weeks, we’ll congratulate you and bring some drinks to your early launch party.

(On a side note we recently released cobot.me after only 4 person weeks of development it doesn’t have a lot of features, but that’s a different post.)

When working with our clients we use pivotal tracker to manage requirements and priorities. Which works very well, as it keeps overhead low and offers a very focused communication channel for feature related questions.

The last step for a successful delivery of a feature requires our customer to accept that feature or hand it back to us if something isn’t satisfying. To enable our customers to do that we provide them with a staging environment, which is a non public version of our customers’ product with the latest code integrated so that he can try out new features before they go live. We deploy to the staging system directly from the master branch usually, from time to time we introduce feature branches if we think something takes longer or might need refinement after more customer feedback. By the time of an actual live deployment we normally have ironed out any remaining issues which shown up during the client’s review on the staging system.

This simple system works pretty well and effective if you are in control of the staging environment, have only one person as the customer to talk to and your developers’ communication works like in a hive mind (which it does, mostly ). This system reached its limit when we worked with PaperC lately, one of our valued clients.

We coached their programmer in BDD and pair programming some time ago and still working with them very closely to get improvements and new features out of the door fast. The limits with our simple workflow became visible when I paired with Patrick together for PaperC and they also had a pair on site with us at co.up. At first delivered tickets began to stack up waiting for acceptance, also because the staging system became unstable as issues weren’t fixed fast enough.

Things got more complicated as we put features on staging which weren’t supposed to make it into the next live deployment as they where part of a bigger, not yet thought to an end, interface change. These features just should be shown in action to see how things can go on from what we did so far. This incident cost us some extra time to put these feature related commits out of the master branch into a feature branch. So we switched to create a feature branch for everything that was more than “add a new input field to that”. This left us with a lot of branches we had to keep track of when deploying to the staging system, but at least we could undo merge commits easily when a feature wasn’t suppose to be deployed live. Then we started a discussion on how we could do this in a better way. Before I describe the workflow which I think is best suited, as we already employed it successfully in the past, I’d like to mention two suggestions I’m not comfortable with an why.

One idea was the introduction of pair branches, where every pair commit their work to. And these branches would be merged into master for acceptance. Apart from not really resolving the issue, it just mitigates it onto a pair branch, and it contradicts the principle of collective code ownership.

Another proposal was to create a special production branch and selectively cherry-pick commits which are supposed to go live. This points into the right direction, as it gives you more control of what goes live, but it might leave you with a lot of commits to pick from, if you have a developer like me who commits rather often. And it doesn’t give you a single point to roll back from if a feature that has multiple commits get pulled off the release.

So now for my preferred and practically proven solution. First off, it requires an extra server which I refer to as experimental. It is a lightweight (not so close to production setup) staging system with a database schema that should be easily migrate-able up and down like on a CI server. It should be fed with some test data automatically. It doesn’t have to be as much data as on staging, just enough to try out most features.

Now to the git workflow part. Smaller changes and bug fixes go directly to master as always. Bigger features should be done in separate branches and merged to master once things are done (Don’t forget to delete the remotes if the feature gets accepted). The master branch should be deployed to the experimental server at least once a day, likely more often so that features can be quickly accepted. Features that aren’t necessarily ready for production yet can be deployed to experimental for acceptance testing simply by changing the branch from which the experimental environment should be deployed from the master branch to the feature branch and rebuild the database if required. Before an imminent release the master should be pulled to staging so that any remaining issues can be fixed. Such fixes should happen on the staging branch and can later be merged back to master. If everything is fine, merge staging to production and deploy to the live system if you are ready. This way you always have a clean production branch, it’s easier to pull off features from a release and get faster feedback for completed features without worrying to mess up the next production release.

What is your approach to managing commits and releases? Do you find this post helpful? Feel free to leave some feedback in the comments.

updated: added sven’s point from the comments

Explaining agile to customers is hard, sometimes more, sometimes less so. In order to improve communication and make it clear what to expect and what not to I came up with the following checklist of what agile projects are about:

You DO get a working, maintainable, production ready, 100% quality piece of software in a fixed amount of time.
You do get a first working, maintainable, production ready, 100% quality version of that software after a very short time (usually 1-2 weeks).
You DO get to launch your software in time.
We DO pair program all the time to ensure that quality and it doesn’t slow us down.
We DO write automated tests to ensure that quality and it doesn’t slow us down.
You DON’T necessarily get all the features you wanted after an iteration.
That’s why it’s important that you DO prioritize what’s most important for you.
We DO estimate how long each feature will take us to implement. But it’s only an estimate.
We DON’T accept a functional specification you bring in as a basis for our work.
We DON’T believe this would work. We DON’T believe it is possible to completely specify a software upfront with tolerable effort.
We DO use your functional spec as a basis for a discussion where we’ll write down stories for each feature together with you. Those form the basis of our work.
We DO embrace changing requirements by working in short iterations.

We DO deliver successful software projects when working like this.

__________________
Signature Customer

Anything I forgot? The comments are open.

Ich benutze seit Jahren Trac für Projektverwaltung und Dokumentation. Bugs und Requirements zu den Tickets, Milestones anlegen, ein paar custom Reports, alles andere ins Wiki. Alles ganz schön und gut, aber das Gefühl, dass da noch mehr geht, wollte nie so richtig weichen.

Ein Tool, das agile Prozesse direkt unterstützt oder gar .. quasi einfordert. Das mir all die Zahlen liefert, die ich schon immer haben wollte. Ein Tool mit eingebauter Planning Game-Unterstützung. Was auch immer.

Und nun kündigen ausgerechnet Thoughtworks, die Altmeister des Agilen, so ein Tool an. Und es soll Mingle heissen. Außer Werbegefasel gibt’s noch nix zu sehen, aber ich bin hochgradig gespannt.