Read a Book

I've just read the excellent "Top 10 Team Practices" post in the Leading Answers blog.

I am a bit worried about leaders who "do not get the time they want or need to read about these topics." What are they doing? Do they really not have three or four hours and a few pounds (or dollars) to step back from what they're doing and get a different perspective? The best you can hope for is that they're too busy taking Agile leadership courses ;-)

Agile - Keeping the Conversation Going

When I was a student of philosophy, way back in the last millennium, I was often told by my tutors that all modern academic philosophy is really just a set of footnotes to the works of Plato.

I was recently reading Plato's disapproving comments on the dangerous new information technology of his day - writing - and suddenly realised that maybe Agile is doing a bit of Plato footnoting of its own.

"The fact is that this invention [writing] will produce forgetfulness in the souls of those who have learned it. They will not need to exercise their memories, being able to rely on what is written, calling things to mind no longer from within themselves by their own unaided powers, but under the stimulus of external marks that are alien to themselves." (Plato, Phaedrus 67-71)

I often think - and say to people who come on our courses - that Agile methods are really about making sure that a bunch of people who have tried to get through life by making "marks that are alien to themselves" - i.e. computer programs, have to talk about what they're doing. Sprint planning, story prioritisation, story estimation, daily meetings, sprint retrospectives, pair programming, all of these are ways of making sure that we're talking about what we're doing and by doing so, hopefully, starting to make sense of it.

I'm also reminded of the words of another wise man, Taiichi Ohno: "Too much information induces us to produce ahead and can also cause a mix-up in sequence ... Eventually, it becomes impossible to make a simple change in the production schedule. In business excess information should be suppressed." (Taiichi Ohno, Toyota Production System, p.50)

There's a limit to what you can talk about. Agile methods (such as time-boxed meetings) use the limits of conversation to suppress excess information as Ohno recommends and keep teams focussed on what's most important right now, for this iteration.

Agile Training in Central London

Introduction to Agile Training in Central London, Wednesday 2nd July 2008

After the success of the course that we ran in March, we are running another training course in central London on Wednesday 2nd July 2008 in association with 01Zero-One. This is the popular and previously well-received course "Crawl Before You Leap".

The course is suitable for anyone who wants to get an introduction to Agile methods and who wants to get a hands-on feel for how it feels to work in an Agile fashion. No programming knowledge is required.

Technical Aspects of Agile - Course in Development

We're thinking of running a one-day, actually possibly a two-day course that covers some of the crucial technical aspects of Agile. We would probably run this through 01 Zero One in central London, where we've already successfully run our introduction to Agile methods course. We would probably offer the course initially to people who are comfortable programming in Java, but we might also offer it for more web-based languages such as Flash, AJAX/Javascript or Ruby on Rails. Of course if any company wanted us to run the course in a particular language, we could talk to them about offering the course them in-house.

Pair Programming. To many people, especially in senior management, pair programming seems completely counter-intuitive. Surely, by getting two people to do the job of one person you're just halving your productivity? A substantial body of research shows quite the opposiste - that pair programming doesn't reduce productivity, but maintains productivity whilst substantially reducing the number of serious defects that are later found in the code. This course would cover the very good reasons for introducing pair programming and how to deal with some of the potential objections. It would also deal with how to start pair programming - what are the do's and don'ts and provide course participants with some hands-on experience of programming with other people.

Test Driven Development. The practice of writing a failing automatic test for each piece of software functionality that is added to a system, together with a script that can run all of these tests has many beneficial effects on the process of software development. This course would give participants experience of writing tests and then coding against them using a well-known testing framework such as JUnit.

Re-factoring. As software development progresses on a project, code gets messy and changes in one place cause unexpected breakages in overs. Re-factoring accepts the reality that code gets messy over time and builds on the advantages of TDD (test-driven development) to allow principled clean up of code. Course participants will be given a chance to clean up the kind of horridly entangled bits of code they might experience and be shown the possible benefits of re-factoring for the ongoing support of the codebase.

But we are already doing Agile!

Really?

Well according to Jeff Sutherland (he that invented Scrum) there is a really good way to find out using a set of 4 questions that he calls the Nokia test:

1. Do you need a complete specification document before you start to build stuff?
Yes: Then you are not doing Agile, you are doing industrial Big Design Upfront making
No: Great - test passed, move to question 2

2. Are you doing time boxed iterative development with each iteration lasting less than 6 weeks?

Yes: Great - test passed, move to question 3
No: Then you are not doing Agile. The most important difference between agile and conventional methods of getting things done is that Agile uses lots of small steps rather than trying to do everything all at once

3. At the end of the iteration do you have working code?

Yes: If you can show this to your customers and get feedback then you have passed the test
No: Then how do you know you are done? If it is not working you can't demo it to your customer and they can't make effective prioritisation decisions

4. Do you have tests to determine that you have finished development tasks?

Yes: Good - you are on the path to Agile enlightenment!
No: You worked so hard but you don't know if you are done! How do you know that changes in the next iteration wont undo all your good work?