“Agila Sverige” a success!

We’re back from the first real agile conference in Sweden, “Agila Sverige 2008”. There have been a couple of other conferences, of course. Some of them with Responsive as sponsors. But this was a conference arranged by the non-profit organisation “Agile Sweden”. It was mimicing the format from “Smidig 2007″,  lightning talks before lunch, and open space in the afternoon.

Andreas and me had two talks each. They seemed all to be well received. Both of my talks where listed on more than one sticky note voting for best lightning talk. So that was a personal success.

It was also a success as a conference. It was so full of inspiring talks, interesting people to talk to, some of them whom I only had had mailing list exchanges with. Nice to meet them face to face. Many of them also people on the “Computer Sweden Top List of Developers”, numbers 12, 30, 44, 49, 51, 53, so sometimes even CS is right…

But the big success was that everybody contributed. Thank you everybody!

My biggest insight was that “10 minutes is enough, you can say everything you want in 10 minutes”. So maybe Agile 2008 in Toronto will be a bore, all those 90 minute ramblings…

Agile isn’t about trust…

Many people have said that “Agile is all about trust”, and I have sort of agreed. Up till recently. A collegue and me had a lunch conversation with Mary Poppendieck at XP2006 in Oulu. Mary talked a lot about the relation Toyota had built with their sub-contractors, how it was all trust, aligning sub-contractors goals with Toyotas and not pressuring the sub-contractors to minimize their prices, no matter what. Instead Toyota promised that if the sub-contractor could not meet the required price levels, Toyota would put people and knowledge into helping the sub-contractor reach that level. And, I suppose, the sub-contractor had similarly promised to make any changes to their operation to reach the level.

Such trust is of course the goal also of agile practices, responsible development and, of course, any other type of business relation. But us agile people can not start such a relation by saying “You’ll have to trust me…”

The software industry has burned those bridges far too many times already. “Well, we’ll try a more structured way to programming…”, “Ok, so that did not work, but trust us now, we have come up with this this object orientation…”, “Hmm, we understand that programming isn’t everything, so trust on this process and quality thing we’ve got going…” No, it is us agile people that have to interface with the “traditional world” first. They will never come to us just because we say that we can be trusted. We must find ways to prove, in real world combat, that there finally are ways to build a trust relation with a developing organisation.

http://www.dsdm.org/timebox/issue32/DSDM&Scrum.asp

http://codebetter.com/blogs/gregyoung/archive/2006/07/07/147179.aspx

Assert-first, Backwards directed, Completion assisted Coding

Testdriven development, TDD, is a well-known technique to be able to focus on the tiny next step of specific functionality to implement. My experience from watching a number of coders in our Dojo’s, and from my own work, is that even though focusing on the test is the idea, it is easy to get side-tracked. All the little details that need to be set up before arriving at the assert statement at the end of the test are distracting. Instead of focusing on the feature the coder starts thinking about which variables are needed, their names, are there any constant values, which handy functions do we need to write. This sequential mode of coding is particularly obvious in more inexperienced programmers and splits the focus. Trying to keep many details in your head at the same time as trying to maintain the direction of the test is hard.

I’m a mediocre programmer and I have a hard time keeping all the details in my head. I need help to focus on what is to be achieved. TDD has been a tremendous help and is my safety net. But to get one step further I have started to use a technique, or rather coding style, that starts with writing the assert-statement first. Yes, just the assert. This helps me think about what the test should actually test before I think about how to set up the test. Let’s call that “Assert-first coding”.

In the same way as for the assert statement in the test, you can start with the end result in the production code. E.g. the return statement in a function is the required goal. Once the return statement is in place we can think about, and implement, what is required to get statement to compile. Step by step we can work our way backwards until we have the complete function. Let’s call that “Backwards directed coding”.

Espescially in typed languages and with modern IDE:s like Eclipse, it is possible the use the Code Completion and Quick Fix features to quickly and easily fill in the gaps and create the pre-requisites to get the assert or return statement to a runnable state. Let’s call that “Completion assisted coding”.

If you combine these techniques you get a style that could be called “Assert-first, Backwards directed Completion assisted Coding”, ABC;-) Thanks, Joakim Holm for the name. (I initially called it “ACBC”.)

I’ll get back with some screen captures to show what I mean.

Evolution

Me and one of my current work collegues had an interesting lunch discussion the other week. He had just read one of Richard Dawkins books and we talked about the creationism and its flaws but also the style in which he argues for his view. This lead us to the development of systems and software and how that actually could be seen as evolution. Erik then formulated the following insight:

Evolution is superior to intelligent design.

Exchanging evolution for development and intelligent design for big design up-front gives a lot of insight on the natural connection between Darwinism and Agile.

Why can Agile only apply to Software Development?

Maybe it is just me, but it seems that it is difficult to get the notion across that Agile is not limited to development of software. In Agile communities people seem to be extremely focused on development of software, preferably a web application.

I have always worked in ways which are Agile in value, mechanisms and effect. But they are applicable to development of anything, from systems including hardware to businesses and enterprises as a whole.

When I met Ken Schwaber in September 2007 we talked about his new book, “Scrum and the Enterprise”. I immediately recognized some of the patterns he seemed to paint. Or maybe the patterns matched what I had been looking for.

However, Ken seems to have had the same problem that I seem to face, when I talk to agilists about a broader perspective of Agile. Or maybe that is “out of scope” of Agile…

“I need a pen!”

“Do you have a pen?” … After a few minutes the answer is “Sorry, no.” What if the question would have been “Do you have something to draw with?”. Maybe a pencil, or chalk could have been found. And better yet, “I need to draw. Do you have a pen?” This signals not only the need, but also a prefered set of properties on the solution. These properties are not requirements, but can still be used as input.

Does your requirements process work like this? Or do you have “Must Have”, “Could Have” and “Nice to Have”? It is the need, and the implied and fuzzy priorities, that is the essential part of agile requirements management work. These are seldom articulated in standard requirements mangement processes.

Project Models Overview

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”

Agile Practices Cross-Reference

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.

Hosting Open Space sessions at Scrum Gathering

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.

Agile Languages?

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.