On the mailing list of Agile Sweden there was recently a long thread on models for life cycle approach to software development and the Agile community received some critique for maybe not having tackled this view, and of course the favourite topic of “project” was raised. The rest of this post is a translation, with some minor edits, of a post that I did to that mailing list, where I tried to summarize my views on “projects”. This was among other things inspired by a blog by James Shore where he described his way of managing the incorrect use of the term by the rest of the world.
I think the rigid command and control mentality evident in many of models and thinking of the last few decades stems from an increasing suspicion towards larger and larger projects with continuously increasing complexity. And rightly so. As we (the engineering and technology community) have become masters of the current technology, we have tackled even more complicated and challenging projects, and of course the amount of “failures” has grown, or at least the economic impact of the failures. The natural reaction is to try to control everything down to every little detail, thinking that detailed control leads to overall control. The problem is of course that this has been the wrong solution to the problem.
Continue reading “Project Models Overview”
Blogging is about sharing so I’ll share a blog from James Shore with an excellent table of Agile Practices across XP1, XP2 and Scrum (too bad no other models where represented, but Somebody Else should maybe do that…). The table is here.
All of us at Responsive attended the Scrum Gathering 2007 in London. As usual it is most interesting, pleaseant and informative to attend these international conferences. Although the organisers was very explicit in making the Gathering more of a social even, it was still very much of a conference, at least for the two first days (not counting the course days). They where so filled with tutorials and other interesting presentations that it was almost possible to choose, let alone make time to talk to people in the short breaks. I would really like the next conference I attend to actually force people to talk to each other during the conference.
Fortunately the third day (Friday) was totally devoted to Open Space, a form that I enjoy very much. This time I hosted two sessions, “How to find Product Owners” and “Enterprise Scrum and Large-Scale Systems Development”. The latter I co-hosted with Henrik Kniberg, who was confused about what Ken Schwaber actually ment in his new book (“Scrum and the Enterprise”).
My take was really not a response or defence to Ken’s Enterprise thoughts, but rather a presentation of some thoughts that I have carried for a long time on how to scale Agile, Iterative and Incremental development to the large scale systems of systems domain. It turned out that these two topics was not exactly compatible so a part of the session broke out to create a concrete example, while the other part continued with more theoretical discussions and comparisons.
My biggest insight from that session was, again, that there are more flavours to development than any single person can really have concrete experience with. Many agile people I meet at conferences seem to have extensive experience with lightweight web or application development, but those with the most questions are usually from the “harder” part of the spectrum, like military, safety, financial or security development. So, I will have to remember to present the concrete problem that “my model” is trying to solve, before engaging in a discussion.
Occassionally there is discussion about if computer languages can be agile, and if so, which. I belong to the group of people that think that it is only people that can be agile, and it is more a feeling than a matter of practices and techniques. So, of course there are no agile languages!
But today I listened to an Agile Toolkit podcast with Dave Thomas (“PragDave”) talking about different topics with Bob Payne. When Dave pointed out that programmers really need to learn a multitude of programming languages, and gave some examples, my thoughts wandered back to my language and compiler designer days. And suddenly I realized that there actually are agile languages. All the lazy-evaluating, functional languages are agile, or at least follows one of the most important agile principles, YAGNI. They do not compute anything that is not absolutely necessary, and when necessary, only computes exactly what is needed, with precision and timely delivery.