My favorite guide to working in an agile way is “The Knowledge Creating Company” by Ikujiro Nonaka and Hirotaka Takeuchi. In their book, they explain how companies successfully innovate by working in an agile way. To me, the ideas in the book fitted seemlessly into what I read in “In Search of Excellence”, the seminal book by Peters and Waterman. Following these works, I can summarize my take on “agile” in two principles:
- bottom-up management
- empowerment
Bottom-up management means that decisions are made by those who have the knowledge to make them. Empowerment means that employees can make decisions on the work they do. For more info on that, read Dilbert comics.
In the 1990’s, we worked in an agile way, in an agile organization. We didn’t have books about the subjects, we didn’t take classes, we just did what we did. We had a watercooler or espresso-machine where once or twice a day, a group would form in line, talking briefly about issues that had come up. We didn’t have deadlines, instead we had releases every three months or even six weeks, and on a Friday every other month, someone would say “next Thursday we’ll build a new release, everything that’s finished by then will be in”. You could plan your work to be in a particular release, or you could just plod on and see what happened.
Working agile worked because it was an attitude, not a method or an instruction. Today, software developers take classes to learn “agile”, they read books, they follow online trainings. Do they learn an attitude? No, they learn a method. Can you learn “agile” from a book or training? No, I don’t think so.
Mao Zedong introduced a way of “agile” when he said “let a thousand flowers bloom”. This worked for him. By encouraging people to be creative and take action, good things happened. But then, he wrote it down in his little Red Book. By writing it down, he turned a useful principle into a dogma. We all know what happened when during the Cultural Revolution, millions of youngsters in China were encouraged or even forced to follow the dogma.
Nonaka and Takeuchi did not write a prescription to working agile and empowered. They gave examples. By reading the examples, you “get” the attitude and start working differently. Then, people started changing the attitude into dogma by writing books with checklists and methods. And of course, memorizing a checklist and following a guide is a lot easier than try to extract an attitude from examples. While intended to be a means to working agile, the methods and guides and checklists became the goal instead. Ask anyone who uses Scrum what the essence of it is. They will mention “sprints”, “backlog”, “user stories”, and such. No one will mention “empowerment” or “bottom-up”.
The demagogue in me would now say “do you really think that Usain Bolt could have set a good time at the marathon by running 422 sprints?” But really, this is the essence of my criticism on sprints. Bolt needs half an hour rest between sprints. Similarly, in Scrum you need a refinement meeting before you can start a sprint, and you need a kick-off meeting. At the end, you need a retrospective meeting and a demo-and-review meeting. This takes one full day, or even more, on every two-week sprint. That’s 10% of your time or more. At the end of the sprint, when all work has been done, you need to wait for the next kick-off meeting before you can start on something new. Which of course nobody does, you just pick a new feature from the backlog and start working on it. Or, you may not have finished your work during the sprint, so it moves to the next sprint. Basically, a “sprint” is a totally artificial time period that starts on Wednesdays (or Mondays) and is not related in any way to the work you do.
At a kick-off meeting, the team discusses how much work it can take on in the sprint. You do “Scrum poker”, attributing meaningless numbers to “user stories” that have no real relationship with either requirement definitions or feature descriptions. At the end of the sprint, the team is happy because the sum of the meaningless numbers turned out to be “right” (you’ve done all the work) or the team is unhappy because it didn’t. Explain to me how it is “empowerment” or “bottom-up management” to follow detailed prescriptions to finish an arbitrary amount of work using fictional numbers in an arbitrary time period.
I prefer to take a very different approach.
The work that needs to be done is listed in the team’s to-do list, it’s ok with me to call it a “backlog”. Team members pick items from the list of feature descriptions or requirement definitions and work on them until finished. When finished, the items move from the to-do list to the release notes, and the team member picks another item. No need to do “refinement”, the team members are smart people who can find additional information when needed and contact others when appropriate. The team plans releases, whatever features are done at release time go in the release. If you don’t have releases because you are not a product company but you are the IT department of a company, whenever a feature is done, it is released via the CI pipeline. No need for kick-off meetings or scrum poker. Instead, you motivate the team to take responsibility, you empower them, you delegate decisions to them. You’d be surprised, the more power you delegate to the team, the more responsibility they take and the harder they’ll work.
In some teams, they use smileys on a board, as part of the Scrum method. Green, orange or red smileys how the state of mind of the team members. In my method, the smileys come with the people. I mean, the smiles will be on their faces.
