When an organization begins their transition to agile, it usually begins with one team. That team starts to think differently about how they want to deliver software to their customers, then they make drastic changes to how they operate and think—they start implementing agile practices. Working software is delivered faster, software quality increases, and customers are pleased.
Word starts to get around that this is the team that “gets stuff done,” and everyone wants that team to do their work. The organization takes notice, and someone decides to duplicate the team’s success across all the development teams.
A separate transformation team is put together. It conducts an analysis of the original agile team and documents how they work. Words like Scrum, kanban, and standup start getting thrown around. The transformation team draws up some process flows, evaluates some tools, and creates an agile transformation strategy. Development teams are given this new strategy and some minimal training, and they’re told to just “be agile.”
Unfortunately, this is where it all starts to fall apart. What isn’t included in the transition plan is the mindset adopted by the development team, the product owner, the IT manager, the business partners, and any other stakeholders. The original team focused on changing how they think about their work, not their processes. Initially, there were no specific processes—the team tried something for a sprint or two, evaluated the results, then adapted and changed as needed.
Business partners become frustrated as the teams work to find their way in a new agile world. Teams are punished when work isn’t initially completed at the same pace or priority as it was before the transition.
Faster, higher-quality software delivery doesn’t happen overnight. All the processes and methodologies in the world will fail if you continue to reward a team based on a nonagile mindset. Agile should make us fundamentally change how we think.
There are two areas that stand out the most to me for how our thinking must change: priorities and failure.
Priorities
Traditionally, priorities tend to focus on putting out fires and keeping up with conflicting requests from multiple sources. We’ve all been in a situation where everything is the “top priority.” This leads to several pieces of partially completed work that are continually picked up and put down, depending on reactive needs. Developers are rewarded for dropping everything and helping someone, either through prolific thanks or praise for going above and beyond. Ultimately, this translates to “He who screams loudest gets first priority.”
An agile mindset changes how we look at priorities. Instead of having multiple top priorities that all need to be done yesterday, we now have a single number-one priority item. That item is defined by the product owner, and the team works on it to completion before moving on to the next.
High-priority work still comes our way, and priorities can still change frequently. But changing how we think about priorities helps minimize disruptions and lets us more effectively manage change. Under this system, praise occurs when a team member helps a requestor get work added to a backlog and prioritized with the product owner, as well as when the work is completed. Team members who are not following the team agreements are held accountable, either through one-on-one conversations or in the team retrospective.
Failure
In traditional software development models, success is defined as meeting high-level success criteria created by a project steering committee or executive sponsor and project manager. These success criteria focus on delivering the project on time and within budget, and meeting the predefined project scope and business requirements. When we don’t check off all of the items on our success list, the project is deemed a failure. The team is punished through overtime or extra work to ensure completion. Failure is viewed as something negative that needs to be avoided at all costs.
An agile mindset changes not only the criteria, but how we look at failure. Failure is not something to be avoided and feared. It can be embraced and celebrated as a stepping stone toward the primary success measurement of working software.
A common mantra on teams I have been part of is “Fail fast, fail loud.” This means we are transparent when something isn’t working as expected. Team members are not punished when work fails. Failures are quickly identified and communicated, allowing for either faster resolution or identifying a new approach to the work. When something doesn’t work, it’s only a failure if we don’t learn something. This allows us to continue our forward momentum.
When we stop thinking of failure as something negative, we can start looking at it as an experiment for success. Fear of failure has always been a strong motivator for teams. Success is rewarded and failure is punished. Teams that have permission to fail without fear of punishment are empowered to experiment. Some experiments will yield far-reaching innovations, and some experiments will fail. But in both cases, experimentation yielded results.
Successful agile transformation starts with changing how we think—specifically, in my opinion, how we think about priorities and failure. Priorities become linear and organized instead of reacting based on what is broken. Failure is no longer looked upon as something to be feared; instead, we embrace failure as a learning experience.
Agile transformation is not just a process or a methodology. It’s a mindset.
User Comments
This is a useful article, but I suggest it attributes to "agile" things that have been good practice for a long time.
For example, on having a single priority. In a project of any size, this would be wasteful of resources as there is a high chance that this is not best use of the skills of some team members - plus having everyone work on the same thing may just not be physically possible. Unless you define your priority as "doing the stuff needed for this sprint", in which case you have just made all the items in "the stuff needed for this sprint" equal top priority. And, of course, there is no reason why you cannot apply sensible prioritisation in a non-agile environment.
I should also point out that "fail fast" has been a best practice for a lot longer than agile has been around. For example, Thomas J Watson's "If you want to succeed, double your failure rate."
Very good article