Prior to the tragic events of 9/11, several FBI agents saw suspicious behavior from individuals on watch lists. Each agent witnessed different events, but there was no central source for searches or collaboration, so analysts and FBI field agents couldn't get the information they needed. As it was stated in the 9/11 Commission Report later: "The FBI's information systems were woefully inadequate. The FBI lacked the ability to know what it knew: there was no effective mechanism for capturing or sharing its institutional knowledge." Reports were printed out three times and filed as paper records. Databases were siloed. "We had the information that could have stopped 9/11. It was sitting there and was not acted upon," Senator Patrick Leahy of Vermont told the Washington Post.
In March 2010, Chief Chad Fulgham, the CIO of the FBI, and Jeff Johnson told the Department of Justice Inspector General that they could not only complete the massive IT modernization project that had already cost taxpayers hundreds of millions of dollars and had ended up twice in a complete dead-end, but could do so by cutting down the number of developers, bringing them in-house, and delivering the most challenging half of the project under budget and in less time than projected by the previous project team. The skepticism was palatable.
However, they pulled it off by July 2012 — less than 2 years after the project landed on Jeff Johnson's desk. By tossing the current project management approach overboard and turning to a more agile, or lean, way of dealing with the problem, the team was able to deliver a product quickly and with fewer resources.
And while Sentinel wasn't perfect, the impact was dramatic. It provided the FBI with the ability to communicate and share information so effectively and efficiently that it significantly altered what the FBI can do! But project Sentinel was far from completed — in accordance with the new project management approach, it still undergoes fast, iterative improvement cycles.
There are countless other stories like this one that illustrate how powerful this different, new way of thinking about a project can be — e.g., making ATM machines profitable or timely reporting from the Arab Spring in Egypt when the NPR reporting team was cut off from Washington.
How could a new approach to project management make such a significant difference when dozens of smart people had spent months creating and pouring over color-coded Gantt-Charts that precisely mapped out every step of the project down to each sub-task? If something that detailed couldn't manage a project of these proportions, how could SCRUM do it?
When you are planning a project, you have basically two ways of going about it: you can use the traditional Waterfall Method or SCRUM. Before we get into why you should manage your website redesign using SCRUM, let's look at the traditional way to manage projects and compare it with SCRUM.
The Waterfall Method "is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance", according to Wikipedia.
The emphasis of the Waterfall methodology is on the subsequent and non-iterative process of mapping out all tedious, sequential steps involved in creating larger projects in beautifully color-coded Gantt Charts that have become increasingly popular with the increasing popularity of personal computers in the 1980's and Excel / MS Project.
In theory, it is supposed to reduce costs at later stages of the project by spending enough time early on in planning, gathering requirements and building in buffers for eventual difficulties.
And since human beings crave predictability, this makes even the most risk-averse among us feel comfortable and safe in believing this project will be on time and on budget.
However, the problem with Gantt-Charts and the Waterfall Method is that they are great in theory but unravel as soon as the project faces reality. The model is incapable of dealing with changing project requirements or input from the outside, e.g., user feedback. This results (worst case scenario) in the project being not only over-time and over-budget, but so far removed from the user's requirements that it becomes unusable — shelfware. While in the best case scenario, the project is still over-time and over-budget, but also produces a sub-optimal product that doesn't properly meet the user's needs.
Now I know the technical term "SCRUM" can scare some marketers, but in reality, it isn't that technical. SCRUM was coined by Jeff Sutherland, a Vietnam War pilot veteran and one of the co-writers of the Agile Manifesto in 2001, who was always looking for a better way to manage projects.
His inspiration for SCRUM came from a research project while pursuing his Ph.D. in Biometrics. He tried to find out what makes healthy cells change into cancerous cells. He found that as cells go through normal development stages (from one stable state to another), they become unstable for a short period of time. This chaos mostly results in the desired outcome (the new cell state), but not always. Sometimes things go awry.
In his life, he worked a lot with system theories, and he observed that the same thing happens in organizations and people: First there is chaos without any apparent rules, and then the system settles into a new (hopefully better) state. The term itself comes from the rugby term "scrummage", during which a team attempts to restart a play and gain possession of the ball by packing closely together with their heads down. They all "put their heads together" to move with one transcendent purpose.
SCRUM is a simple-to-understand, however often difficult-to-master process framework that can be used to "address complex adaptive problems, while productively and creatively delivering products of the highest possible value," according to the Scrum Alliance.
In contrast to the Waterfall Method, SCRUM is not a linear or sequential process used to build products, but rather a framework that deploys smaller, iterative cycles or sprints to manage complex product development.
Here is a quick overview of why SCRUM works:
Jeff Sutherland describes in his book, "SCRUM — The Art of Doing Twice the Work in Half the Time", how he was called in to help. He addressed 150 engineers and told them that unless they moved to a more customer-responsive development model, they would go under. They discounted his ideas for yet another management fad and shot him down. As he left, Sutherland shrugged and said, "Change of Die!" Well, you know what happened to BellSouth.
While this sounds dramatic, the results are speaking for themselves: on average, SCRUM projects are 300% more successful than Waterfall-managed ones.
If SCRUM is so successful in other areas, is there a way we can borrow this powerful framework and apply it to websites? The reality is that not only CAN we, but we MUST! The scope and complexity of websites have evolved so significantly, and companies need to adjust their online marketing strategies so quickly that it makes no sense to push their designing and development into a linear process that takes months.
In the past twenty years, websites have undergone a tremendous evolution. Most big businesses used websites mainly for informational purposes, like relatively static online "billboards" that included About Us, Contact Us, Portfolio and some services pages. The more advanced websites had an archive for press releases and company news, but most of the time, the entire website had a very limited number of pages that usually was the same for each website — no matter the size, the industry or the business mentality.
Due to the technical limitations of the internet and the lack of differentiation, a linear process, like the Waterfall method, was all that was needed to manage website design projects. However, since the launch of Amazon as an online bookstore in 1995, things have changed significantly. The first Amazon website was already ahead of the curve. It included a personal notification service, customer reviews, and a way to discover over one million book titles.
Since then, websites have increasingly become more interactive, more personalized and more customer-focused. They have become a real-time communication tool. They are suggesting products based on previous shopping preferences and even allow you to build customized versions of the base products with a few button clicks.
To create these kinds of websites, you cannot simply gather your list of requirements and start developing them using a sequential development process.
The average website redesign takes somewhere between 3-5 months and won't undergo any major changes for another 18-24 months once launched. That means, by the time you launch your brand-new website, your requirements have already changed. For example, your competition has launched a game-changing new tool or your customer support team lets you know that your visitors are struggling with the check-out process.
In fact, the single biggest reason why websites are constantly over-budget and over-time is because of scope creep. Reality hits once the website design process has started and now the team is faced with an ever-changing set of requirements. Instead of figuring out what will actually work or what is demanded by the user vs. a subjective request from the management team, the web design team will just add it to the list. Once completed you are stuck with the result for another two years or so. It simply seems narrow-minded and counter-intuitive.
If you have read this far, you probably understand the importance of changing the way we approach web design and development. If I wanted to achieve one thing with this post, it was that — so, thank you!
The great news is that there is already a tried and proven SCRUM-inspired methodology developed for the web design and development process called Growth-Driven Design. The term Growth-Driven Design was coined by Luke Summerfield, HubSpot's Chief Evangelist for Growth-Driven Design in 2015. It describes the application of SCRUM to the web design process and brings together critical elements such as usability, inbound marketing, and conversion rate optimization under one unifying methodology:
Growth-Driven Design is an iterative and incremental framework for website design and development that minimizes the risks of traditional web design. Through its strategic and systematic approach, it shortens the time to launch by focusing on real impact as well as continuous learning and improvement — leading to tangible business results.
The process is simple enough: after an initial short strategy phase, the team brainstorms a list of requirements, which get categorized and prioritized, and agrees upon some basic fundamental assumptions as well as a few other guard rails before diving into the development of the launch pad website. The quick launch of a website that will make 80% of the impact with 20% of the investment within the first 45-60 days is critical as it allows the web design team to get valuable user feedback. Now they will organize in monthly sprints to tackle the top priorities of the brainstormed list, always keeping contact with the actual users. As priorities change, they can be added to the prioritized product back log.
Ready to learn more about how Growth-Driven Design can help you get the peak-performing website you need? Great! Click below to schedule a quick chat with me!