Click the button to start reading
Going Agile? 8 Tips for a Successful Transformation (And 4 Pitfalls to Look Out For)
If you’re taking a trip and you know the destination, packing is pretty simple. A tropical location means you’ll bring shorts, a swimsuit and sandals. Whereas traveling to a wintery climate means you’ll be sure to bring boots and a heavy coat.
But what about packing for a trip when the destination is unclear? And you don’t even know how you’re going to get there? Planning under these circumstances leaves anyone flummoxed and uncertain.
An Agile transformation presents a real challenge to an organization. Particularly in an environment accustomed to traditional Waterfall, managers are used to knowing exactly when a project ends, how much it costs, and every step along the way.
Losing this certainty leaves managers clutching their seats, wondering if they’ve made the right move.
Oftentimes, in an Agile transformation, managers feel their hard-earned positions are threatened. Plus, it’s unclear how to gauge a team’s progress when you can only plan a few weeks ahead. It begins to feel absurd, and so executives have been known to stamp out Agile uprisings, returning instead to staid, known methods of command and control.
Yet, the ultimate objective for any company is a satisfied client. This means delivering a product that has all the bugs worked out, and is ready to go in real time.
Agile lets you achieve this result—in a way that Waterfall cannot. It’s worth it to embark on the Agile journey, then, even though it entails traversing unpredictable paths.
Let’s look at some of the things a manager does to make an Agile transformation successful.
Eye on the Prize: A High-Functioning Agile Team
A transition to Agile is complicated and messy. It requires managers to make all sorts of decisions each day regarding schedules, clients, and workloads.
When a manager understands the end goal, and has a clear understanding of what an Agile team looks like, it’s easier to make decisions that bring this transformation about.
Here are four key components to a high-functioning Agile team.
1. Works Autonomously
An Agile team works together independently from the manager.
They determine the work that needs to be done, based on the end goal, and produce this work in small batches, called sprints. Next, they analyze the work in a retrospective, and plan another sprint.
The team is solely responsible for building software, testing it, and releasing it to see how it functions. This accountability makes the team highly motivated to deliver results.
2. Stays Small
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Melvin Conway, a computer programmer in the 1960s, developed “Conway’s Law”, which propagates the idea that the quality of the communication within a team determines its output.
In order to keep communication fluid, an Agile team needs to be small. One method to gauge the right size of a team is measuring the amount of pizza that can be eaten amongst them.
A group who eats about two pizzas is just right. At this size, everyone on the team contributes. It’s a collaborative, cohesive unit.
If the team becomes any larger, lines of communication break down, and the team’s output declines.
3. Owns Decisions and Outcomes
In a traditional Waterfall environment, a team works toward a goal defined by the manager, and the final product is evaluated by a separate quality assurance team.
An Agile team, however, feels the full weight of responsibility for its decisions and the outcome. This makes them incentivized to solve problems and work through bugs and kinks.
The Agile Manifesto states: “Customer collaboration over contract negotiation.” This means the Agile team works toward a product that satisfies the customer. They aren’t simply producing what the manager asks, and leaving it at that.
4. Pivots Repeatedly
The Agile Manifesto states: “Responding to change over following a plan.”
An Agile team understands the end goal. It isn’t sure at the onset, however, how it is going to get there.
It completes a small amount of work, and based on the results, pivots and plans the next sprint. The path forward adjusts continuously.
In sum, an Agile team works like a small, independent cell within an organization. It defines its own work, evaluates it, and works through problems on its own. The manager’s role is to facilitate the team’s ability to work cohesively.
The Agile approach differs from Waterfall in many ways. In an environment where Waterfall has been the norm, a transformation presents a real challenge.
Next, let’s look at some key areas where Agile brushes up against the established way of doing things.
The Challenge: How Agile Disrupts Waterfall
Waterfall is a big-picture, top down approach to project management. The leader states what the goal is, then working backward, plots all of the steps to reach it.
Agile takes a very different approach. It seeks to resolve some of the fundamental flaws in Waterfall, namely an inability to make changes throughout the project. In Agile, a team constantly pivots and makes changes, based on feedback.
The differences in these approaches affect many facets of a project. Here are some of the key areas where Agile is dramatically different from Waterfall.
Measuring Risk
In Waterfall, a team works to fulfill an objective that is laid out at the onset in a contract. Success or failure is defined by whether or not the contract is met.
With Agile, however, developers design for the market. “Working software is the primary measure of progress,” is one of the Manifesto’s principles. Small bits of completed software are presented to the client, bugs are identified, and the group then pivots for the next sprint.
With Agile, then, the measure of success has more to do with how the end user is responding to the product.
Although Agile’s end goal is superior (it seeks to develop a product that actually works), the constant pivoting presents a challenge to a manager. Whereas with Waterfall, the risk and progress is measurable and known throughout.
Plotting a Timeline
In Waterfall, the leader identifies the goal, then plans backward from that point. Every task is plotted on a Gantt chart. The timeline is known at the onset, as well as the costs.
With Agile, work is paced. Each sprint accomplishes a manageable workload. One of the principles in the Agile Manifesto is “Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.”
Since the team reflects and pivots at the end of each sprint, an Agile team can only look four to six weeks ahead.
A manager, then, cannot present a clear timeline using Agile, as it can with Waterfall.
It’s important to note, however, that the Gantt chart doesn’t account for ripples, and the effects of these ripples, or hiccups along the way. It’s not uncommon for a software team to work 14 hour days at the end of the year in order to catch up with the Gantt chart. The pre-planning in Waterfall, that is to say, is a bit of an illusion.
Changing Deliverables
In Waterfall, the leader tells a team what to build. The team then goes and builds it.
In Agile, the team understands the end goal, and decides for itself what to build. Management isn’t a part of the decision.
An Agile transition, then, may cause a manager to feel that her entire position is eliminated. However, it’s more that the role has changed. Rather than overseeing a team, an Agile manager facilitates the team’s potential.
In sum, Waterfall presupposes what the market wants at the project’s onset. Agile, however, allows the output to adjust as the market changes.
For example, let’s say a team sets out to develop a text messaging app. Then, during the course of the project, the market shifts, and people start sending voice messages more often than texts. Agile would note this shift and re-design its app, whereas Waterfall wouldn’t even recognize it.
It’s not unheard of with Waterfall that a client tells the team to trash what they’d spent the last year working on. The client recognizes that the product isn’t suited for the market at the launch date.
And so, although it feels less certain, an Agile approach aims to produce a product that serves the needs of the market, in real time.
But the differences between Agile and Waterfall, as we’ve seen, are pretty huge. Now, let’s look at key things a manager does to facilitate a successful Agile transformation.
8 Tips for a Successful Agile Transformation
Agile really rubs against traditional Waterfall methods of doing things. Getting universal buy-in can be a challenge. Oftentimes, managers want to be halfway in, straddling the line between Waterfall and Agile. Some relapse altogether.
However, Agile is worth striving for, as it aims to produce a tested product that meets the demands of the market.
Here are seven steps managers take to ensure a successful Agile transformation.
1. Assuage Concerns
Agile buy-in oftentimes is on somewhat of a bell curve. Some managers are all-in, while others are not convinced at all.
The transition has starting pains, for sure. In order to prevent upper management from stamping things out when it doesn’t see results right away, it’s important to educate everyone as to the benefits of the Agile process.
When they understand that Agile means a better product and a happier client, the hesitant managers are more likely to just breathe and go with it.
2. Get Tools to the Team
One of the principles of the Agile Manifesto says: “Give teams the environment and support they need.”
A key role of the manager is to facilitate the autonomy of the software team. Make sure their equipment is the best the company can afford, and that they’re well-compensated for their work.
3. Hire Motivated Developers
Hiring capable and motivated employees is central to building a good Agile team.
In an Agile environment, as discussed, the team is autonomous. They create a work schedule, develop products, test them, then plot a path forward all on their own.
A high-functioning team, then, needs to be composed of individuals with self-initiative. Someone used to taking orders won’t thrive in an Agile environment.
4. Monitor Developers’ Work
One of the principles in the Agile’s Manifesto is “Continuous attention to technical excellence and good design enhances agility.”
A manager of an Agile team assesses the progress of the software developers. The emphasis isn’t on the amount of work being done, or of sticking to a schedule, but of the quality of the work completed.
5. Communicate to the Client
With Agile, a project’s timeline isn’t nicely plotted out, so a manager cannot give a client a definite completion date.
In lieu of this certainty, the manager keeps the client in the loop as to the team’s progress. The manager also solicits feedback from the client regarding batches of completed software.
6. Get an Agile Coach or Mentor
It’s one thing to understand Agile in theory, but quite another to practice it. Every day throughout an Agile transition, a manager is presented with scenarios that leave her befuddled. It isn’t clear how to react to the situation in a way that aligns with Agile principles.
It’s helpful to have a coach or mentor guide the manager in these scenarios. Someone who has walked the path before can illuminate the way forward.
A management team in transition constantly struggles against relapsing into Waterfall. And a coach ensures that new processes are put into place and stay there.
7. Clarify New Roles and Duties
Managers oftentimes are hesitant to implement Agile, as it means a dramatic change in their roles and responsibilities. It’s not unnatural to resist a change that threatens your job!
It’s important that everyone understands they still have a role to play, but that it’s different.
In Agile, a manager’s role is more about enabling a team to work together, and less about overseeing it.
Educating managers about the benefits of Agile also helps to gain buy-in.
8. Model Agile
Company culture in every organization is trickle-down, for sure. A manager who wants to facilitate an Agile transformation needs to be Agile himself.
For example, it’s tempting for all of us, when presented with a problem, to solve it all on our own. This gives us the satisfaction of saying, “I did it!”
However, an Agile approach to a problem means taking the concern to the team, discussing it and listening to feedback.
When a manager understands and models the Agile method, it is easier for others to do likewise.
In sum, a successful transformation is accomplished with small steps. By making diligent, consistent progress, it’s possible to bring about an Agile transformation within all facets of an organization.
Agile Gone Awry: 4 Mistakes Managers Make When Transforming
An Agile environment is built on trust. Managers trust the team to produce excellence and work toward a goal, and the team trusts the process of working around sprints and retrospectives.
It’s easy to introduce practices that threaten this ecosystem of trust and frustrate the Agile environment.
Here are four things to avoid when making an Agile transformation.
1. Forming Storming Cyclone
A cohesive team is fundamental to the Agile methodology.
When any team forms, it goes through the stages of forming, storming, and norming before it can finally perform and produce. Each of these initial three stages takes time.
When people move around and teams get shaken up, everyone goes through the forming and storming stages over and over again. This decreases the time a team spends working on the project. It also disrupts the communication that’s necessary to a high-performing team.
Oftentimes, a company has many projects it needs to work on. It feels it cannot afford to have a team focus exclusively on one. In this instance, rather than rearranging teams, it’s better for a team to work from the product backlog. This way, the work goes to the team, rather than the person to the work.
2. Falling into a Scrummerfall Trap
During an Agile transformation, it’s easy for a company accustomed to Waterfall to backslide into its old way of doing things.
For example, take a sprint. According to the Agile Manifesto, a team works in such a way that it “maintains a constant pace indefinitely.”
Sometimes, instead, a sprint functions like a mini-Waterfall, where most of the work is completed at manic speed at the beginning, with little left to do at the end. (One solution to this phenomenon is to reduce the jobs in the product backlog so that each job is smaller and takes less time.)
When a manager notes a team is backsliding, it’s helpful to take the issues to a coach.
A good coach understands the nuances of all the challenges a team faces, and is able to help navigate them.
3. Forecasting With Gantt Charts
A Gantt chart works well to assuage a manager’s concerns around productivity. It’s comforting to see every piece of work plotted out, and to sit knowing a team can fulfill the contract.
However, the Gantt chart really creates an illusion of control. With any little ripple, the carefully plotted workflow is disrupted. Additionally, this chart encourages software designers to work inside of a black box for a set period of time. They ignore the market, ignore how the client feels about the product, and simply put their heads down and write code.
Sometimes senior managers ask for Gantt charts as part of a status report. In this instance, it’s helpful for a project manager to identify what the manager really needs or is looking for. It may be possible to answer the question or service the need without putting together a fixed schedule of to-dos for the team.
4. Keeping Close Tabs on a Team
It goes without saying that an Agile manager doesn’t micromanage. But some things come across like hovering without the manager even realizing it.
For example, when a manager requests a status report during a retrospective, it communicates that she’s closely monitoring performance.
Or, when a manager introduces time-tracking methods into a team, it disrupts trust and sends the message that she’s keeping a watchful eye on them.
These sorts of command and control messages alter a team dynamic. It goes from being an Agile team who develops its own schedule and works as a unit, to one who listens to orders and acts on instructions.
One exercise to help identify things that disrupt the Agile process is a retrospective on a team’s past year of working together.
With this information, a manager identifies practices that demotivate the team. All the impediments that surface can be organized into an impediments backlog, to determine practices going forward.
A Destination Worth Reaching
With Agile, you don’t know a project’s journey at the onset. However, you do know the journey will be smoother than the jerky ride Waterfall takes you on. And the destination is better, too.
A successful Agile transformation takes time. It won’t look like the team is making progress at first, and many won’t be on board with the changes right away.
The real benefit to Agile are the results: you have happier clients who enjoy the finished product. All the bugs have been tested. Plus, you have a team that reflects frequently and doesn’t waste time going down rabbit holes.
After a time, managers’ uncertainty begins to wane, and it’s replaced with trust in the Agile process. Managers ease the grip on their seat, and breathe a little easier, knowing that with all the tools in place, they can let the software team do its thing.
What are some of the biggest challenges you’ve faced in your Agile transformation journey?
