GUEST COLUMN: Agile-ish: 5 Ways to Tell That You are Not Agile

Guest author Sujey Edward, recognized industry leader in implementing Agile processes, is a Vice President of Salient Federal Solution’s Agile Center of Excellence

When people tell me their Agile projects have failed, it does not necessarily surprise me. The real surprise is when I find out that their “Agile” project lasted years in development, cost millions of dollars, and produced no working software. I have to wonder, how do you call your project “Agile,” when your results contradict its most basic principles? Your team may be conducting daily stand ups, using scrum boards, and grooming backlogs, but executing these tasks does not make you Agile. It’s like coming to a party with flour, eggs, and some butter, and saying, “Look I brought cake!” Agile is not about individual ingredients (activities), it’s a philosophy that has to be baked into the entire enterprise.

Agile’s most fundamental tenet is that production quality software is developed at every sprint— accordingly, it is obvious that a project is not Agile when working software doesn’t exist. So, if you are not measuring your level of Agility through your project activities, how do you know your project is not Agile? Here are 5 simple ways to tell:

1. You take too long to create working software.
2. You are not in the practice of welcoming changing requirements.
3. You do not discover lessons learned after EVERY sprint and apply them to the next sprint.
4. Some people on the project do not know what is going on.

And most importantly,

5. You do not feel empowered to end your project.

If you take too long to create working software, you are not Agile. Agile projects deliver working software every two weeks, or at the least, in a very predictable, short cycle. The longer your cycle, the more risk you introduce to your project. Frankly, if your project has any taxpayer dollars associated with it, (like most of mine do), your cycles should be predictable and short to minimize risk and deliver working software and value to your stakeholders. Are you reviewing and approving production quality software every two weeks?

If you are not in the practice of welcoming changing requirements, you are not Agile. The beauty of Agile lies in the customer’s freedom to re-prioritize, and change direction. Teams that use more traditional approaches spend an inordinate amount of time in analysis before developing any of the solution. Because Agile teams use larger project goals to orient their direction, but only analyze what they need to complete the active sprint, stakeholders and teams are empowered to introduce new requirements based on changes in business value. Are your changing requirements welcomed even late in the development process?

If you do not discover lessons learned after EVERY sprint and apply them to the next sprint, you are not Agile. Traditional projects create lessons learned after completion in its entirety, with the lofty ideal that lessons learned will be applied to the next project. However, when project teams and scopes change and time passes, this application becomes difficult, turning lessons learned into memories of old project horror stories. Agile promotes the opportunity for our knowledge workers to take a moment every two weeks to reflect on what could be done better—the opportunity to try something new, or change a current approach. Are lessons learned being discovered after EVERY sprint and applied to the next one?

If some people on the project do not know what is going on, you are not Agile. Agile promotes transparency to everyone—regardless of your role, or level of authority. All stakeholders should know the ACTUAL status of the project. A real Agile team may use a “wall of truth”, where metrics and current statuses are posted for interested parties to see. Keep in mind, these truths are not week-old stats on a PowerPoint slide. This information is real, live, and absolutely relevant. Does everyone involved in your project know what is going on?

If you do not feel empowered to end your project, you are not Agile. Agile projects end when the return no longer exceeds the investment. Although contracts designate a specific time period for projects, it does not mean a project needs to last that long. While this point may be controversial to your company’s finance department, it is truly the only way to ensure customer needs come first. As Agilists, we understand that our job is to support the agency’s mission through the delivery of high-quality, usable software. The project should end when the value is achieved or when the expected value is not being delivered. Do you feel empowered to end your project?

If you answered, “yes” to all the questions above, you can call your team and your project Agile.
If not, take a second look, apply the lessons above…and stop being the guy that thinks flour, eggs, and butter is a cake.