Reading this little ebook was very enjoyable and provided me with valuable insights. It is written in a very pragmatic and approachable way, and provides hands-on guidance. Now, none of this is rocket science, but then simple things aren’t necessarily easy.
James Coplien and Gertrud Bjørnvig have written a wonderful book explaining how lean architecture can play a meaningful role in agile software development. Here they describe the benefits of use cases “as a way to capture what the system does when it is important to understand a sequence of work towards a goal in a context” (Lean architecture for agile software development, ch. 8.2).
The notion of a sequence of work towards a goal in a context resonates strongly with me: it’s a brief and–to me–powerful way of tying what needs to be done to context and purpose.
I have been working on e-commerce sites for the last few years. Much of the work has been driven by conversations about user journeys or user interaction flows (or whatever you’d like to call this).
I suspect that interaction flow descriptions/visualizations and use cases might well complement each other, but I haven’t yet seen them being effectively used together. I’d be grateful for your thoughts, experiences and suggestions.
When I say “use cases” I refer to the Alistair Cockburn tradition.
James & Gertrud more often used the phrase “a sequence of tasks…” than “a sequence of work…”. The latter seems preferable to me as it seems applicable in a much wider context.
A few weeks ago I joined an up-and-running software development (and service operations) project together with a few other people. The team had already launched the first version of the product successfully. We had heard that huge effort had been put in to achieve this success and we had a hunch that the team would likely benefit from a renewed emphasis on certain lean & agile practices. We also had a hunch that the team wouldn’t benefit from us showing up and starting to lecture from the latest Scrum book or so.
I consider us extremely lucky to work in an environment in which we are free to choose our working practices (obviously within reason). I also consider us extremely lucky to work in a great team willing to own their work — and to put themselves on the line every day trying to improve our performance while at same time having to deliver against high expectations.
Listening to the team and the people around us, and establishing a shared understanding of our goals (including trade-off priorities; hat-tip to Alistair Cockburn) and the forces acting on us seems to be the essential foundation for our learning. After that, getting out of the way seems to be the best thing us management types can do. Every so often, we can provide some support and advice, or offer some re-assurance and confirmation. But mostly, it seems to be about getting out of the way and keeping the way clear of other obstacles as best as we can (we have way to go on that one).
Our work practices seem to become more lean & agile by the day, and I think our performance is improving. This post makes reality probably sound easier than it is, but I feel things are going so much better than whenever I’ve seen project teams being instructed to “be agile”.