Please Note:
This article is only available until July 29th for non-members
Get unlimited access to this article as well as to 560 how-tos, more than 800 Case Studies, and 300 interviews just setup your MarketingSherpa Membership free 7-day trial.
A redesign or tweak of your website by IT developers never goes easy, and it always takes longer than projected -- right? Wrong. There is a way to make upgrades without turning your life topsy-turvy. It’s called Scrum, and it may even make website redesign easier and faster – and done, perhaps, on time.
Typically, your IT team has used the Waterfall project-management system -- where all planning is done up front, followed by design, testing and launch. Matt Raines, VP Technology, Bluefly.com, has used Waterfall to build a website or add features for the online retailer of designer clothing, handbags, shoes and accessories.
In mid-2007, however, Raines and his colleagues used another project-management approach to develop a new checkout service on Bluefly.com. The method is known as Scrum -- a term borrowed from rugby.
Scrum divides work into specific chunks of time. This schedule continues until the project’s completion. Since adopting Scrum, Raines says his developers:
o Roll out smaller product features faster, rather than waiting for a full project launch
o Have more agility in prioritizing work
o Communicate better with management
o Beat their launch dates
As an example, Raines says, he used Scrum to implement Google Checkout for Bluefly. “Essentially, we did that whole [checkout service] project in about six weeks, which we had originally estimated [to take] at least eight weeks of work.”
The checkout project involved transferring Bluefly customers’ shopping carts to Google to complete orders. When Google sends a notification that an order is complete, Bluefly ships the merchandise. Then, Google bills the customer, withdraws a percentage and sends Bluefly the remainder. This entire process had to be automatic and simple from users’ perspectives.
Find out the differences between Waterfall and Scrum and Raines’ tips for making website transitions far less painful.
Waterfall – The Standard SystemWaterfall is a sequential project-management model created almost 40 years ago to develop software. Each step in this process must be finished before moving to the next one. And, there is no going back – waterfalls can’t flow backward – to revise earlier steps.
Many users like Waterfall. They say it is linear, easy to understand and encourages early planning. There is also an emphasis on documentation since the list of requirements remains as a blueprint throughout the process.
Others are not as smitten. They say that the software requires perfection before moving on to a next step – an almost impossible goal. Also, modifications have to wait until the process is complete; you cannot move back to step one to add more features without affecting every subsequent step.
Waterfall also forces all features to launch simultaneously – at the end of the process.
Scrum – A New AlternativeRather than emphasizing planning and design, Scrum focuses on getting people to work faster.
“You’re not looking for every single thing to be documented up front. You don’t have a big project plan. It’s not like you have your 842 tasks that you have to get done,” Raines says.
Work is done in intervals called “sprints.” Raines sets his sprints at two weeks. After each sprint, a project can be altered and another sprint can begin. “That means we come together every two weeks” and decide what will be completed during the next two weeks, Raines says.
After a certain number of sprints, a feature is released. This continues until the entire project is completed.
Organize Your Scrum TeamScrum is more complicated than Waterfall, and it requires a unique set of roles, meetings and documents:
->Roles
o Product Owner
Scrum calls the business owner a product owner. It “basically puts the business owner back in the driver’s seat,” Raines says.
Before a project begins, a product owner needs to create:
- Vision for the product
- Business plan that describes anticipated revenue streams
- Road map that plans several releases
- Product backlog or a list of features prioritized by value to the customer
The owner also decides release dates, is responsible for ROI and can accept or reject work results.
o Scrum Master
This individual is in charge of the team’s success and represents a team to management. Scrum Masters meet every day with their teams to discuss progress on the sprint.
“They are the ones trying to move impediments that are not productive to the team and encouraging or re-encouraging the things that are helping the team to be more productive. And [they] make sure that, ‘Yes, we are going to hit our goal for this two-week sprint,’ ” says Raines.
o Team
The team works on and completes projects. Its members organize and meet to discuss the progress of a sprint. They decide how much work they can take on in one sprint. Depending on the size of a business or department, there can be multiple teams. Raines prefers a team with about seven members. A typical size is 5-9 designers and developers with cross-functional skills.
Develop Your Schedule-> Sprint planning meeting
This meeting determines what work will be done during a sprint. The Product Owner reviews the vision, road map, release plan and product backlog with the team. The team considers the priority of items on the product backlog, and decides which items can be completed in each sprint based on its length. After this meeting is complete, the sprint begins.
-> Running the Sprint
Team members work on the goals of the sprint. They usually range from 15 to 30 days in length.
-> Daily Scrum meeting
The Scrum Master leads this 15-minute meeting for the team members to assess their progress on the sprint. Every team member answers: “What did I do yesterday? What am I going to do today? And what’s in my way? What are the impediments blocking me from moving forward?” says Raines. “There is nowhere to hide in this. It’s almost full transparency from a development process.”
-> Sprint review meeting
After every sprint, a review is held. The first half of the meeting is directed by the Product Owner who reviews completed items on the product backlog. Everyone discusses how to reprioritize the product backlog for the next sprint. Finally, the objectives of the next sprint are set.
The second half of this meeting is a retrospective for team members to look at what they did during the sprint and how the team can better function.
-> Release scheduled
After a predetermined number of sprints, a release is scheduled.
“Let’s say you want to do a release once a month. What you would do is essentially two sprints worth of work, and put those together into a release and release that out” to its destination, such as your quality assessment team, says Raines.
A release can be done each month, quarter or year. “Each organization is going to be different.”
How to Deal with Pitfalls: 4 LessonsRaines first implemented Scrum indirectly. He was under a tight deadline and could not afford the time to map out requirements and designs.
“We basically just started by jumping straight into implementation without answering any of those questions up front and iterated through that implementation process.”
This sink-or-swim approach taught Raines some hard lessons:
Lesson #1. Push collaboration
“The most critical mistake that I made was assuming that everybody would just love and adopt Scrum,” Raines says. “Because we were coming at it from a very top-down standpoint, I wanted to basically push and encourage those teams to become those cohesive units that would come together and be highly communicative, really strive for quality and sort of bring people together.”
That took a very long time to happen – longer than he expected. “I most certainly underestimated all of the impacts and all of the consequences of changing a development methodology, one that was really designed to be a bottom-up but implementing it top-down.”
Lesson #2. Change roles diplomatically
Eliminating or changing typical managerial roles and accepting titles like Scrum Master and Product Owner can be hard to swallow. It can cause friction.
“In the past, there were these lead developers or these people that were in sort of these prominent positions, and that all went away. Basically, everybody is just a part of the team,” says Raines. “I think a lot of people had, from an individual standpoint, a loss of identity.”
Lesson #3. Hire a coach
Scrum can be confusing at first. That’s why Raines hired a consultant to help his company identify snags in their process.
The coach would “sit through our planning meetings, see how we’re operating. Because, a lot of times, once you get into the regular flow you forget … and lose your way a little bit off the process. [The coach] helps bring you back.”
Raines says his coach came in quarterly, and it cost about $200 an hour. “You need to remember that you’re bringing them in truly as an investment and really trying to push that efficiency back down to your entire development process so that you can get more out the door.”
Lesson #4. Educate coworkers
One reason Raines experienced some pushback from coworkers was the fact that he didn’t educate everyone as well he could about the process from the beginning, he says. They fixed many problems by taking more time and investing resources to better educate the staff.
Education included holding presentations, distributing materials and hiring a consultant to come in to speak and answer questions.
Matt Raines will be speaking at eTail in Washington, DC, in August. For details on upcoming conferences, go to http://wbresearch.com/etail/ Useful links related to this articleScrum Alliance: Your trusted source for Scrum knowledge
http://www.scrumalliance.org/
Wikipedia: Waterfall model:
http://en.wikipedia.org/wiki/Waterfall_model
Wikipedia: Scrum (development):
http://en.wikipedia.org/wiki/Scrum_(development)
Wikipedia: Scrum process image
http://en.wikipedia.org/wiki/Image:Scrum_process.svg
Bluefly:
http://bluefly.com/
