I went to the Integrated Agile conference yesterday. The conference was about dealing with Agile and Lean in software development. Instead of taking notes on paper, I used Twitter all day - so you can find the notes using Twitter Search for keyword #iagile.

A lot of what was being said focused on the state of agile methodologies as of now – most evangelism has been done, and now we have to deal with reality.

Do not love agile

The keynote session was taken care of by Henrik Kniberg, the writer of Scrum and XP from the trenches. His starting point was that we shouldn’t love agile or Scrum – that only leads to emotional debate and expectations that can never be met. The current state of agile methodologies (or tools, as he likes to call them) is that people expect miracles, so most companies will be disappointed. Basically, the expected level of greatness of agile is larger than its success rate. It’s probably best to focus on the solutions for the problems you want to solve – if agile tools can help, that’s great. However, using a tool in the wrong way does not make sense, regardless of the quality of the tool.

Tools don’t fail or succeed. People do.

He even quoted Miyamoto Musashi, infamous author of the Book Of Five Rings. He was a ruthless fighter in the 17th century. One of his lessons is never to attach to a single weapon or style. So, do not commit to a single tool. Use multiple if you must, add stuff, leave stuff out. The process is only a tool: a way to get to the real goal.

If you lock yourself in a process, you might end up doing stupid things. Examples are:

• Complaining about changing requirements. Don’t! Change your process to be more change-friendly instead.
• Locking your doors during a sprint to prevent interruption. Don’t! Shorten your iterations instead, so there is more opportunity for stakeholder representatives to drop by.

A tool is only a tool, but some values are pretty much universal:

• Visualize the workflow
• Limit work in progress
• Focus on quality
• Prioritize
• Short feedback loops

An important lesson: don’t worry about getting your process right from start. You won’t. The only real failure is the failure to learn. So don’t blame the tool, try to improve yourself instead.

Product owners

After Henrik, Serge Beaumont entered the stage. At Albumprinter, we know him pretty well, because he used to be our Scrum coach from Xebia. He’s a smart guy.

His talk was about product owners, a largely neglected area in agile literature. He argued that the Product owner is largely responsible for maintaining flow of development. After all, the owner produces requirements, and an interruption in the flow of requirements influx could break the flow of development. A way to circumvent this issue is to create buffers in the ready state.

In order to do this, the Product Owner must be aware of a long-term vision to have a direction. So, focus is a requirement for flow. Like Henrik Kniberg, Serge referred to Kanban. It’s a concept related to lean and just-in-time (JIT) production, devised by Toyota. Kanban dictates only few restrictions:

• visualize workflow,
• keep work in progress small,
• improve flow.

Interesting advice on writing stories: avoid the cause-effect trap (“I want a button because then, I can go to the next page” – that’s not business value), by simply asking why every time a requirement pops up.

Océ

I went to a presentation of Océ, the manufacturer of copy machines and printers. They use Scrum in their R&D department – with over 900 developers. That’s a crazy number. They even put the actual machine in the room of the team that deals with it. Very interesting. The presenter John Kesseler focused pretty much on how to select the right leaders for these teams. He argued that the most important traits of a Scrum Master and team lead (the same person in his organization) are:

• Focus on quality. Lack of focus on quality indicates (or will lead to) lack of motivation.
• Focus on the entire system. Team-centric scrum masters are bad.

Toyota Lean

Pascal van Cauwenberghe and Portia Tung presented a session on Toyota Lean. Obviously, Toyota has been used as an example for years. They are really successful in manufacturing stuff by applying an amazing process called Lean. Amazing note: Henrik Kniberg claims that Toyota itself still uses waterfall for their software projects – a thing they don’t like, but they are struggling getting Lean to work in the IT department.

Anyway.

Kanban says to visualize the workflow, and subsequently optimize. As Taichi Ohno says: “All we are doing is looking at the timeline from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that timeline by removing the non-value-added wastes”.

There are a couple of rules in Lean that can be used in software, too.

• Don’t produce to make money, make money to produce instead. Money is never a goal.
• Discipline of a team starts with the leader's discipline.
• All management decisions should be based on long-term philosophy.
• Don't do workarounds. Period. Fix the real problem instead, or you will suffer later.
• Reflection must lead to continuous improvements.
• Do the Gemba (workplace) walk, go and see for yourself.

How to create flow?

• Avoid mistakes by not overloading people and machines.
• Work at a sustained and sustainable pace. Avoid interruptions, task switching and starting/stopping a lot.
• Use stable, repeatable methods everywhere to maintain predictability, regular timing and regular output of your processes.
• Allow creative and individual expression to improve upon the standard.
• Encourage your people to consider new technologies.
• Use simple visual indicators (Andon) to help people determine if they are within a standard condition. Design simple visual systems at the place of work to support Flow and Pull.
• Link teams, departments and companies with simple Pull systems. Be responsive to shifts in customer demand, rather than relying on long-term schedules and complex systems to manage inventory and work in progress.
• Jidoka: build a culture of stopping to fix problems, to get quality right the first time: automate tests and deployment.

The final keynote

Then, Rob Thomsett threw away everything you just thought to know about Lean and all that. This experienced IT manager and brilliant speaker did an awesome session on The End Of Management As We Know It.

1. First, we compared IT to the building industry. It gave us waterfall methods. Waterfall turns dark after analysis - an interpretation of the analysis suddenly pops a lot later in time. That worked in the 70s, because the window of stability for businesses spanned multiple years back then. Right now, it doesn’t work anymore. Why? Ask your CEO how many months in the future he can foresee with certainty, and there is the answer.
2. Now, we compare software development with building cars in Japan. Does that make sense at all?

When we borrowed engineering and construction project management models we also inherited their prevailing culture. We are all victims of a project culture that has evolved "silently" over 40 plus years: closed, distrust, dishonesty and lack of courage are symptomatic.

Maybe, we are using the wrong metaphors.

The good news: agile development is the first transparent development model in the history of IT and business. Now is the time to change. A crisis is a terrible thing to waste. It isn’t about hunkering down. You must emerge from this crisis as a new company. Use turmoil as an accelerator for improvements.

Pretty cool.