Agile seminar. Kent Beck and Mary Poppendieck, London June 2005

I'm a bit late on writing this up, so have probably forgotten some of it by now….On the 24th June I went to see a seminar from Exoftware.

Kent Beck

"Accountability and Developer Testing" Kent Beck, Three Rivers Institute.

In his talk, Kent will present a high level overview on the business value of developer accountability and a solid testing environment.

I wanted to see Kent Beck due to his seminal textbook eXtreme Programming eXplained and the fact that he wrote JUnit. Beck says that the 2nd edition of XP Xplained has been greatly refactored and that he has changed his approach in trying to get his ideas adopted. Rather than saying, "this is how you must develop" he says, "here are some things that worked for me, maybe you can adopt and adapt them".

His latest focus is on accountability. Quality is an instantaneous measure taken at a point in time. We have QA teams that test a finished piece of software until it is 'of a level of quality that it can be released'. We should be more interested in health. In a human being, quality would be like measuring your pulse rate, but health would be making you run on a treadmill and seeing how quickly your pulse can return to rest. In other words, health is the measurement of performance under stress.

"The shape of the software matches the shape of the team".

A large bloated team will produce a large bloated product and vice versa. In order to build great products you must concentrate on building a great team. Using the right tools and processes can enable a team to be flexible and accountable. Accountability is about being able to account for one's actions, this is not about being responsible for them for ever, but about being able to demonstrate what it is you have done. Tools like JUnit foster a climate of being able to demonstrate that a piece of software works, and in the action of doing so a Developer becomes more responsible and more accurate.

Beck posed the rhetorical question, > "What if you published all your test results on your companies home page" to which the answer is probably either, "everyone would start forging the results" or "you'd make damn sure that they all pass".

Lean Software Development Mary Poppendieck

"Can the efficiencies and cost savings enjoyed by the manufacturing industry through lean and TQM manufacturing practices be applied to the software industry? In one word: absolutely! In this talk, Mary Poppendieck will take attendees through the benefits of lean software development and how to apply the practices to projects."

I didn't know what to expect from Mary Poppendieck, but I was pleasantly surprised. She talked about Just-in-Time workflow in manufacturing and how this could be translated to software development and made a lot of sense.

The first target in manufacturing is to reduce waste. Waste is seen in work in progress, so by increasing release cycles it is reduced. As Mary says on he website, "80% of the value of most systems is delivered by 20% of the features, and up to two-thirds of the features of most systems are rarely, if ever, used. The easiest way to develop better software faster is to Write Less Code. If we would stop spending time specifying, designing, developing, testing, documenting and maintaining features that are not going to prove particularly useful to our customers, we could focus on providing them with a significant competitive advantage." This statement should be music to the ears of both Developers and Company Owners.

Traditional project management tends to focus on 'resource utilisation', but what happens when you maximise the number of cars on a road? You get a traffic jam. Queueing theory looks at increasing the pulse rate through the workflow, and turning it into a pull process. This makes it more flexible to variability.

Another thing is measurement. An old project management adage is that "you can't manage what you don't measure", but when we find that the measure isn't working we normally go into more detail, whereas we should really do the opposite and go up a level. E.g. instead of measuring 'number of errors' maybe you should measure 'customer satisfaction'.

events agile
It's All In The Game blog (c) 2005-16 by Jez Nicholson