After months of meetings, emails, and debate, the decision has been made: Your organization is going Agile. You’re excited about the benefits and are aware of the challenges. The team is totally pumped about the prospect of making great software that makes the business wildly successful.
Implementing Agile+, or any agile development methodology, can deliver tremendous value from accelerated time to market to improved quality and reduced costs. Unfortunately, many well-intentioned attempts to implement Agile fall short for a variety of reasons.
Simply put, Agile is not “for dummies.” While Agile software development can initially appear clear-cut, the transition period can stir up a slew of behavioral, managerial and technical challenges.
Why It’s Worth It
Greater transparency. More value faster. Fewer surprises. The benefits of Agile go on and on and are enjoyed by the entire organization from the development team to operations, sales and management. Some of the most-loved benefits include:
Greater project visibility.
The level of project visibility in Agile is a luxury not enjoyed by practitioners of Waterfall. With Agile, instead of waiting 12 to 18 months to detect a massive problem, developers can see early on that problems are brewing. Agile also breaks down communication barriers by allowing executive sponsors to see the status and value of a project as it proceeds.
Happier, more satisfied clients.
By the time a Waterfall project gets into production, it can be totally different than what the current market needs. Agile, on the other hand, helps you ship faster, more frequently and stay in sync with market changes. It’s also easier to make the technology scalable (something you may not notice for 12 or 18 months in Waterfall). Because you can show your clients something in one or two iterations (rather than at the end of 18 months), they can easily see if the product meets their expectations and decide whether to add or swap out features.
More engaged business counterparts.
Because of its quick turnarounds, Agile makes it easier to keep the business involved. The business is at your kick-off meetings. They’re in your scrums. You can do demos every two weeks and ask, “Hey, is this what you need? Is this what you like? What don’t you like?” The development team also has the ongoing opportunity to say, “There are a couple of things here I don’t like.” Complaints are dealt with in-person and right away instead of building up over time in email wars. It’s a good thing.
Transparency around changes.
With Agile, the business sees the value of what you’re doing as you are doing it. Now you can say: “OK, here’s what we’re doing. We can change it if you want but it is going to cost this many hours.” The ability to incrementally show the business how long it takes to actually put code back into production after you’ve made changes goes a long way.
Big stuff. Less risk.
Agile makes it safer to tackle huge projects that may seem overwhelming with a less flexible approach. With Agile, you can do the highest risk work first, get some really good feedback, and then recompose it.
More passion about your work.
More often than not, your team gets some requirements and does the development. 18 months later, the project is thrown over the wall. You might never know what the finished product was for or how the business reacted. With Agile, you are a part of something tangible every two weeks. You’re doing work that can be demonstrated, approved and applauded by the product owner. (And even if it’s rejected, at least you know your part in that as well!)
Better managed quality issues.
Some people think that quality goes down with Agile. Most Agile practitioners think the opposite is true. With Agile, quality is built into the process. Rather than a quality group that comes to the release at the end of the day, the entire team is responsible for quality.
Agile is Easier Said Than Done
Long-term success with Agile requires a specific cultural mindset, ongoing organizational commitment, and a lot of hard work. Most companies face a variety of people and technical challenges when transitioning from traditional software development environments, including:
Not everybody readily buys into the Agile way of thinking. Some testers just want to test. Most developers just want to develop. Business analysts rarely want to do anything else. Changing the way people think and behave about their work is probably the biggest challenge to forming an Agile team.
Changing this attitude requires building trust within the team that it is safe to fail. You don’t want to fail, of course, but if you have an Agile team all moving toward one goal, you figure it out, adapt and change for the better.
Agile teams are cohesive teams. If you have a dissenter on your team, it’s recognized as a team problem and the team works to correct the issue one way or another. Everyone needs to be on board and work together toward the same result.
One way to build the Agile mindset is to abandon your cubes and move into shared space. Co-location promotes a strong, collaborative team environment. While some may resent losing their privacy, the impact of having everyone in the same room is tremendous. Say, for example, someone goes to your tech lead and says, “Hey! We have a problem.” Now, everyone in the room hears the heads-up and can do the right thing to resolve the issue.
Because an Agile team is so adaptive and frequently changes its focus, resource management issues can easily be magnified. For example, some of the .NET developers on the Agile team are needed for a new Java team. How do you seamlessly remove them without hurting the Agile team? The same may apply to BAs and QAs.
One solution is to build a poly-skilled environment where individuals have multiple expertise areas. Now, .NET and Java developers can learn core concepts in both areas and move between them. BAs and QAs can learn to move between the analyst roles.
True, this is not easy since some QAs simply don’t want to deal with the BA role and some BAs don’t use a QA role. While this may be a situation that calls for more than a carrot, it’s part of the transition as to how you solve it.
The magic Agile wand (aka the “checkbook syndrome”).
According to corporate legend, when an organization transitions to Agile, the business runs around waving their Agile magic wands saying, “Well you’re Agile now. I should be able to change what I want, when I want.”
There is no denying that without proper management of the core cost and schedule of the project, an Agile project can easily become an open checkbook that allows development to just keep working on projects indefinitely. (Although some may argue that an open checkbook is a strength because you get to refocus where you are going with every reiteration.)
One of the tools for getting around the open checkbook syndrome is to make the business people keep the end game as the focus of each iteration. For example, rather than focus on architecture or things that could impact the cost and schedule, hold the business responsible to concentrate on the end game. Shift the responsibility to manage against the budget to the Product Manager or Project Owner. Give them a budget constraint and allow them to run the project however they like. But, when the time is up, they lose their team unless they renegotiate something.
When you move to Agile, you look forward to positive behavioral changes on the part of ‘liners’. You want them to team with you and sit in the shared Agile room rather than another office, building or continent. In order to avoid disappointment, it’s best to keep in mind that the typical “line of business” person doesn’t always care about Agile the way you do. They don’t care about Waterfall either. Just like some people don’t care about the model car they drive, they just want to know that it’s got four wheels, it steers, and it makes my business go. Accepting this attitude can be a challenge because it is hard to put yourself in someone else’s shoes.
Ideas to Help You Succeed
Best practices are practices that help you succeed. That said, we’ve come up with some recommended practices that reflect the trials, errors and successes of teams transitioning to Agile:
Let teams evolve in their own way.
Because teams come from different places and perspectives, they need to evolve in their own ways. Let’s say you have multiple teams adopting Agile. One team is a start-up with zero structure. For this team, Agile seems heavy and controlling. The other team is transitioning from a structured Waterfall environment. To them, Agile seems lightweight and elusive. In cases like this, how do we find best practices across teams?
One way to address this challenge is to pull together the QAs, PMs, architects, and other functional groups from each team and have them work together to come up with best practices. You can also have teams of all the architects or BAs or QAs that meet once a month.
Understand the metrics.
Metrics for an Agile project are very different than Waterfall and require upfront negotiation. If your GPMO or PMO is trying to track an Agile pilot according to standard Waterfall metrics, be prepared for fear of failure, bad feelings, retreat and loss of support. Your Technical Sponsor must agree that even though Agile metrics are different, if your teams meet them, you are successful.
Invest in training.
Because Agile is a different way of getting things done, getting the appropriate training is key to success … even for experienced professionals. Sometimes training can take the form of work groups that provide community support or peer-to-peer problem solving. Since Team and Scrum Managers will no longer be in control of their teams like they used to be, training in their new role as team facilitator may be a good idea.
Leverage transparency to eliminate surprises for the business.
Agile has unique advantages … so make the best of them. The business can now see the value of what you’re doing as you’re doing it. If they want something changed, you can show them exactly how long it will take, what it’s going to cost and why. This is a huge advantage because, as you know, the business doesn’t always realize how long it takes to make changes.
Build support with IT and Business Executives … even the CEO.
Agile is not just a development change or trying a new methodology. It’s a mindset change that affects all parts of the organization. A successful transition to Agile requires the Business to understand that they’re part of the team now. It’s no longer them and us.
What kind of support should you strive for? Executive support should go beyond IT. You want the CEO to make it clear to the organization that she is onboard with the adoption of Agile. You want her to say that anyone not on board should find another job. Although this may sound a little severe, it’s actually necessary because in spite of its advantages, many organizations have trouble getting people to commit wholeheartedly. Change is always hard -- but those who do commit 100% see the results.
Ideally, IT and the business should be mutually engaged, working side-by-side through the transition. In reality, however, it doesn’t always work that way. But hang in there! As you walk down the transitioning path, the engagement starts to happen. Those little light bulbs come on and you see things like defect rates going down. Or it takes less time to solve a problem. Before you know it, the product owner bounds into your Agile room and says, “ I can’t believe you did this in two sprints!” The team gets energized and engagement soars as the business begins to really get the value of Agile.
To Eat the Egg You Must Break the Shell
The old Jamaican proverb has it right. In order to do the stuff that matters, the fear of risk-taking must be overcome. Agile is not as straightforward as it appears at first, the transition period can be tough, and most companies make so many mistakes they start to wonder why they bothered.
But for the most part, once you commit to going out on the limb it won’t be long before you’re grabbing low hanging fruit. Sustaining and scaling, though, is the tough part. Things like forming an Agile office, leveraging your new found transparency, and driving executive support are crucial to making Agile sustainable.
Done right, Agile can go a long way in helping to remove obstacles to team success, keeping relationships open, and solving your clients’ business problems.