Have you ever been offered a “stottie” or a “balm cake” or a “cob”? Have ever been called “Pet” or “Duck” or “Hen” and not known what they meant? Have you ever been confused when someone told you to get on the “side walk” or “pavement”?

The words we use can often be used to identify where we are from. However, those words can make it harder to get where we want to because people do not understand us or have a different understanding of the words we use.

“Backlog” is one such word. It is a word that expresses the IT view of the world. This was fine when Agile was being sold to IT teams. Now that Agile is being sold to business investors, we need a new phrase to describe outstanding work.

Ask someone who has not heard of Agile “What is a backlog?”. They might look up a definition…

“Value of unfulfilled orders, or the number of unprocessed jobs, on a given day. While a backlog indicates the workload that is beyond the production capacity of a department or firm, it also serves as a pointer toward the firm’s future sales revenue and earnings. Also called open order.”

The key is “unfulfilled orders / unprocessed jobs”. They describes the commitments that the IT department has yet to complete. Backlog is a term to describe IT’s relationship with outstanding work. It does not describe how the business view the same things.

Without knowing the name, a business investor might describe the backlog as “A list of things I might invest in that will deliver business value.” Backlog implies commitment and makes no reference to value. This is why I prefer to call the backlog “A portfolio of investment options”.  It is a phrase that business investors I’ve dealt with have responded well to. One that makes their role as an investor clear.

So pet, fancy a stottie and bottle of dog to celebrate our new found understanding?

Last week I was lucky to spend a few days at #ALE2011.

Whilst there, Olaf Lewitz shared a trick he has to close the front door of his house. He follows this process. Open door, Put the keys in the lock, Pull the door closed using the key and Lock the door.

Whenever you pull a door shut behind you, you are making a commitment. If you want to pass back through the door you need an option (key) to get back in. Whenever you pull the door shut, there is the risk you have left your keys inside. Olaf’s process addresses the risk of pulling the door closed whilst your keys are inside.

This simple pattern could be used on adjust (IT) processes to achieve the same effect.

<cheeky>If you implement the pattern, be careful the Lean Tool Heads do not optimise them to remove the waste (or what we call risk management)</cheeky>.

Update: Thank you to Laurent Bossavit for pointing out the “Berlin Key” which enforces this process.

I’m still landing after last week’s #ALE2011 unconference in Berlin. The organisers did an amazing job of hosting a truly memorable event with people from ALL over Europe and even the (very) odd interloper from the U.S.A. ( <- Brian, Another example of taking the piss ).

ALE is short for the “Agile Lean Europe Network”. Network is probably a better term than community for Agile and Lean. A network is formed of nodes (People, Companies) AND the relationships between them. Agile is the learning machine that operates on top of the Agile / Lean network. In order to learn from another node, you need a relationship. If you ask people “What is the opposite of a good relationship”, their obvious response is “a bad relationship”. The correct answer is “No relationship” as you can still learn from a bad relationship. There is no learning from a non-existant relationship. The success of a learning community is due to the relationships within it.

For me, ALE2011 was successful because it facilitated the creation of new relationships and the deepening of existing relationships. This happened in a number of ways, some organised, others spontaneous.

1. I had the opportunity to spend time with people I knew well and people who I now know better.
2. The Conference started with Jon Jagger’s Coding Dojo to get people talking. The message from the start was audience participation.
3. The open space was the only thing running at the time. It did not compete with any other sessions. You could not hide from interaction with your fellow attendees.
4. There was no trade fair activity.
5. Dinner with a Stranger encouraged people to speak to new people.
6. The sessions were not tutorials or workshops but rather quick presentations to inspire conversation in the open space, over dinner and in the bar.
7. No one was SELLING!
8. Lots and lots of hugging. Franck asked if it was German thing, or a British thing which prompted lots of blank looks. Someone said “Its an Agile thing”.
9. Lightening talks provided everyone with an opportunity to take centre stage.
10. The audience could change the programme. The lightening talks were extended by thirty minutes based on a two sentence interaction.
11. Lots of talking points, like the map of Europe with pins, and the Post-It note pictures.
12. Groups ate lunch together in the hotel.
13. The kids and spouse track bought something very special to the atmosphere of the conference. It felt less like work. More friendly somehow.
14. The stars of the conference were the participants rather than the speakers.
15. We had Marcin, Marc, Oana, Franck, Ivana and Olaf to act as emotional glue.

#ALE2011 reminded me of the first two Agile Development Conferences in Salt Lake City back in 2003/2004. I spent some time trying to think of why. I have to thank Brian “The Token American” Marick for helping me see through the noise in my mind. At the most timely moment, Brian mentioned a book in which the purpose of conferences is suggested as a place where “experts can come together to form collaborations” and “people can be energised for the future”.

What made ALE2011 successful were the same things that made ADCv1/2 (Agile20xx v0.1) a success. The expert practitioners had time to talk and form collaborations. Time to learn what people were interested in beyond the stuff they are known for. Time to explore the possible areas of collaboration and whether you want to collaborate. In short, time to form relationships. 

Agile20xx serves two purposes.

• Provide a meeting place for expert practitioners
• A trade fair.

Those engaging in the trade fair do not have the time to renew the relationships or build new ones. Agile20xx does the trade fair well and hopes the practitioners can look after themselves. The reality is that many of the practitioners at Agile20xx are there for the trade fair. Practitioners from Europe, Asia and South America travel all the way to the USA (and submit to invasive search by Homeland Security) to talk to themselves. Something that may not continue now that we now have a place in Europe where we can do the same without the jet lag.

Agile20xx needs to consider whether it only wants to be a trade fair. I hope that the future organisers of Agile20xx learn from ALE2011, otherwise we need to create an Agile Lean Americas Network with ALA20xx as a place where “experts can come together to form collaborations”.

—————————————————————————————————————————————–

This post is dedicated to those who made ALE2011 happen… Alex,  Aleksey, Andrea,  Catia, Christian,Christiane, Eelco, Erik, Franck, Greg, Greg, Ivana, Jaume, Jens, Jule,Ken, Marcin, Marc, Marc, Micheal, Michael, Mike,Monika,Natalia, Nick, Oana, Olaf, Pablo, Sergey, Sven, Will and Wolfgang. ( I stole the list from here )

Thank you Jurgen for lighting the match that set fire to this group.

Special thanks go to Monika and Oana for giving me the opportunity to show I can “respond to change”.

Very special thanks and to Olaf for being the linchpin and showing me a slice of life in West Berlin.

Disclaimer : None of the numbers in the post are researched!

The UK Government contracts out its software development to systems integrators. In order to stay competitive, the system integrators off-shore the software development to places in the world where it is cheaper to hire developer. Places like India, China and Eastern Europe. And quite frankly if they were not driving down the costs, we the British Tax Payers would want to know why.

The reality is that the cost savings of off-shoring are not as mouth-wateringly good as they initially look. The off-shoring argument is simple. A developer cost £50,000 in the UK and only £10,000 in the off-shore location, i.e. An 80% discount. (Made up numbers before anyone asks)

However anyone who has worked with off-shore teams will know that they bring additional overheads.

1. You need two sets of (middle) management. One for both the on-shore and off-shore team.
2. You need more formal processes (additional process overhead).
3. Time zones mean you only have a fraction of the day when both teams are in the office.
4. Small delays creep in due to having to wait for the other team to be available. The delays have a compound effect.
5. There are often inefficiencies in communication due to language.
6. Off-shore companies often have higher levels of staff turnover which means you have a lesser chance of retaining high quality staff and the benefit of gelled teams.
7. More chance of building the wrong thing.

Off-shoring people are smart and they have worked hard to address these issues. The reality is that the savings are not in the 80% ball-park but more likely to be in the 25% – 30% zone. But that is before we include the “building the wrong thing” factor.

The real benefit of off-shoring is liquidity. Access to a greater pool of quality programming talent. Those hiring during the Dot-Com era will remember the days when it was impossible to hire decent developers. I remember times when you had decide on the day whether to hire a Java developer or they would be snapped up by someone else.

For most UK organisations, the economic argumant for off-shoring sort of makes sense. For the UK Government IT, it does NOT make sense. The UK Government gets a 50% discount on hiring developers in the UK. Once this is factored in, the arguments for off-shoring fall apart.

Where does the 50% discount comes from? Easy. Developers in the UK pay income tax and national insurance in the UK. Off shore developers do not pay tax in the UK. In fact, given that the system integrators are mostly US Corporations, it is likely that almost NONE of the investment by UK Government IT will come back as tax revenue.

Its time for UK Government IT to have some tough discussions with the systems integrators so that we can claim our 50% discount.

There is an argument that we do not have enough developers in the UK. Perhaps this will provide the stimulus to invest in IT developer skills in the UK.

Yesterday I had to debug a programme written by a colleague. I realised that the majority of debugging is analysis. Understanding how the code works. As a result, I realised that the debugger was running backwards.

As someone working to work out why there is a problem with the output. Ideally I would like to start with the output and move backward through the execution of the code until I reach the point where the problem occured. The analysis of a bug is similar to analysis in Feature Injection.

For example, I want “A” as an output.

A = B + C

Therefore I need B and C.

B = D * C

C = E + F

D, E & F are all inputs to the system.

To help with analysis of a bug, the debugger should move backward through the execution of the code. I should be able to put a watch on output values and then the debugger should show me when the values are updated. If I start watching A, the debugger should ask me (automatically) show me B & C. When B is updated, it should show the values in D & C.

Currently the debugger runs forward in the direction of execution. As a result I have to search for variables, get to understand the code and all sorts of stuff to analyse where the problem is.

I haven’t done debugging of real code in years, err, cough, decades. When I used to do it we did not have debuggers and had to step through the code instead. It was impossible to work backwards using the the original manual process. However, this process has become automated and updated until we have the current “engine in front of the car because the horse was in front of the cart design”.

Am I missing something obvious or is it time to move the engine behind the car where it really should be.