Can we make Agile great again?
Once upon a time, I signed up for an interview as a Product manager assistant to get my first job. I remember walking into the first office: panoramic windows, open space, lots of computers. Everything outwardly reminded me of those endless movies about genius hackers hitting clumsy corporations with their cyber arrow. I have seen a lot of meeting rooms, people arguing, drawing fancy schemes, moving stickers on the Kanban board. All this has finally fixed in my head the idea I will have a chance to lead a real ranger team, a valiant legion of a cyber army with the smartest engineers of generation.
On my first day, the Head of Product gave me a book by Jeff Sutherland about Agile Scrum management, several articles like “Seven mortal sins of the PM”. I remember how passionary I read the Agile Manifesto and each rule was repeated as biblical commandments:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiations
- Responding to change over following a plan
Having worked with different development teams, I want to tell you my vision of the Agile manifesto. Looking ahead, the reality was not as bright as I had expected. Let’s go over the Agile Manifesto to discuss the most common problems.
Individuals and interactions over processes and tools
I understood what was behind this set of rules. People were exhausted by endless manufacturing schemes, which lacked human value and creativity. The software delivery was like a workday in factory halls with bureaucracy line management. In the end, the desire to get rid of routine resulted in ideas to put people above processes and tools. For a simple example, let’s imagine a soccer team: 11 players on the field clearly understand their goal, have the necessary skills, show initiative at the right time. A player does not have to be a forward to score a goal, nor does a tester have to be a Product Manager to improve the product. No bureaucracy, people are like cells uniting into an organism.
In reality, things might be a little different. The biggest problem with Agile teams is the constantly inflated financial budgets for their maintenance. Yeah, they are cool guys putting people’s ideas and creativity above processes, but often it crosses the line. Imagine you have to build an ordinary two-story mansion. In an ordinary Waterfall, you’d rather calculate how much foundation you need to lay so the house does not collapse, then determine the budget. In Agile it is almost impossible, people spend hundreds of hours discussing which foundation is better, what materials to make it out of instead of just doing it. In the end, we lay the foundation for a two-story house as if we were building a 50-story skyscraper. They invent a new bicycle, just in case, because someday in the future, the house will be a skyscraper.
A team has to get at least a little progress every day. They do not have to focus on long development plans and modifications. Only short iterations culminating in a trip to the customers. A new paying client a day will please everyone more than a new thousand lines of code for an architecture. When the company relies too much on its people and neglects processes, it risks ruining the entire project or never even running it. Users absolutely don’t care about architectural delights if they cannot get desired product features on time.
Working software over comprehensive documentation
The second point of the Manifesto is the working washing machine is better than its instructions. Sounds reliable, does not it? Unfortunately, it is a common misconception. Every team member has the right to ask three simple questions:
- Why should they do it?
- Why should they do it in this way?
- Who needs it at all?
As soon as you start asking “why” at all levels, including business, the volume of tasks decreases several times; the motivation increases as well. People understand the meaning of the work, do it faster and more economically, cutting corners. How to ensure this? Write business documentation (user stories).
In addition, I regularly hear a person has been given responsibility for a big game, she does the wrong thing, and it should be reworked. Before writing code, an employee at a specific task describes a two-line or two-paragraph solution plan. This practice allows the team leader or the architect to be aware of all the changes in a large project. She reads not a code curve but two paragraphs about what happens in the system at all, quickly detecting critical errors. All thanks to the user stories.
Don’t be lazy; invest your time. Learn to write documentation efficiently. You will not notice what a huge benefit you will bring to those dozens, sometimes hundreds of people in your project. You will understand your product, where it is going to reduce the possibility of critical errors.
I provide you another example. I once saw one Agile team come up with a game inside. The essence of the game is each newcomer must raise the project in a local environment without documentation. The rest of the team is betting on it. Someone bets for a few hours, others even for a few days. In the end, a fresh developer setup the environment after 18 hours, everyone applauded. It was funny; it was like the final exam to determine the smartest guy. Not having documentation for the launch of a fairly complex project, each developer spent on average 8–12 hours on different attempts. Programmers’ efforts are added to the cost price as they directly participate in the creation of the product. Imagine how much money flew into the pipe behind the screen of this harmless game.
I faced lots of businesses wanted a silver bullet to get everything at once. When a business wants everything, it lies. Try to recognize what the business really wants, understand pains, only then use the Agile. If you would like to reinforce your software development methodologies, I’m available for chat.
I’m going to continue about remaining principles in the next article to discuss other misconceptions.
