Agile 2.0

“I’m done with agile!” vowed a developer in a forum post I recently came across online. What followed was a heated thread of agile rage meeting agile creed. Apparently many organizations have failed to embrace the agile mindset and cannot deliver the benefits of agility. By employing only the techniques of agile practices, they are doing agile whereas they should be focused on being agile.

Being agile rests on four equally important pillars: the culture, the structure, the reward system, and the right set of tools. By set of tools, I mean the appropriate techniques for agile practices.

The structure

Being agile is not quite as fun as it’s promoted. It’s very exciting, yet extremely intense. An organization of dedicated teams creates safe spots for individuals to open up and dig into the root causes of the team’s problems and failures. Statistics also attest to the improved results from teams that stay together over the course of many projects: according to Harvard Business Review, stable teams are not only 60% more productive but also 60% more responsive to input.

The culture

Responsiveness to input is what drives change. Short feedback cycles are useless if the team cannot admit that they got things wrong on the first try. Building a culture that allows mistakes is like planting a forest – the best time to do it was 20 years ago. There are, however, accelerators that have transformed teams – both independent ones and those that are part of a larger whole.

Introducing a format of serious play (like Hack Day at Helmes) forms a habit of collaborative discovery: testing, failing, learning and sharing the story. With the time pressure of getting to a working prototype in a single day, the lessons must be learned fast.

The rewards system

During Hack Day, people work on their pet projects, driven by serious motivation and focus to get their project done. The same startup-like drive can be generated with a smart reward system to extend the sense of ownership to the everyday work. Helmes has made every employee a partner who participates in the financial success of the client and the team. Like good entrepreneurs, the teams push for long-term financial success through productivity, efficiency and high customer satisfaction. The focus is clearly set on results.

The toolset

The agile mindset is a filter for the agile toolset. It is necessary to examine closely in order to adopt meaningfully. The best set of techniques is the one that makes sense to the team in the current context. However, there are some tools that we would not trade for anything.


Agile teams are empowered to make decisions without additional review layers and control. In order to make decisions, one needs good criteria. The only good criterion in business software context is the business value. Engineers can be trusted around algorithms so they will weigh all alternatives fast if you crack open the business value calculation to the team.


Agile techniques and principles for influential retrospectives are the ones we follow religiously. We use metaphors as instructed in the retrospective handbooks, we choose a facilitator from outside the team, we mute-map to ensure everyone has a say and ask “Why?” as many times as humanly possible to seek root causes. We hold retrospectives with different scope, starting from iteration retros to the whole partnership with the client.

Agile 2.0

The “I am done with Agile!” is an excellent slogan for an Agile 2.0 campaign of moving away from doing agile towards being agile. It is obvious that an organizational transformation needs more than adoption of a process rooted in Scrum textbooks. I’d say, “pimp your agile” for anyone who is frustrated to the point of long rants in an Internet forum. The right place to vent discontent and concern would be at a good old retrospective.