Mayden is a small and successful U.K. company that develops managed Web applications for the health care sector. They specialize in flexible, cloud-based software, delivered by a team of 44 from two locations in England. Celebrating their tenth anniversary in 2014, Mayden has built a track record of delivering value to its customers with applications that have the power to change the way that services are delivered by health care staff — and experienced by patients.
Given a relatively young company that focuses on innovation and flexibility, you might think that Mayden grew up embracing business agility, but that wasn't the case. The company did have a reputation for being responsive to customer needs, but it tried to execute within a traditional project management environment. CEO Chris May explains the problems that surfaced as a result of trying to be flexible in a Waterfall environment: "Our best-laid plans were continually being hijacked for short-priority developments. The end result was that we reached a point where we had started lots of things but were finishing very little."
This created what Operations Director Chris Eldridge refers to as an "illusion of progress" — projects were frequently assigned to only one person, so the work "often took months to complete." From a development team standpoint, this approach created individual expertise and worked against a team environment. People were seen as specialists, and some developers had a large backlog of work while others had insufficient work — but they were unable to assist their colleagues because they didn't have that specialist knowledge. This created individual silos and led to lack of variety as well as boredom and low morale. From a company standpoint, it also led to poor skills coverage, with multiple "single points of failure" in the development team.
Fortunately, Mayden recognized that the situation wasn't ideal. When an opportunity to develop a brand-new product with brand-new technology presented itself, the staff was enthusiastic about trying a new approach. While there was some discussion of hybrid project execution approaches, the decision quickly came down to using Scrum or continuing with the traditional Waterfall-based method that the organization had in place.
A number of people on the development team were interested in agile. One of them, Rob Cullingford, decided to do something about it. Without really knowing what to expect, he booked himself on a Certified ScrumMaster® (CSM) course with Paul Goddard of Agilify. At the end of the course, Cullingford was not only a CSM but a "complete convert." He presented his experience to the rest of the development team and convinced Mayden to bring Agilify and Goddard in to provide them with CSM training, with similarly positive results.
Cullingford points out that Mayden management had a vital role to play in the decision to use Scrum. "The company's management team really grasped the concepts of Scrum and had the foresight to see how it could transform the way we delivered our projects, and moved decisively," he explains.
Eldridge had a background in Lean manufacturing, and he saw a number of significant similarities that helped support his quick acceptance of Scrum. He freely admits, however, that the decision was driven by the enthusiasm within the development team. "The ultimate decision to take Scrum training forward was a no-brainer," he says. "Paul [Goddard] came in to talk to us one week, and we had 20 people on the ScrumMaster training the following week." Eldridge adds that Scrum was "enthusiastically embraced by all: the managers, support team, and developers. Everyone was really keen to give it a go."
Clearly the environment at Mayden was ripe for change. There was a general recognition that the current method of executing projects wasn't working, combined with a potential solution in Scrum that all levels of the organization felt would offer tremendous benefits. However, enthusiasm for a new approach is not enough in itself — success has to come from the results, and it was here that Mayden shone.
"The result has been transformational," Eldridge says. "Stories are now allocated internally by the Scrum team, freeing up that responsibility from the project lead. The team is empowered to divide up the work as they see fit, and they have moved away from internal experts over time." Developers are more interested in the work, and skills are better spread among the team members. Fewer stories go into development at one time now, which has meant faster delivery of new features.
Cullingford explains that Scrum has also added greater visibility for all stakeholders into what is going on. "Committing to producing something by the end of each sprint gave not only the developers but also all stakeholders visibility on progress. This was completely new to us, as previously months could go by before any work was shown to anyone. It was great to see a product progress rather than just being witness to a final grand reveal." Of course, the customer also benefits tremendously from this approach: "The client [is] getting a product they want rather then something we thought they wanted," Cullingford says. That product also tends to be of higher quality, with defects identified earlier in the process through the reviews at the end of each two-week sprint.
Cullingford is convinced that the same results wouldn't have happened with the organization's traditional project execution approach. He also points out that because the client wouldn't have seen the product until much later in the development process, any changes would have involved expensive rewrites. There would also have been an impact on other projects, because team members would have been tied up with those rewrites.
The benefits to Mayden have gone beyond just a better performance on this particular project. Eldridge identifies a number of distinct areas where he has seen an improvement since the introduction of Scrum:
Eldridge sums up the situation with the ultimate compliment: "Scrum is probably the single most productive change we've made in Mayden's ten-year history."
Mayden has now moved all of its product development teams to a Scrum approach. Although the company was able to make the change quickly, in just six months, it still wasn't fast enough for the development teams that were seeking to embrace it. The final teams to make the transition were "positively falling over themselves to move to Scrum; we didn't have to persuade them to change at all," Eldridge says.
Mayden isn't stopping with development. "Everyone can see the benefits," says Cullingford. "There are now other areas of the business, such as the customer support team, that are looking at how Scrum could be beneficial to them."
Clearly, Scrum was the right solution at the right time for Mayden. The company was able to realize benefits quickly, in large part because everyone involved recognized the opportunity and committed to it. However, Scrum has reached much further into the organization than anyone imagined. CEO May describes a better relationship with customers, who, he says, now "get a definite answer as to when something will be delivered, even if later than they would have liked.'"
In his role as product owner, Eldridge also sees benefits. "The quality of the coding and the engagement of staff in the process has increased massively," he says. "It feels like the development process has more structure. The fortnightly sprint rounds provide a regular rhythm to the teams, which is very comforting to the teams and to the managers." Eldridge also notes that managers are spending less time managing staff, which in turn frees them for more valuable contributions than task management.
As ScrumMaster, Cullingford has perhaps the best perspective on the changes that Scrum has ushered in. He is able to see just how profound the impact of Scrum has been on the development team. "The morale and working environment for the developers is so much better. Some developers have been totally transformed -- empowering them and giving them a voice has brought them out of their shell and really grown their confidence. They all now have a say on how a sprint story is to be implemented. In some cases, it's been like hiring new developers, the change has been so great."
Cullingford cites improved communication within the development team and also between developers, ScrumMaster, and product owner, increasing the level of engagement at all levels. The key challenges that the organization faced with its old project execution model are no longer a problem. In particular, Cullingford notes, issues with capacity planning disappeared "almost overnight" because of the effective use of sprints and the backlog. The removal of reliance on individual specialists is also improving the overall quality of development because of increased visibility into the code, which creates an environment that Cullingford describes as "constant peer review."
Mayden was able to deliver a tremendous level of success, not just relative to how things were before but also in absolute terms. May, Eldridge, and Cullingford all recommend that other organizations explore how to take advantage of what Scrum offers, but they are aware that success comes from hard work. Cullingford notes that even though they were told in training that while Scrum concepts were easy, putting them into practice could be difficult, there was an initial belief that it would be easy for Mayden.
Cullingford points out that success comes from commitment, and from the support that is readily available. "If you do choose to implement Scrum, you can't do it halfheartedly; you have to commit to it. Embrace it company-wide and you'll be amazed by the results. Also find a great Scrum trainer/coach. We couldn't have made the transition to Scrum so well without the expertise of Paul Goddard. As well as the CSM training course, he has done on-site coaching to get all the teams underway with their sprints and has popped back after a few months to check on our progress and stop us falling into bad habits."
Eldridge agrees that training provided tremendous benefits for Mayden, and he notes that the trainer helped them overcome the temptation to make changes to Scrum practices in the beginning to make things easier -- "always for good reasons," Eldridge says, "but what you really need to avoid is falling into bad habits early on." Goddard and Agilify understood Mayden's needs and helped develop its capability at the start, then followed up with checkpoints during the adoption process, providing not only practical advice but also an incentive to "avoid letting the good intentions slip."
Cullingford says that the dynamics of the team may change, which requires an open mind and trust. "The quiet person in the corner who doesn't say much may just well surprise you and become the star of the team, if given the opportunity and environment in which to flourish. We've experienced that firsthand, and Scrum was the catalyst."
Get the latest resources from Scrum Alliance delivered straight to your inboxSubscribe