On Responsive Development

I read Uncle Bobs blog about him recording a Katacast of Prime Factor kata in Ruby, with music. (His main point, and my own when I speak about TDD and katas, is of course that to become a professional you really need to take your practicing seriously, only then can you excel!)

I recommend a read for any of you coders out there. Then you can visit the Katacast website for some more examples.

Strangely, this much resembled what me and Andreas did at XP2009 on the session that Emilie Bache organised, although without music. I coded and Andreas commented. We had decided on trying for the complete Bowling Kata in Java with Eclipse so we had to do exactly what Uncle Bob said he had to do, practice, practice, practice and optimize, to fit it into the 20 minute slot we got.
Again, like Uncle Bob said, it was great fun! I very much enjoy working these things with Andreas, we seem to complement each other well.

(I seem to have trouble pingbacking other blogs so I’m adding a pingback to a tutorial which is supposed to be monitored. Also pingbacking this post.)

I’m now on the train from Copenhagen to Malmö. This was not planned. Again the flight from Budapest as delayed. This time, again, enough to make me miss my connection at Kastrup. So about every other flight from Budapest is more than 30 minutes late. Maybe they need to fix the root cause…

But this post will be about the way the airline and airport personell handled the situation. Or didn’t…

The flight was scheduled to leave at 17:45. We boarded and as usual we had to wait for something for about 30 minutes. Since there is about 3 hours for transfer in Copenhagen this is often not a problem, so I was calm.

Then they announced a further delay, due to some mixup at the Schengeln boarder. (Schengeln is a EU-regulation easing the requirements on passports etc. for members from countries agreeing to the regulations.)

After another 20 minutes we where asked to disembark, including all handbaggage. There were two busses outside collecting all passangers. The first filled up and then waited for the other to fill up.

The busses drove us about 100 meters to the nearest gate where we waited for 15 minutes in the busses. We were then let out and led through a security check after which everybody had to wait in a small area for about 1,5 hours. Now, I was starting to suspect that not even 3 hours would help. I would probably miss my connection.

There were no speaker announcements or officials stepping forward, only police, customs, airline and airport personell running around and speaking Hungarian to each other.

Finally, we were rounded up and led to the exit. Outside of which there were two busses of course. The first filling up, and then waiting while the other filled up, before driving the 100 meters to the aircraft. There we waited for another 15 minutes in the busses, before boarding, this time only through the front entrance.

The boarding took extra long time, mostly because people did not return to their original seats, probably because they thought they could get off substantibly faster from another seat. This caused many changes of seats during the boarding.

So the aggravation, and the delay, was worsened by personell, and passengers, not keeping the flow.

Finally, after a delay of 3 hours we took off. Before performing the usual security demonstration the stewardess asked if we wanted to know what had happened! Maybe she, and the other officials, would have had less unhappy passengers if they had thought about telling us that much earlier.

It turned out that the mixup was that some people coming from non-Schengeln countries managed to skip security checks. So they had to close down the whole airport and empty all pending aircrafts to make sure that there was no threats. So while we were in the terminal waiting they had checked through the complete plane.

Knowing that the delay was about threats and security would most definitely had made passengers accepting the procedure more readily, instead of just being told what to do.

Powered by Qumana

I’m doing a presentation on a seminar in Jönköping on the topic of “Agile in a Larger Context”. I will focus on the values of agile, the things that are perceived as impossible to handle in an agile way, particular in larger organisations doing complex systems development, and how such a transition can be made anyway.
Anders Olofsson from Combitech is the organizer and Anders Hallqvist from DNV will be presenting on Agile and CMMI. 48 persons registered so far.

Update: around 60 persons finally attended. We started the seminar with the Ball Point Game with four teams of around 15 people. It was much appreciated. Here are my slides: Agile i ett större sammanhang 2009-10-21.

Many organisations strive for excellence, talking about and planning for becoming a Center of Excellence. However, many of those organisations seems to be stuck in a culture of Cost/Benefit analysis.

But noone has become an expert, a top level athlete or world artist by calculating the return on investment on reading a book on a subject, practicing six hours a day or painting picture after picture.

We do these things because, in our heart, we belive it is the right thing to do.

I believe it is the same with excellence, we can only become excellent if we truly believe in the actions we take. Just as a simple example, there probably would never be a framework for automated acceptance testing if you did a cost/benefit analysis before implementing it. It is just to hard to calculate the benefit, the return on that investment. And particularly so if you only consider the current project…

Excellence comes from a burning conviction to become better!

In this blog entry Mike Griffiths summarises some discussions he had with Tony Parrottino, who is a Behavioural Scientist. It is an interesting blog post and Tony’s answers to some of the questions are important clues on how to progress the agile thinking and ways of working.

I have often said that I think “the three questions” (what did I do, what am I going to do, is anything blocking me) are not the best ones. In my view the focus on the daily meeting should be continuous, visible progress, so maybe the most important question is the one about blockage. If we focus on that we can grow a helping culture which is one important component in a fully self-organising, top-notch, team.

I get some support from Tony Parrottino, since he says the three questions are “sub-optimal”. I think Tony is answering the wrong question, though. Because the questions are not put to the team by a manager that wants them to perform. Instead they are the things other team members need to hear to be able to help out.

Tony is much focused on that the one thing we need to manage is behaviour to increase performance of individuals and teams. One of his comments was

trying to remove what you don’t want will not ensure you will get what you do want

But that is in the context of team behaviour, not in terms of obstacles or difficulties. He goes on to talk about “pinpointing” which seems to be a term used to be precise in expressing what you expect your collegues to do and how to behave. To this I can only agree. Focus is one of the most important factors in performance, and you can only focus if you know exactly what is expected.

In larger organistations it seems more difficult to get acceptance for the agile estimation and planning. By agile estimation and planning I mean measuring velocity of a team and using burndowns or other methods to forecast finished stories or functions at the time of the deadline. There are many good places, blogs and books to read about this.

This reluctance is probably related to the larger number of people focused on the number crunching of traditional resource allocation and planning, but also because the size of features are bigger.

Traditionally we have always hoped there was a way to find the “true” and absolute cost of some development early. Usually the thinking goes along the lines of thinking and planning really long and hard. That will never happen… and we know that more thinking will not help. Those that get their initial estimates fairly right is using statistics to adjust them over time to match historical observable data. Some companies actually collect data about the relation between some initial estimate and the “real” number of worked hours. Let’s call this the estimation factor.

This factor is based on statistical, empirical evidence, and includes any and all effects that influence the “real” outcome: de-scoping, requirements creep, features not realized up-front, difference in skills etc. All which are normal effects in any development and should be expected. In any particular case the factor may be off by a mile, but overall it will even itself out. That’s what statistics is about.

However, statistics only work if you measure the same way every time. If you re-estimate in the middle of development, you can’t reliably use the same estimation factor, because you are not in the same position as when you first estimated. You have more knowledge about the actual required functionality, its complexity and some of the work has already been done, possibly with de-scoping and just realized required additions thrown in.

So if you mix and match these numbers and throw in some “converted agile estimate” too, you will get a number which will tell you nothing.

Actually, the estimation factor, if used correctly, is exactly what the team velocity is: a factor between some guestimated effort (points) and some empirical data (points per iteration) that can, if used correctly, help you to forecast future outcome. The estimation factor is on large objects like features and whole departments, the team velocity is on stories and a single team.

I am not a beliver in converting team velocity to hours, and I am sure that planning and follow-up could be extremly simplified (and de-mystified 😉 if some agile techniques where applied. Agile is about making things simpler, not more complicated.

Repeatedly I get the question “What books should I read about Agile?”. Here is a list I have compiled. There are probably more good books, and if you find one, don’t hesitate to recommend it to me.

Agile

• Lean Software Development: An Agile Toolkit, by Tom & Mary Poppendieck.
• Agile Software Development, by Alistair Cockburn.
• Agile Software Development Ecosystems, by Jim Highsmith.
• Scrum and XP from the Trenches, by Henrik Kniberg.

Scrum

• Agile Software Development with Scrum, by Ken Schwaber & Mike Beedle.

XP

• Extreme Programming Explained: Embrace Change, by Kent Beck.
  The first edition is more practical, the second is re-written extensively to show how values fit together with the techniques and practices.
• Planning Extreme Programming, by Kent Beck & Martin Fowler.

Management & Leadership

• Agile and Iterative Development—A Manager’s Guide, by Craig Larman.
• Collaboration Explained : Facilitation Skills for Software Project Leaders, by Jean Tabaka.
• Managing The Design Factory, by Donald Reinertsen.
• Agile Retrospectives: Making Good Teams Great, by Esther Derby & Diana Larsen.
• Peopleware: Productive Projects and Teams , by Tom DeMarco & Tim Lister.

Requirement Management & Modelling

• User Stories Applied: For Agile Software Development, by Mike Cohn.
• Agile modeling: Effective Practices for Extreme Programming and the Unified Process, by Scott Ambler.

Planning

• Agile Estimating and Planning, by Mike Cohn.

TDD/Test/QA

• Agile Testing: A Practical Guide for Testers and Agile Teams, by Lisa Crispin.
• Test Driven: TDD and Acceptance TDD for Java Developers, by Lasse Koskela.
• Test-Driven Development By Example, by Kent Beck.

Programming & Refactoring

• The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt & David Thomas.
• Working Effectively with Legacy Code, by Michael Feathers.
• Refactoring: Improving the Design of Existing Code, by Martin Fowler.
• Refactoring to Patterns, by Joshua Kerievsky.

Lean

• Implementing Lean Software Development: From Concept to Cash, by Mary & Tom Poppendieck.

I don’t consider myself a Toyota/Lean-expert, but there is an interesting saying that I have heard is used within Lean, “Plan Well to Execute Fast”. And that might sound very much like BD/PUF (Big Design/Planning Up-Front, if you didn’t get that…).

But isn’t this exactly what the Agile and Lean techniques are trying to help us with? We plan the days work carefully in the daily meeting, in the iteration planning we plan the content and do the design necessary to execute the stories fast.

I consider the view that you should plan before you do to be embraced by most people. If you do this you can focus on smaller pieces at the time and get more focused and efficient. The parallel with personal productivity techniques like Pomodoro and GTD are, to me, obvious.

“Waterfall” is a, failing, attempt to do the same thing. But it is not always easy (or good) to break down a complete project to tasks small enough that people can focus on them, particularly if you are not knowledgeable in the area (as the case usually is for a specialist in project planning). So “Plan Well” has been become one big plan/design/do-anything-as-long-as-it-is-not-real-work-phase before the real work can start. And for some areas it might still be necessary to do, if you are building a new factory plant for example.

But the trend seems to be clearly visible, that in many areas, the insight is spreading. It is possible, and often even very benefitial, to plan and design, and execute, a much smaller part of the work at a time. More opportunities to do it present themselves if you focus on a small change in the “product” that you are changing, instead of on the task and the “human resource” allocation. There are examples in building construction (all the way back to the early skyscrapers, picture is the steel delivery schedule of Empire State Building, with floors on the vertical axis), road and bridge construction, budgeting as well as in systems- and software development.

Companies and people that will not get this shift will be stuck in “waterfall”, “command and control” and “human resource allocation”, miss out on the financial survival advantages, and, like the dinosaurs, soon become extinct.