5 Lessons to Learn from Agile Roll-Out Success Stories

Agile development – like so many other major undertakings – can seem like a great idea on paper, but turn into one that’s surprisingly difficult to execute.

Part of this challenge occurs because Agile, as executed by its many supporting methodologies, seems to require an “all-in” effort. Indeed, the four core beliefs of the Agile Manifesto listed below seem to require a total reworking of a company’s development teams, resources and processes:

Understandably, given their intense requirements, Agile implementations fail. But as is often said, where there’s a will, there’s a way. Protecting your Agile roll-out from negative outcomes can be achieved by learning from the example of those who have gone before you- including the five companies profiled below:

Don’t Dismiss Agile Prospects Unnecessarily

Many companies using traditional waterfall development are quick to dismiss the possibility of adopting Agile – not because they can’t see its benefits, but because they believe it will conflict with other certifications and structures the company has already taken on.

(The agile process is perceived by some to contradict the more linear processes and structures within the company, producing resistance to moving towards an agile approach.)

One of the most commonly cited sources of conflict is with the Capability Maturity Model® Integration (CMMI), based on its focus on repeatable processes and documentary evidence. However, as a case study published by technology provider CollabNet demonstrates, it is possible to find common ground between the two approaches.

In the case of a large, CMMI ML-3 financial institution, CollabNet shares:

“The firm employed Agile and CMMI consultants to look for a viable solution. Widespread consultations and workshops were held that involved team members across the organization. An initial process was developed that captured the core elements of Agile and fitted in with general working practices of the firm.”

Ultimately – and as should be expected in a corporate case study – the institution went on to adopt CollabNet’s technology to automate many of the documentation requirements associated with their new process.

The lesson here, however, isn’t that the right technology provider makes Agile implementation possible (though it certainly doesn’t hurt). Instead, it’s that common conventions like, “Agile and CMMI can’t work together,” can often be disproven when the parties involved are sufficiently motivated.

Free Up the Resources for Necessary Dedicated Personnel

Scott Granieri of Tantus Technologies, Inc. shares how a federal client of his firm navigated the Agile roll-out process back in 2011. Though Granieri identifies many challenges posed by this transition – including overcoming a long history of waterfall development, the client’s appraised CMMI ML-3 status, and budget restrictions that prevented the hiring of new personnel -in a white paper for ScrumAlliance, it was internal organizational issues that posed one of the biggest hurdles.

(The Agile roll out process is dependent upon 5 key factors. At the heart are culture fit – the suitability of Agile for the organization’s culture – and resource requirements.)

Granieri describes the work carried out by the client as “supporting more than 23 systems with more than 80 team members, performing both operations and maintenance work along with projectized enhancements.” Understandably, then, freeing up staff who could dedicate themselves fully to Agile was nearly impossible.

According to Granieri:

“A matrixed team environment is not optimally aligned to the Agile model, and it presented us with a roadblock in terms of realizing the full benefits of Agile. When people move in and out of teams, team cohesion suffers, more coaching is required, team velocity does not improve as quickly, and velocity itself becomes less predictable.”

Further complicating matters was the fact that none of the team members on Granieri’s client project had extensive knowledge of Agile or Agile methodologies. Success ultimately came once Granieri and the client identified a business intelligence pilot program with a manager willing to take on the challenge of learning a new development process and invested in the training necessary to execute the Scrum process.

Reflecting back on his experiences, Granieri offers the following recommendation: “Where you can, we strongly recommend dedicating teams solely to Agile development. Where you cannot dedicate staff, we recommend seeking some alternative solutions. Alternative solutions may include dedicating as many of the sprint team members as possible (if all cannot be fully dedicated).”

Granieri’s experience and suggestions point to a truism about Agile development: half-hearted efforts will deliver half-hearted results (or worse). If your company isn’t able to free up the necessary resources -described here in terms of personnel, though employee availability isn’t the only resource required – it may be best to delay Agile roll-out until a later date.

Consider the Needs of All Involved Stakeholders

Freeing up the necessary personnel alone isn’t enough to guarantee Agile roll-out success. As early as the initial planning process, care must be taken to protect the needs of all involved stakeholders at every step along the way.

On the UK-based ProjectSmart blog, IT consultant Adam Alami shares the example of an Agile roll-out that was, by most standards, considered to be a success. Speaking on the positive feedback given by team members, Alami shares:

“Participants found that using the Scrum process brought them closer, made them aware of each other’s thinking processes and helped build team spirit. They felt the method facilitated knowledge sharing. Most of the participants also found the process to be very vibrant and dynamic. The process energized the team, and all team members felt they had a voice.”

At the same time, however, Alami found stakeholders experiencing dissatisfaction due to their inability to see the big picture of the project and the way a lack of centralized documentation and communication made them feel as if critical knowledge was missing.

Recognizing these needs – paying attention to the bad as well as the good – enables companies to remedy problems that arise before resentment grows. In Alami’s case, for example, modifications of the Agile framework to address big picture issues or the creation of an internal intranet to serve as a knowledge repository and transparent, inclusive communication platform would have helped stakeholders feel more positive about the Agile process.

(Using intranet teams, all stakeholders can centrally host essential documentation, knowledge and communicate with other team members on the project. This ensures accessibility to critical information for all.)

Learn from Alami’s example. Don’t wait until problems appear. Continuously solicit feedback from stakeholders and act on it in a way that supports their needs throughout the roll-out and beyond.

Learn from Your Mistakes

Railinc freely admits that their first Agile attempt failed; not through weaknesses in the approach itself, but because they chose the wrong pilot project.

“We had already tried and failed once to apply the Agile software development methodology to one of our tech projects. While customers were indeed more engaged with us, it turned out that we had picked the wrong project. And we had insufficient infrastructure in place to support it. And we had stretched our development team too thin. And the list goes on. It just wasn’t right.”

Undeterred, Railinc repeated the process again – this time, with the right project and the right people in place. In fact, the success of their second Agile roll-out led to an unexpectedly positive outcome: it gave them the insight needed to kill the project in question before bringing it fully to market.

Railinc’s example has a dual lesson to be learned. First, there’s the obvious maxim that, if at first you don’t succeed, you should try and try again. Even more interesting, however, is the importance of learning not just from your implementation mistakes but from the data and insight your new process generates.

An Agile roll-out can succeed, yet still produce data indicating that the project involved will be a failure. As frustrating as these realizations may be, learn to celebrate that discovering failure at this stage represents a far smaller loss to your company than identifying impending doom at the end of a lengthy waterfall development cycle.

Don’t Be Afraid to Change Your Approach

Though Agile development requires substantial investment, beware of sunk cost fallacies that prevent companies from changing direction as needed.

Take the case of Siemens Health Services, as described on the InfoQ website by Bennet Vallet. Though Siemens had initially rolled out Agile using a Scrum/XP methodology, they found, after several years, that the metrics derived from their relative story points and velocity charts weren’t properly supporting their ability to manage release development.

To increase outcome predictability and release forecast accuracy, Siemens revised their methodology to the Kanban approach – going all-in on the process. According to Vallet:

“We used a big-bang approach to implementation, based on the belief that in order to achieve results at this scale; we would need to fully deploy Kanban across all the teams as well as at the enterprise program management level.”

Following its first year of Kanban rollout, Siemens migrated all of the company’s 40+ teams across three continents to the new approach. Vallet acknowledges that Siemen’s past failures with Scrum methodology directly contributed to success of the company’s Kanban roll-out, proving the important lesson that it’s always ok to go back to square one, change your approach, and move forward in a way that’s right for your company.

Now, we want to hear the lessons you’ve learned. What would you add to this list, based on your own experience rolling out Agile? Leave us a note below sharing your experiences.