Are you Ready Ready

I’ve been to the Scrum Gathering in Munich this year. In his keynote Jeff Sutherland describes how he gets Scrum teams hyper productive. Essentially, you need to get your stories to Done Done as fast as possible. However, often too many unknowns do exist when a user story is being played. To fix this problem Jeff introduced, as on of his key ingredients, the concept of Ready Ready. Ready Ready removed disruptions and waste caused by issues being clarified with customer or others. He even suggested the use of a Ready Ready checklist to make sure that stories to be implemented do comply with the definition of Ready. Looks like the ‘Definition of Done’ gets a sibling -- ‘Definition of Ready’. The enforcement of DoR helped to increase the flow of stories to the anticipated state of Done Done and thereby increasing the productivity. Applying Ready Ready was core to create hyper productive Scrum teams. It came 2nd after 'Everyone must be trained in the Scrum framework'.

This is essentially what I have been doing or better trying to do in my last projects. However, the Ready Ready idea is very easy to explain and very convincing. Especially since it comes from Jeff Sutherland.

From now on my Product Backlog items will be Ready Ready before they can move into the Sprint Backlog.

The Agile manager is a master programmer

Lean thinking by Toyota says that managers must go and experience at the real place of work (gemba in Japanese) to learn what is going on. In the manufacturing field, gemba means the shop floor. When trying to apply Lean Thinking into my Agile management style, I feel like uploading the codebase from the repository into my computer and looking at the code; or even going further, I should be pairing with the programmers in my team.

The “real place” in software development is the crafting of the software. Therefore the Agile managers should be master programmers who can craft the code, and apply the development practices.

Of course not every master programmer will make a good Agile manager; and, on the other hand, not every traditional manager will make a good Agile manager. Either one will have to master several complementary skills that will empower a good Agile manager.

I have seen great traditional manager became great Agile managers, and great programmers became great Agile managers too. In both cases, the winner (the new Agile manager) did not stand alone. The whole team benefits at the end.

The manager who is new to Agile is to be empowered by the Agile team. And the programmer who is new to Agile is to be empowered by the team, including the Agile manager. Empower the team. Really. Don’t forget to empower the new-to-agile-manager. Please invite your manager to (once in a while) craft the software with you.