QCon London: Taking back development (Take Agile Back).

Ruud Wijnands and I just completed QCon London. I have a few new contacts, a few new stories, and we were able to present "Take Agile Back" -- a talk in three parts:

• Take Back Agile: "If this is agile, take it back."
• Take Back Agile: "Give me my agile back."
• Take Back Agile: "... to your team." 

The point was not to shore up the defenses and protect the whole velocity/timebox/points/meetings nightmare, but to remind people that there were reasons that XP (and scrum) worked, and to return our thoughts to the experiments that resulted in a successful, productive, social process that got stuff done.

There are underpinnings to consider.

Safety (anzeneering) is one. It has to be safe to experiment in order to do things more intensely. We see people repeat some practices, but deny the right to modify the system via experiments and validated learning. This is a mistake. We need to find our own "two questions" and focus on never stockpiling our pain.

Permission is a key type of safety. Ruud and I both talked about finding permission, and how our mental impersonators (your "inner forbidding boss") need re-calibrating. We discussed the context shift developers need in order to get permission, and how trust and permission can be obtained in a transactional way. 

But most of all, it starts with concern for our value:effort ratio. This relates to the lean concept of "perfection" (absolute value with zero waste) and Ruud explained that it can be addressed with the accumulation of small improvements (see 2-Second Lean for more details). 

There was about an hour's worth of stuff, so I'm not going to use up this space with a recap.

However, I got a story from a developer in my elevator ride from the interview I had with Ben Linders on Friday: His team started to estimate the time it would take to clean up the code in order to implement a feature. He said it was the moment that everything changed for the better. They didn't ask permisison, they just included it in the estimate instead of estimating the time to type the new feature's code onto the pile of rotting code that they already had.

This story resonated with me. If you are that developer, please contact me so I can write more about your journey. I've seen this before, and I would love to hear more.