It’s easier to understand Agile once you understand the Traditional approach, since Agile was a reaction to Traditional weaknesses.
Agile started in the 1990’s in software development in a response to how badly Traditional approaches were working with these projects. The traditional approach was taking years to create software solutions. By the time the project finished, not only was it much more expensive than originally expected, it wasn’t what people needed.
As we mentioned before, Traditional project management works best when the problem is well known. Where Agile shines best is when finding the answer is part of the problem. For example, think of a Super Bowl commercial. When you are spending millions for a few seconds of time, shooting the actual commercial isn’t the problem. The hard part is finding the right idea that is going to resonate.
To handle these kinds of problems, Agile tools include:
- Delivering iteratively – Traditional project management takes big tasks and breaks them into smaller ones. Agile does the same thing, but does it in a way that each task can be delivered to deliver value. For example, if we’re doing reporting, the first step could be grabbing raw data, downloading it in Excel, and then start seeing what information helps us make decisions before we build the end reports. If you know exactly what the data looks like, this extra step doesn’t make sense. But if you aren’t sure, it can help users see products early in the process to make adjustments.
- Connecting with customers – As you can see, customers are involved early in the process to help test and define the project as you go. They still don’t like the product the first time you deliver, but now they have a chance to make changes. Agile also leans on design thinking and product management to better think about the user experience, so we’re asking the right questions and thinking about real end users (not a super user or a manager).
- Improving teamwork – Agile emphasizes daily touch bases and working together to find solutions. Instead of an architect defining the solution, teams and customers discover it along the way, leveraging the fact that all of us together are smarter than any of us alone.
- Continually Growing – Project management has the concept of growth in lessons learned, but it’s often not done well or often enough. Scrum builds retrospectives into the process, letting the team refine the process throughout the project, not just at the end when it’s often too late.
- Being honest about assumptions – You don’t realize how many assumptions your making about what the customers want, how long the project will take, or how much it will cost until you take a step back. Thinking about a traditional project plan, detailing Bob is going to do a 2 hour task 3 months from now on Friday at 2:00 pm helps you realize how much guessing is going on. Understanding those assumptions helps you better understand risks and mitigate them.
- Giving the team more flexibility to find the right answers – Rather than having top leadership or other experts focus on the right way to do it, Agile works to push decisions down to the team doing the work. Not only does it provide better solutions, but it reduces administrative time on leadership allowing more focus on strategy.
- Shorter deadlines – Projects are broken into 1-4 week blocks, with deliverables due at the end of each. These shorter deadlines work to smooth delivery so teams aren’t easing up at the beginning, then rushing later.
- Forcing prioritization through timeboxes – The approach limits how much time you have to solve problems, pushing teams to focus on the most important items first.
It’s important to remember that know tool works for every situation, and Agile has its weaknesses as well:
- Not everything should be iterative. Building a house one room at a time is far less efficient than starting with a foundation and then moving up.
- Too many teams take Agile as an excuse to not have a plan or a roadmap. You may not know the solution, but you should know what problem you’re trying to solve and how you will measure success.
- Agile doesn’t build in the tools or knowledge to handle complicated projects with a lot of moving parts, or where vendors are involved. This could be because it was originally built on a traditional framework, so project leaders may have already had the skills developed. But if not, it’s important to get people involved who specialize in these areas.
- Agile focuses on effectiveness over efficiency, so it’s less efficient in environments that are primarily individual work and collaboration/problem solving isn’t important.
- To be successful, it requires a change in mindset, not just learning a new set of behaviors. Individual contributors who are used to being assigned tasks are now asked to be creative, trouble shoot, design the entire product, and think about how they can improve as a team. That takes time to adjust to.
- Teams won’t be successful if there isn’t trust. That can take time to develop, and it means team members have to be willing to leave individual goals behind to focus on the good of the team.
- Teams do best when they have time to work together and aren’t multi-tasking, so it does best when you have a team of individuals who are dedicated to the project for a longer period of time.
The perfect environment for Agile is having a dedicated team of people working on delivering and fixing one product over the course of years. However, that’s not where most of us work. That doesn’t mean you can’t use some of concepts, they’ll just need some adjustment. As we mentioned at the beginning, the key is just to choose the right tool for the job.
And that’s where we’ll focus in our next article which will look at Choosing the Right Tool for the Job.