mikkeman.nl

One of the key practices of agile project management is continuous delivery of valuable software into the hands of your customers. Doesn’t that sound cool? Unfortunately, it’s all too common that customers don’t want continuous delivery of software. Why?

There are many reasons why someone wouldn’t want that. It might take too much time to educate your users continuously. Or continuous change to the system might disrupt daily production. These might all be good reasons to delay delivery to once every month (or 2, or 3). Please note, it does not mean you should stop looking for ways to increase the pace in which the organisation can digest change (after all, we prefer shorter time scales).

Recently someone asked “can’t we just postpone this software release with another year to implement many more features?” Of course we could, but why would someone want that? The answer was simple: project funding. Many organisations fund projects to deliver software. When the software is delivered, the project is over. No more funding, no more people, no more project. The software is transferred to a maintenance contract and you might be lucky to have 1 or 2 RFC’s approved in the next 10 years.

If an organisation works this way, it makes perfect sense to order as many features as you can think of, and delay delivery as long as possible. Because you know that extra funding is only negotiable as long as the software isn’t live yet. Your boss will consider your project “done” as soon as the software hits production. Good Bye Budget.

This problem can only be solved on a strategic level. Management should rethink their attitude to project funding. It might make perfect sense for an organisation to have software delivered after a month, and keep the project funded for another year. Such a change would make your entire organisation much more agile (buzzword alert!). Agile project management is much more about these kind of changes than introducing daily standups, pair programming and taskboards.

How does your organisation fund projects? And do you consider that agile?

Picture taken under Creative Commons license from jayneandd’s photo stream.

Yesterday I attended the book launch “De Kracht Van Scrum” at the Krasnapolsky in Amsterdam.

The book is written by Eelco Rustenburg and Rini van Solingen. Jeff Sutherland and Guido Schoonheim started the evening with presentations on the history of Scrum and how Xebia combined Scrum with offshoring. After that, Eelco and Rini climbed on stage to introduce their book, “De Kracht Van Scrum”.

To get an impression of the book (and a few laughs), please watch the trailer (it’s in Dutch).

The rest of the evening was well spent with a beer, getting a signed copy of the book and talking with a few other people.

User Stories are a nifty concept to convey “what needs to be done” in an agile environment, where not all analysis and design activities have been done before coding has started.

User stories need to be clear and concise, and everybody (Product Owner and Team) should have a basic understanding of the story during the Sprint Planning. Just enough info to determine the approximate size of the beast.

After the Sprint Planning, there will be (should be) LOTS of conversation and confirmation. By definition. Because the requirement is still only briefly analyzed, it is a false expectation to be able to understand and code a user story right after Sprint Planning (of course, it happens, but it shouldn’t be the standard).

I sometimes come across teams that look back and conclude that they didn’t deliver what was expected and propose to be “more clear in the wording and details of the user stories”. Don’t try to go that path. It’s a slippery slope, and before you know it, you’ll be back reviewing detailed designs. You might say it’s an anti-pattern of agile.

I don’t care what the user story says.

Make sure everybody has a basic understanding at first and work together to deliver what’s expected. That’s my preferred strategy if you adhere to agile principles.

Photo taken from koalazymonkey’s photostream under Creative Commons license.