My colleague Nicoleta challenged me to write a blog post about agile that even a non-technical person can understand. I accepted the challenge only to find myself facing a big problem: how can I describe a philosophy that impacts everything about how we work (and even live) in a short post while keeping it easy to read? I hope I can rise to the occasion.Let’s start from the beginning. What is Agile?
Different people understand it differently. Project managers might see it as a new methodology of working that appeared as a reaction to the classic one, waterfall. Managers might see it as something that can improve business results because it worked for other similar companies. Developers might see it as yet another management idea.
To me, agile is more than that. It’s a new philosophy of work that combines three things: feeling good, being disciplined and focusing on results. When in an agile team, I
- feel good because I work with great people, I have a goal and I am very connected to results
- am disciplined because I know it helps the team and because the team helps me
- focus on results because I know the team’s goal and it satisfies me to fulfill it.
Agile started as a reaction against a style of work that was increasingly used in software development in the 90s. This style of work involved a lot of documentation and bureaucracy. The bureaucracy started from a big problem with software development: at least one third of the projects were cancelled while another third of the projects were going over budget. The natural response to such problems is to add more control.
Agile took a different route. The people who created the Agile Manifesto, the official birth certificate of the movement, thought that we can do better software with less micro-control and more macro-control. As a manager, they said, instead of focusing on what each person does, you should focus on what a team produces. As a team member, it is your responsibility to plan your own work, find solutions to the problems and improve your work environment so that you work better. As a manager, you should focus on how to provide the necessary freedom and environment that fosters collaboration and focuses people and how to solve the problems that stand in their way (so called impediments). As a team member, you are totally responsible of the results. As a manager, you only look at the results and at at how to make your teams happier (because happy teams have great results).
If we take the example of a company that creates a newspaper, this is how agile would work:
- The manager sets goals and constraints. For example: we publish a new edition every week, we must sell at least 10000 copies, we never discuss topics related to politics.
- The team is formed from all the roles needed to create the newspaper. They can be: writers, investigators, reviewers, photographers, designers. We would ideally want typographers on the team as well, but it’s not always possible.
- If the team is too large (larger than 9 people), multiple teams are created with complete reponsibility for one slice of the product (for example: sports section, external section, trivia section etc). Small teams have better collaboration and faster communication than large teams.
- The team creates its own process to deliver the newspaper in the given constraints. A few already defined frameworks exist, like Scrum or Kanban.
- After 6 months, the manager challenges the team with higher goals. For example: sell at least 20000 copies and avoid topics related to football players. The team tells him what they need to do in order to make it happen. For example: better marketing, lower price by lowering production costs by changing the typography etc.
- Given these new constraints, the team must collaborate more closely. Maybe they must review each other’s articles so that they are better quality. Maybe they pick topics together to tap into the ideas of each and every member of the team. Maybe they pair work on investigating a story (you should remember that one of the best investigation ever, the one on Watergate, was written in a pair: Bob Woodward and Carl Bernstein)
This example shows a few important agile concepts:
- Manage by goals, not by tasks. “It’s your responsibility as a team to deliver the newspaper every week and fulfill our goals.”
- The servant leader: “Let me know what you need to accomplish this goal and I promise to help you solve your problems.”
- The only measure of progress is a product that makes sense: “I don’t care if your article is 50% done. I want to see how the full newspaper evolves from the general structure through article titles and first draft for each article to the final version.” This approach is called incremental and iterative development.
- High quality feedback early and often: Reviewing each article as early as possible, even in first draft phase, helps increasing the quality, reducing the creation time and improves the skills of the team. The final feedback is given by the readers: how many buy the newspaper? What do they think about each article?
- Trust: “I trust you can fulfill this goal, given the right conditions. I am here to create these conditions”
- Collaboration: If each journalist works on his or her own, the speed and quality of the end product will only be as good as they are. But if they work together, they learn from each other, improve the quality through reviews and deliver work faster. This is possible because they are knowledge workers; creating knowledge requires as much brain power as possible, unlike creating nuts and bolts.
When I first learned about these concepts, they totally made sense to me. I liked that each role from a company is pulling its own weight. The managers think about strategy, growing the teams, improving results. The creative people have the freedom to innovate and use their skills as long as their work helps the goals of the company. Everyone is helping everyone instead of one person controlling the others. The administrative people have more predictability because the team synchronizes often.
I was surprised to learn later on that agile is difficult to adopt. Here are the most common reasons I encountered:
- Illusion of control: some people feel that managing by goals will reduce the control on the team. Unfortunately, the only way to see it works is to experiment this approach for a while.
- Team members not taking responsibility: agile means more freedom to do your job as you see fit, but also more responsibility. Some people dislike that, especially after being used with someone else taking responsibility and telling them what to do. Some of them can’t adjust to the new model and they leave the team for a place where they can be in the comfort zone.
- Resenting change: agile means continously improving the way you work. This implies embracing change. But this is easier to say than do. It’s much harder to change the way you work every two weeks or every few months than it is to do the same thing over and over. However, my experience shows that once you get over this hurdle, you will take advantage of opportunities.
- Don’t ask for help: any change is difficult. It’s ok to ask for help if you’re serious about it. That’s where Flavius or I usually come in :).
I hope I gave you a good idea about what agile is. I doubt that I gave you a complete picture. If you find it interesting, I’m always ready to answer questions or comments.