Melting Icebergs, Devil Ducks and Epics - Agile 2009, Day 2 - codecentric AG Blog
Was yesterday really only the second day of Agile 2009? Then I have to hurry to write down my impressions, before the next day will have been started.
Keynote, by Alistair Cockburn
Dr. Alistair Cockburn not just entered the stage, he marched in, accompanied by a bag pipe player and starting with a variation of Shakespeare’s Julius Caesar.
I come to bury Agile, not to praise it;
The evil methods do lives after them,
The good is oft interred with their bones,
So let it be with Agile.
The noble Waterfall hath told you Agile was ambitious:
If it were so, it was a grievous fault,
And grievously hath Agile answered it.
Quite an interesting opening. The core message of the presentation was, that “Agile” is like a melted iceberg. It dropped into the water of software development, left its traces (ripples and waves), but is now common practice and natural part of the whole. Fiveteen years ago, “Agile” was meant to be for small, co-located teams, and has little to do with the size (up to many tenthousands) and scope (life-critical systems) of todays implementation. We need a new way of software engineering for the 21st century, which shall be based on the following foundations. Software development
- Is a corporate game: software development can be views as a cooperative, finite game (until the release at the end of the iteration), with an ongoing goal conflict between delivering the software and getting set-up for the next round. You have three possibilities: Invent, Decide and Communicate, and always face the problem that no two situations are ever the same and always require new strategies.
- Is a craft: This part of the presentation was mainly delivered by stories and anecdotes to emphesize the importance of understanding your craft. Everybody is going through three Stages until you really master you craft. From the Japanese there are three steps calls Shu (learn/copy one technique), Ha (collect several techniques) and Ri (invent your own techniques).
Uses lean processes: You can look at software development as a manufacturing process, if the items floating through the various posts of the manufacturing chain are unvalidated decisions. This way it is relatively easy to detect and fix bottlenecks.
While I agree with the three foundations, I find the statement that agile is mainstrean and was not meant for what it is currently evolving into at least questionable. Agility may be well understood by now, and because of that less suitable for research and publications, but that does not mean that it is into wide use everywhere. If it was initially meant only for small and co-located teams is beyond my judgement, at least my impression so far always has been different. Answering a question from the audience, Alistair emphasized that he does not want to bury agile. Rather he wants to make clear that we now reached a point where we need new concepts and take a fresh look to master the new challenges.
His motivation for these statements remained unclear to me for the rest of the day, and also triggered some discussion amongst the attendees, until in the evening, during the “Open House” at ThoughtWorks, the “Agile Community of Practice” of the Project Management Instituts (PMI) was founded. There the same tune was sung: classical project management could offer techniques that could be beneficial for large or critical projects, but blended with agile values and practices. Since up to now the PMI and the Agile Alliance were rather located on different sides, I now consider the keynote as a try to lay out the way into the future, to make it possible for both organizations to come together.
Practically “Chrossing the Chasm” from Project-level to Enterprise Adoption, by Ahmed Sidky and Chris Sterling (pdf)
In the next session, I was hoping for tools and ideas on how to introduce Agile in enterprises. The presentation was well done and I got a lot of ideas from it. All of you who could not attend, do not despair. All attendees received a copy of “Becoming Agile in an imperfect World” by Greg Smith and Ahmed Sidky bekommen. Just read chapter 23.3 “Next Steps”, it more or less covers exactly what was presented. My take-away was, that it can be helpful when introducing Agile to map actions that should be implemented in a matrix, and adress them step by step, starting from actions to enhance the collaboration to actions that lead to encompassing embracement of agile practices in the whole enterprise. Doing that, it is important to note, that you should not finish one level, until you start with the next one, but you should sweep diagonally through the matrix.
XP: My Greatest Misses 2000 – 2009, by J. B. Rainsberger
Apparently, this session is about learnings and consequences, that J. B. Rainsberger drew personally from his greates failures. The key message was to enhance the awareness that failures in communication that are the underlying reason for most problems. He presented the Satir Interaction Model to debug communications, first in retrospect then with ongoing practice while the conversation is still ongoing. At the beginning of the session I was hoping for more interaction, since we were asked to build a circle in the corner of the room, but in the end, J. B. Rainsberger was talking for 90 minutes continuously. Nevertheless I found the session helpful in that respect that one of the core values of the Agile Manifesto is that individuals and interactions are more important that processes and tools. Yet many trainings and coaches focus only or mostly on teaching the right processes and tools, and do not educate on how to communicate better.
User Stories for Agile Requirements, by Mike Cohn
Not much new here, but it was interesting to get the concepts explained by Mike Cohn himself, including the possibility to get answers to concrete questions. Especially the relation between epics, themes and user stories is now a lot clearer to me (hopefully). My mental domain model now looks like this: There are only user stories. An epic is just a label for a large user story, without making any assumption about what large means in that context, except that an epic is too large to be implemented in one iteration. A theme is a collection of user stories. Since an epic also is a user story, a theme can as well group regular user stories as well as epics.
What are the characteristics of a good user story? It should fulfill the INVEST-principle: Be Independant, Negotiable, Valuable, Estimatable, Small and Testable. In the end user stories were set apart from use-cases and IEEE requirements (“A system shall …”), needless to say that user stories are the way to go.
ThoughtWorks Open House
In the evening, ThoughtWorks invited to an Open House. Thanks for the possibility to visit your offices and the great party. With food and drinks there were good discussions evolving at various, well prepared stations. For example there was the oldest continuous integration server worldwide, at least that was claimed by Martin Fowler during the opening speech. A funny item, at the pair programming station, were the Devil Duckies. “Rubberducking” is a technique from pair programming when you are lacking somebody to pair with, just explain everything to your rubberduck. Already Ernie knew what they were good for.