Scrum is popular as a jumping-off point for agile software development because, experts agree, it\u2019s lightweight and easy to grasp. Because it\u2019s a framework and not a methodology, it\u2019s more empirical in nature than prescriptive, and it looks more at the process of creating software than at the engineering required to create it.<\/p>\n
Despite its relative simplicity, agile development experts agree that certain bridges must first be crossed before an organization can implement Scrum (and other agile methods) successfully.<\/p>\n
Scrum is best utilized for developing software products that would otherwise fail using a more traditional approach to project management, according to Victor Szalvay, CTO of the Scrum business unit at CollabNet. Among the factors is the complexity of the project.<\/p>\n
\u201cAre requirements changing? Is the technology squishy? Where you\u2019re injecting uncertainty, the project becomes non-deterministic, and that\u2019s where Scrum is the best fit,\u201d he said. Projects that are simple, highly repeatable, and with little risk and uncertainty, can be done using more traditional \u201cwaterfall\u201d methods, he added.<\/p>\n
After an organization makes the decision to move to Scrum and agile, it must first have an understanding of what it\u2019s getting into with the framework before trying to implement it. Moving to agile development, and particularly Scrum, involves a major change in the way development shops work. As the old saying goes, \u201cPeople don\u2019t resist change, they resist being<\/i> changed.\u201d<\/p>\n
One of the first keys to gaining the productivity benefits that Scrum promises is to get total buy-in, whether from a small team doing a pilot project or an organization-wide shift. The experts interviewed for this story agreed that it is important to have both bottom-up and top-down support before beginning to work this way.<\/p>\n
\u201cYou have to understand when you move to agile methodologies, there will be a learning phase that should be accounted for in the planning,\u201d said David Vidoni, director of product management at BPM software maker Pegasystems, which transitioned to Scrum and agile development about a year ago. \u201cIn situations where you don\u2019t have buy-in, that\u2019s where you run into problems.\u201d<\/p>\n
Ideally, an organization will have a team of developers that wants to work in a Scrum and agile environment, along with a higher-level executive who understands the benefits to the business and will champion the effort. \u201cBottom-up alone will get squashed because the higher-level individuals will feel threatened, while top-down doesn\u2019t work because there\u2019s too much organizational change involved,\u201d said Szalvay. \u201cIt\u2019s best if it spreads organically; people will want to do it.\u201d<\/p>\n
A top-down approach, according to Eli Lopian, CEO of Typemock, tells people what the organization wants, but usually lacks guidance as to how they should behave in their new roles. A bottom-up approach is better, he said, because the developers want to learn the practices, get the tooling and become a more responsive, professional team.<\/p>\n
But for this to succeed, \u201cYou need a very strong champion,\u201d he said. Typemock is a provider of commercial unit-testing tools that has adopted Scrum and agile development.<\/p>\n
Once the decision has been made to use Scrum (either on the team level or throughout the organization), it is important to set a baseline as to what it means and what everyone\u2019s roles are. Because of the changes in how people work, Scrum is as much a human resource issue as it is a technical one.<\/p>\n
\u201cYou\u2019re talking about changing where people will sit, who they will be working with and how they work, and you need top-level support for that. But you need developer support as well. They might have had a bad prior experience with agile, or a fear of the unknown,\u201d said Szalvay.<\/p>\n
Training is important for success, the experts said. Vidoni said that when the company transitioned to Scrum a year ago, it brought in Scrum creator Jeff Sutherland and put the development team through two days of training to get a baseline. This way, \u201cat the outset, everyone had a level understanding,\u201d he said. <\/p>\n
Getting the team up to speed at once is important, agreed Richard Cheng, managing consultant at Excella. \u201cBring in someone\u2014either coaches, or with hiring\u2014who knows what they\u2019re doing. People who really get agile generally come to agreement as to how things should be done.\u201d<\/p>\n
Szalvay recommends starting with a pilot team to win support of the higher-ups in the organization by demonstrating success. \u201cPick a high-visibility project, where you can allocate people to a cross-functional project team,” he said.<\/p>\n
“There can be no silos. You need all the roles represented [in the project] in real time. Then, you try to demonstrate the same level of success that\u2019s visible up and down the organization. A lot of benefits can come from this kind of realistic approach.\u201d<\/p>\n
Pat Guariglia, founder of ElegantAgile.com and a certified ScrumMaster, suggested in his blog choosing a project with \u201cmedium criticality\u201d as a pilot. Too little criticality means upper management will blow off the project or not give it the resources it needs; too high criticality leaves little room for failure, placing too much pressure on the pilot team.<\/p>\n
Vidoni cautioned against setting expectations too high too soon. \u201cYou need to get into the rhythm of the format. You should give yourself months to adjust to it before you look for the productivity gains.\u201d<\/p>\n
Joe Little, Certified ScrumMaster, agile coach and managing director of Kitty Hawk Consulting, recommends that teams beginning down the Scrum path be co-located for a while\u2014about six sprints, he said. Further, he would not use Scrum tools to get started.<\/p>\n
\u201cI would learn it with a [whiteboard] in the team rooms,\u201d he said. \u201cMost people later on, with distributed activities, would need some kind of Scrum tool. If you\u2019re widely distributed\u2014which I wouldn\u2019t be\u2014you need a tool. But I don\u2019t think it\u2019s the key to success.\u201d<\/p>\n
One aspect, however, that is seen as a key to success is doing Scrum by the book at first. \u201cEverything is there for a very good reason,\u201d Szalvay said. \u201cYou set up responsibilities for the product owner and team. When people say they don\u2019t want to name a product owner, that leads to all kinds of issues. A product owner makes priority decisions, and you need one person to be responsible to the organization and its customers for that priority. Or, they say they don\u2019t want to co-locate teams. Then they won\u2019t gel, and it leads to bad ramifications.\u201d<\/p>\n
Yet TypeMock\u2019s Lopian admitted his company uses a hybrid mix. \u201cWe don\u2019t have the team and project owner and ScrumMaster definitions,\u201d he said. \u201cWe use managers to think about what needs to be done.\u201d<\/p>\n
There are two schools of thought on Scrum, according to Jez Humble of ThoughtWorks Studios, which make development tools for use in agile shops. First is the school that says you have to do all of it, or you\u2019re not doing it properly. The other is doing what he called \u201ccowboy agile\u201d due to customizations.<\/p>\n
Szalvay suggested that people wait until they have a firm understanding of Scrum and the process before they start to tailor it. \u201cThis way, they\u2019re doing things intentionally and not unwittingly.\u201d He also cautioned against doing \u201cScrum, but\u2026\u201d which he explained as \u201cdoing Scrum, but not this part of it or that part of it.\u201d<\/p>\n
Excella\u2019s Cheng said Scrum can be tweaked to an organization\u2019s needs, \u201cbut don\u2019t lose the heart of it.\u201d<\/p>\n
\u201cIt\u2019s like cooking,\u201d he explained. \u201cWhen you learn to cook, you follow a recipe. If it\u2019s not to your liking, you tweak it so it comes out good. But it could also turn out inedible.\u201d<\/p>\n
But, like cooking, once you have the ingredients in place, it\u2019s important to know how long to keep them on the stove. Time-boxed sprints are an essential part of Scrum, yet estimating how long a task will take can be problematic.<\/p>\n
\u201cSizing is one of the bigger learning curves,\u201d said Pegasystems\u2019 Vidoni. \u201cOur approach to estimation was to take a set of baseline stories of various complexities and to size new tasks to that reference point.\u201d<\/p>\n
Pegasystems has merged business processes with the development process, which Vidoni said provides the benefit of \u201creally assessing what our business priorities are and not over-commit. We\u2019re able to balance our tactical needs with the more strategic business needs.\u201d<\/p>\n
TypeMock\u2019s Lopian agreed that project estimation was an early problem. Scrum advises that sprints take no longer than four weeks. At first, he said, \u201cyou don\u2019t know how to estimate how long a task will be. It could take half the time you allot for it, or it could be three times as long.\u201d<\/p>\n
Trial and error got them down from four-week iterations. \u201cWe went to one week about a year ago, but the development team didn\u2019t feel they could deliver value in that time, so we went back to two weeks. Now we\u2019re more mature, and we\u2019re back to one week.\u201d<\/p>\n
ThoughtWorks\u2019 Humble took it even one step further, with the advocacy of what the company is calling continuous delivery. \u201cIt\u2019s all about keeping software production-ready. Every four weeks isn\u2019t enough. Continuous delivery means having software production-ready all the time,\u201d he said. <\/p>\n
Yet Scrum doesn\u2019t prescribe any technical behaviors for achieving agile success, and that\u2019s either a flaw or a compliment, depending on point of view.<\/p>\n
\u201cScrum talks a lot about process and management of a project, but speaks very little about the engineering side,\u201d said Excella\u2019s Cheng. \u201cXP talks more about that, with continuous integration, test-driven development and pair programming.\u201d<\/p>\n
To address this, Cheng pointed out that the Scrum Alliance is offering Certified Scrum Developer classes. \u201cThey\u2019re trying to penetrate that area more,\u201d he said.<\/p>\n
But Humble, who said that \u201cScrum isn\u2019t sufficient to regularly deliver high-quality software\u201d because it doesn\u2019t look at engineering practices, said the danger of Scrum expanding into technical practices is that it could lose its focus. \u201cScrum has a business focus, and it\u2019s easy to get going on,\u201d he said.<\/p>\n
The fact that Scrum does not prescribe engineering practices is \u201cnot a bug, it\u2019s a feature,\u201d said Kitty Hawk\u2019s Little. \u201cIt\u2019s not clear which will be the right ones\u201d for any given organization.<\/p>\n
One of the key points of Scrum, said Cheng, is that it lets teams do what they do best, without heavy requirements. \u201cYou create partnerships as to why things are being built. You don\u2019t manage people, but give them goals and let them figure out how to get there.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"