Another discovery at ACCU conference "Bicycle repair workshop"

Something else I discovered at the ACCU conference: Bicycle Repair Workshop.  Should I name to originator?  Or should I let her live in quite anonymity?  Perhaps I should actually seek permission to talk about this here, but then was it not Picasso who said “great artists steal.”  (No I did ask permission.)

First the name: its a straight take from Monty Python.

What it is, is a forum where software developers at the company can gather and talk about the problems they are currently encountering.  The originator envisaged a forum for people to talk about process issues, and specifically Agile practices but its free form enough to let people take in what they want.

The workshop takes up an hour or so on a regular basis, I can’t recall it it is weekly, bi-weekly.  There is a bit of fun (cakes supplied) and people turn up only if they have something to contribute – so a self selecting group.

Like the book groups and Tech-Talks that I’ve created in the past the forum gives people the opportunity to talk about the issues they face.  By exposing, explaining and naming the problem/issue/challenge/opportunity it becomes more manageable.  By explaining it people are forced to make some sense of it to themselves and then to other people.  And when other people see it they can help.

In one of his books Gerry Weinberg (Secrets of Consulting I think) compared problems in companies to moss.  In the dark, moss grows and becomes bigger.  Exposed to light moss dies.  Problems are the same, when you hide them they become worse, expose them and it becomes easier to deal with.

I see this happening when people gather in a pub or coffee bar, or stand around the water cooler and moan about things in their work place.  They know what is wrong but they feel helpless to act.  So bar and water cooler conversations don’t result in much action.  Often these problems don’t get talked about in official forums either:

• because these problems shouldn’t exist, e.g. the according to the official process manual these things shouldn’t happen


• because office politics gets in the way, e.g. everyone knows that X needs to change but nobody feels they can say it


• because somethings we can’t talk about, e.g. Fred under performs and needs to be let go


• because solving the problem needs resources and we all know the company won’t spend money


• because we are embarrassed to admit to our own problems

The advantage of the semi-official forum, like Bicycle Repair Workshops and book groups is that people are freed of these constrains and can talk more freely.  For managers this posses a problem: too much support and involvement with the forum will make it official and kill it, too little support and it will turn into another moaning shop and nothing will happen.

By creating a forum people are allowed to talk about a problem and expose it to the light.  The advantage of the Bicycle Repair Workshop is that it is directly asking for and discussing these issues.  I occasionally facilitated a Tech Talk into such a forum, and the books we studied in book group lead to discussions about problems bit I never tackled the issues head on, on a regular basis.

Of course it mights be possible to have too many forums.  All of these activities take time and commitment.  A company running bicycle repair workshops, book groups, Tech Talks and what ever else may over tax people.

These three types of forum share another thing in common.  They can be created through bottom-up action.  You don’t need to be a manager to create them, you can just do it.

On the other hand, if you are a manager then then can create other types of forums. I’m working with a company now to help them revise their development process and become more Agile.  One of these things I’m doing it running twice monthly improvement meetings, kind of reverse-retrospectives.  These are more official so have a different flavour.

In all these cases the real problem is turning information and learning into action.

Other blogs on ACCU conference

More stories from the ACCU conference at:

• Jez Higgins


• Russel Winder

I am sure there are other ACCU bloggers so if anyone knows them please let me know.

 

 

Failures in Agile process?

One of the questions that was posed at ACCU conference was “What are the downsides of Agile development?” – and “What does Agile failure look like?”

I have tried to answer the first question before but failed myself.  One downside is that the Product Owner role – typically filled by a Business Analyst, Product Manager, Customer or other proxy-customer – is given an immense work load.  This is a subject James Noble has done some work on.

What happens is that Product Owners have to keep doing their original job and service the needs of an Agile team.  As the Agile team becomes more productive they ask more and more of the owner.  Consequently the owner gets maxed out and themselves becomes unproductive.

However when I thought about this I don’t think the failure is a failure of Agile, I think it is a failure of the business.  Put it this way: for years “the business” has been complaining that software teams do not deliver what they want.  Now along comes Agile and says “we will deliver exactly what you want” but “you need to tell us exactly what you want.” 

It is no longer enough to set half a dozen developers working on a problem and expect them to come up with the right thing.  If customers want what they ask for then they need to tell the developers exactly what they want in detail.

The second question, “What does Agile failure look like?” is hard to answer because we don’t have many case studies of failed projects.  This isn’t just true of Agile projects, it is true of many IT projects.  Companies don’t like to talk about failure. 

Still I can see several failure modes for Agile:

• Teams fall back to the old way of doing things: I’ve only heard about this not seen it myself.  Typically it occurs when you bring in a lot of consultants to make your team and process Agile.  Things work when the consultants are there but when they leave teams fall back to the old way of doing things.  Unit test break and aren’t fixed, planning meeting are missed, quality slips and deadlines are missed.  The presence of consultants gives the team a backbone but knowledge is not really transfered to the existing team.


• Failure to get management buy in: Agile is often introduced at the bottom of the hierarchy, by developers at the code face.  Eventually there comes a point when managers need to support it or stop it.  This doesn’t happen and the development process is left in a random state.


• Failure to get developer buy in: this occurs when management buy into Agile but developers don’t.  They don’t want to write tests, do code reviews or pair, believe in technology over visual planning, etc.  Again the process is left in a random state.  I expect to hear more about these types of failure in future.

The common theme here is not that Agile fails, after all IT projects and processes fail all the time so there is nothing new or special here.  Failure of an Agile project looks a lot like the failure of a Waterfall or RUP project.

Rather Agile fails when you fail to see the benefits of the new approach.  So when you do a little bit but not enough to improve quality, improve delivery dates, and make things predictable.

Both questions are good questions and deserve more attention.

Waste from the ACCU conference (Testing)

As I mentioned last time, I came back from the ACCU conference with a bunch of notes and a lot of thoughts.  Recording them in this blog seems like a good way of remembering and sharing these thoughts.

Last time I referred to the Great TDD debate.  At the conference Mary Poppendieck reminded us of the key principle behind TDD and other forms of unit (especially automated) testing when she quoted from one of the original Toyota sources:

• Testing to find defects is waste: the defects should not be there in the first place so any attempt to find them is waste.


• Testing to prevent defects is essential: defects slip in, we should catch them as soon as possible so create systems with tests that prevent defects.

Hopefully it should be obvious were TDD fits it: TDD is there to prevent defects and reduce waste.  However, testing later in the cycle, e.g. system test, is waste and although it may be necessary right now we want to get away from faults, testing and waste.

On the face of it this is bad news for software testers.  If we start testing to prevent waste rather than find waste then they are out of a job.  Well I have three reassuring thoughts for software testers, they will not be unemployed anytime soon because:

• Few organizations can actually implement this principle, some will always need testers.


• We have a lot of code out there where nobody prevented the defeats and therefore needs testing.


• Testing itself is an activity that can add value to products –  as Oracle considered last year.

Also, most of the software test managers I have ever worked with have been keen to point out that they would rather conduct Quality Assurance than Test.  Too often these activities are lumped together but when you think about it they are very different.

So, in the short term testers have plenty of work, in the long term their future is in quality assurance – a more value add activity.

Now at this point a lot of people tell me I’m an idealist.  After all, everyone knows software is buggy, has always been buggy, and always will be buggy.  I remember being taught at University how every piece of software contained an infinite number of bugs.

I asked Mary Poppendieck about this, her answer was basically: you get what you expect, if you expect to get bugs then you will.

Well, maybe I am an idealist.  But what is wrong with wanting software without bugs?  What is wrong with setting my sights higher?

Back from the 2007 ACCU conference

I got back yesterday from the 2007 ACCU Conference.  Once again this was a great conference.  Lots of good stuff on Agile and Lean (Mary and Tom Poppendieck delivered a keynote), software management, programming in general, Java, C# and C++. 

I mainly kept myself to the management and agile sessions.  Also I was involved with a lot of ACCU business type stuff occurring around the conference.  It is about the time when all the key players in the ACCU are in the same place and a lot of association business gets done.  As well as delivering my own session and taking the stage with Mark Shuttleworth and Mark Poppendieck I was in meetings about the ACCU journals, growing membership, conference organising and a host of discussions about the association.

Over the next few blog entries I’ll try and debrief myself and highlight the things I feel I learnt and need to remember.  My comments from this time last year still stand, the best speakers are no necessarily the ones you expect them to be.  (Apologies for that blog entry, its one of the ones with formatting problems.)

Right now here are a few bullet points.

I met three people who are separately working on projects that compile the same code base to Java and C#.  These people have the code in one language and have some pre-processor step which makes the syntactic modifications so it can compile for the other.  Is this a trend?  Will we one day have Java# ?

Ed Sykes and Jan-Klass Kollhof did a really good session.  They set out to produce a distributed algorithm using Python and JavaScript in web browsers.  They just about succeeded but actually their session was far more interesting for what it said about systems with emergent behaviours.  They also took a stab at futurology and suggested Web 4.0 Distributed Computing.  You heard it here first!

The great Test Driven Development debate rumbled on. Well, when I say debate it is a bit one sided.  There are a few people who think TDD is not a good practice then there are the vast majority of people who have tried it think it is a good practise that improve quality. 

Mary Poppendieck presented some figures from Mike Cohen’s book Agile Estimating and Planning.  Before introducing TDD Cohen’s company had 10 faults per 1000 lines of code, after 3 months of TDD this had fallen to 3 per 1000 lines.

For me this debate is a little like the Black Adder scene were the Captain (Tom Baker) says to Black Adder (Rowan Atkinson):

“Crew? Opinion is divided on the matter, all the other captains say you need a crew and I say you don’t”.

Gail Ollis did a good session on Advocating Agility, one of her first slides quoted the start of A.A.Milne’s Winnie the Pooh:

“HERE is Edward Bear, coming downstairs now, bump, bump,
bump, on the back of his head, behind Christopher Robin. It is,
as far as  he  knows,  the  only  way of coming downstairs, but
sometimes he feels that there really is another way, if only he
could stop bumping for a moment and think of it.”

Gail had spotted the great sentiment expressed here: we do painful things because we simply don’t know how else we might do them and don’t take the time to find out.  I left intending to use this quote myself. 

In looking for this quote on the web just now I seen that neither Gail or myself is the first to spot this, its all over the place and often associated with change.

OK, thats a first stab at debriefing the conference, over the next few entries I’ll write more.

Software Strategy

In this blog I keep coming back to same interests:

• Software application development: specifically the use of Agile or Lean techniques to improve the process.


• The link between IT and business strategy.


• Opportunities to make better products.


• How improving our learning can improve our application development, IT strategy and create better products.

Well I am please to announce that I’ve decided to make these passions into a full time job.  I have created a new company to help organizations with exactly these issues.

Software Strategy will help organization improve their learning, improve their strategy and improve the execution of strategy.

Specifically Software Strategy will help organizations deliver the software application which are necessary to delivery their strategy.  Unique software applications have the ability to help companies succeed.  Either because they sell the application itself or because the application allows the company to better deliver some product or service.

For more information see the Software Strategy website.  The company already has a full order book and several interesting prospect in the pipeline.

Retrospectives need a learning culture

I attended a project retrospectives training session last week.  Although I’ve run quite a few retrospectives over the years I’ve never been trained in them.  My guide has been Norm Kerth’s Project Retrospectives book and a whole bunch of ideas I’ve picked up over the years.

This training session was organised and run by Rachel Davies and Diana Larson.  It drew on Diana’s new book Agile Retrospectives. 

Although the book and the training is aimed at Agile practitioners it could be used by other teams – its just that Agile teams are more likely to do this stuff.

The world outside of software development is also catching onto retrospectives.  In part this is thanks to the US Army and Marines who call them After Action Reviews (AAR).  Now they have a macho name and the backing of some generals they seem to be cropping up all over the place.

That said, I still think Retrospectives – or AAR to give them a more fashionable name – are still more talked about then practised.  The training session gave me an opportunity to reflect on this paradox (as well as learning some new techniques and improving my facilitation style.)

So why is it retrospectives get a lot of talk and little action?

There seem to be three basic failure modes.  First is retrospectives that don’t happen.  Usually the reason given is lack of time.  However I think this only an excuse to hide behind.  When people want to do something they do it, if something is important time is made for it.  Conversely when something is low priority or someone doesn’t really want to do it then there is not enough time.  We are all busy people, lack of time really means “is not a priority for me.”

I think one of the reasons people don’t want to do retrospectives is because they are scared of what might come out of it.  Individuals could be criticised, companies could be found wanting or someone may say something they are not supposed to say. 

Retrospectives expose the lie that your boss/manager/leader knows best.  By definition retrospectives are about asking teams what they can do better.  Traditionally we are brought up to expect that someone in authority, someone with a “big brain”, knows best.  So retrospectives can be threatening to managers who feel they are loosing some power.

Which brings us to the second common failure: ineffective results.  Simple formulaic retrospectives, perhaps they simply ask “What do we do right?  What do we do wrong?” and perhaps they limit the whole thing to an hour, and perhaps the team leader or project manager acts as facilitators.

Such retrospectives are unlikely to uncover deep thoughts because they are not asking the questions that will cause people to reflect deeply about the whole project.  Having a authority figure lead the retrospective will also cut off reflection, by leading this person is exercising their authority and sending a clear message “I am still in charge.”

Finally, the third failure mode of retrospectives is: Lack of action.  Things the team decide to do aren’t acted on.  This is actually closely related to the first two.  If it is hard to find the time for a retrospective do you have the time to make the change?  More likely you are risk averse.

And if the authority figure isn’t open themselves then they are not going to be fully behind the change.  This will be clear to anyone tasked with making the change.  That is, if anyone can be persuaded to take on the task.

Arie de Geus pointed out in his book The Living Company that when you have more people involved in making a decision it might take longer to actually make the decision but taking action once the decision is made will be quicker.  This is because more people were involved in making the decision.  If a retrospective is half hearted then any decisions will not have wide buy-in so taking action will be a slow process.

So what’s the answer to these problems?

Well I think I’ve realised were I was making my mistake.  Like many other people I’ve been seeing retrospectives in isolation.  As some kind of plug in solution, nicely self-contained.  But they are not, this was the mistake.

I’ve realised that retrospectives need to be embedded in a learning culture.  I used to think they could be one of the early tools to use in creating such a culture, now I realise they are an advanced tool to be brought in once you have the culture in place. 

An organization that does retrospectives is an advanced learning organization.  Most organisations are not learning organisations let alone advanced ones so it is hardly surprising that retrospectives are missing.

When you have such a culture not only do people value learning but it is a priority for them.  They make time for learning events.  They value the results and they take action.

In such a culture people feel less threatened by what might come out of a retrospective because they are accustomed to deep thinking and reflection.  Everyone knows the rules and people are open to insights and change.

In a learning culture managers have already accepted that the team knows best.  They have already changed the view of their role from command-and-control and “boss knows best”.  They define their role more in terms of helping individuals and teams learn and advance.  Neither are they threatened by loss of authority.

Finally, when you have such a culture, when people are not scared or threatened, when everyone appreciates the value of holding a retrospective then change does happen, people do follow through on the action identified in the retrospective.

So, how do we create such an advanced learning organization?  Well, that will have to wait for another blog entry and even my book.  In the meantime, if I can help with a retrospective or creating a learning culture please get in touch.

SPA London: Making BT Agile

The SPA conference is on this week and I’m not there.  SPA is a good conference but being so close to the ACCU conference I need a very good reason to go.  Since I’m not speaking there I’ve skipped it.

The BCS SPA group also holds monthly meetings which I sometimes go along to.  About three weeks ago I went along to a very interesting talk entitles “Large-Scale Agile Application Development”.  In fact the talk was actually about how BT had adopted Agile development techniques.  This was quite a challenge as those who know BT know that it is a very large company, a traditional telco and at one time a nationalised industry.  There could be few more challenging environments into which to introduce Agile.

BT haven’t completed their Agile transition but it seems to be going well.  Fortunately they had high level management backing on their side and all the kind of resources big companies can bring to bear on these problems: training, off-site boot-camps, consultants (mainly from Exoftware) and other resources.

I was particularly impressed by two of their ideas.

First was a plastic credit card like “pledge card.”  I’ve seen these done by political parties in the past but this one was for “BT Core Agile Delivery Practises.”  On one side was the Agile manifesto and on the other was BT’s core practises:

• Customer collaboration


• User stories


• Iterative development


• Automated testing


• Continuous integration

The card strikes me as good because a) it was a constant reminder of the practises, b) it was very corporate so endorsed the idea that the company wanted this to happen.

The second idea was a pre-printed task card with the main fields a developer would use.  I’ve seen index cards put through a laser printer before but this was more structured.  It contained fields to help describe the work task, the priority and the acceptance criteria.  Again good for re-enforcing the corporate message (“This is what we want”) and a reminder to teams as to what they needed to do.  My only criticism might be that for such a small card it had a lot of fields to complete.

BT seems to have invested a lot in this programme.  They had sent lots of people on training courses and held lots of off-site meetings and training.

They also spent a lot of time and money using coaching techniques.  In fact they used pair-coaching with an experienced coach working with a new coach to help train the coach.  To my mind this approach vindicates the coaching approach and shows how powerful it can be.

That say, it does seem the coaching model in use was very much drawn from the Agile coaching model rather than the model used by business coaches.  The difference is that the Agile model is much more directive about what needs doing while the business model is much more open.  Both have their place, I just wish Agile coaches were more aware of the other model and how it can help.

 

Application development is getting better

As regular readers may have noticed the state of the application development industry has driven me to despair recently (27 January).  But it appears I am wrong.

According to this report of a report in the Software Development Times things are getting.  The report in question – that is the one with the data, not the report of the report (don’t you just love journalists?) – is a new report from the Standish Group.  These are the people who produced the Chaos report in 1994.

You can read the 1994 report for free but the 2007 one is going to cost you, prices seem to start at $500.  I’d love to read the report but I can’t justify $500 right now.

Anyway, Software Development Times already offers the key findings:

• 35% of projects started in 2006 are considered successes – up from 16.2% 12 years ago.


• Project failures are down to 19% in 2006 compared to over 31% in 1994.

(For the moment we will accept the definitions of success and failure.)

And the reason for this change?  Well I’m sure the $500 report gives many, personally my money is on the move to Agile development methods.  The SD Times gives us three:

• Iterative development


• Better Project management


• Web infrastructure

Iterative development fits with my hypothesis.  Better project management, well we’d have to know whether they mean more project managers using Agile like techniques or whether PRINCE2 is finally about to save the world.  No prizes for guessing what I think.

And the web infrastructure?  Well, it might just be that technology can make a difference.

One more finding from the report.

In 1994 the value of software was 25c (US cents) for each $1 spent on the software, this has risen to 59c per dollar.  (Thats if I’m reading the statistic correctly, the sentence containing it is a bit of a mouthful, someone please correct me if I’m wrong.  But lets assume I’ve got it right…)

Think about that: Software is worth less than it cost to develop.

Most of the money spent developing application is still wasted, we would be better off keeping the money.  That is frightening.  But it is completely compatible with something I wrote about in December (17 December).

Companies that understand IT, and in this case application development reap the benefits.  Those that don’t understand don’t get the benefit.  The days when IT could be left to the IT department and everyone else could bury their head in the sand are gone.  If you don’t want to be bothered with IT then just don’t do it, save your money.  If you have to do it then do it properly.

Book Review: The Elegant Solution

I have just finished reading the The Elegant Solution by Matthew E. May.  I think I’m going to have to give up reading serious books to do with software development, business and change until my own book is finished.  Progress has been far quicker than I expected and the end is now in sight.  Problem is when I read a book that comes anywhere close to my subject things get confusing.

So to The Elegant Solution, subtitled “Toyota’s Formula for Mastering Innovation.”  The author mainly considers product innovation although the same things are true about process and practise innovation.  In effect he is talking about what Michael Kennedy calls  “Lean Product Development” or “Knowledge based product development” (Product Development for the Lean Enterprise).  Its about the application of Toyota’s lean thinking to the development of products.

Although May tries to be practical the book is still quite conceptual.  There are big bold ideas like “Learn to see” and “Master the tension.”  While these are backed up with stories (mainly from Toyota but a few other places too) most of the practicalities are left to the reader.  Its a good book for creating aspirations.

I also found that the book overlapped with my own thinking and the draft of my book.  I found myself thinking at one point “He’s said it!  I have nothing original to say!”  Actually I came to realise there is a difference – it is worth me continuing – and that his work just further validates my own thinking.  In particular May’s emphasis on learning is spot on.

I’ll recommend this book, its worth reading but I’m not completely happy with it.  I found it annoying in many places.  For a start is is very American – ironic when it is mainly about a Japanese company.  There are some points were I don’t actually understand what he is saying because he refers to figures from American history, or sporting metaphor's.  Neither do I have car-culture so some of that escaped me too.  As the book went on this annoyed me more and more, this is not a book for the international market.

While the book is short on references it is short in total.  Had the author included more references, expanded on his thinking and skipped the American turn of phrase it probably would have been a lot longer – and I would have complained about that too!

At the start of the book May sets out to define The Elegant Solution (TES).  He gives some examples but I’m not convinced, they can be a little subjective.  In fact I found myself thinking of Christopher Alexander and Quality Without the Name (QWAN – see The Timeless Way of Building) – more recently called Wholeness.

QWAN is the underpinning of Alexander’s Pattern theory.  The more I read May’s work the more similarities I saw between the two.   QWAN and TES are described in similar terms and are, to my mind at least, similarly subjective – although Alexander would claim QWAN is objective and I suspect May would claim the same for TES.

The similarities don’t stop there.  Alexander created Patterns to help create QWAN.  Patterns describe a problem, a set of forces and a solution.  May gives a set of practices describe a problem, a cause and a solution.

I think May is very close to Alexander and Patterns.  I don’t know if he has read any Alexander or has made the connection himself.  I suspect not but his references section is sadly lacking – he has one but its not a complete list of references or influential work which is a shame.

As a book The Elegant Solution also reminds me of Tom Peter's book Re-imagine! Both try to enthuse people to take a grip on the world themselves and step beyond the normal bounds.  However there is one big difference.  May’s book is all about incremental change and improvement.  But Peter’s rejects incremental change, he wants radical change. He sees small improvements (the type typically brought about by Lean) as preventing radical change.  Why change a little when you can change a lot?

This is a big divide.  Personally I come down on the incremental change side of the argument.  But – and this is a big but – incremental change has to be combined with a constant desire to do better and a systems view of the world so you are not sub-optimising.  This is an argument I’ve been making for a while, I probably picked it up from Peter Senge’s The Fifth Discipline, and its the same argument May makes.

Finally, I’m getting a little fed up of reading about Toyota.  I know, this is partly my own fault but I want to know were the other example's of Lean are?  I know a few, like Dell and Heathrow Terminal 5 but surely there are more still?  And when will thinking advance beyond Toyota and Lean?  What is next?

Perhaps what makes Toyota different is not so much Lean, or learning, or knowledge but simply a willingness to deal with problems and to grasp opportunities.  Maybe the secret is just that they do things.