By Rafael Sabbagh
The world faces one of the worst financial crises in history. Several European countries, the United States, and Japan are already in a state of recession. The International Monetary Fund (IMF) recently stated that the recession will continue to deepen and the recovery will be slower than in the past. As a consequence, emerging and developing economies such as India and Brazil will suffer massive net capital outflows. IMF also said in a forecast that the world economy will shrink 1.3 percent in 2009.
Forrester and Gartner predicted technology investments will suffer a drop of 3% or 4% in 2009, respectively. Particularly, spending on IT services will fall this year. Companies like Toshiba and Nokia recently reported losses or drastic profit drops, and plan to fire thousands of workers. Intel saw their stocks plunge. Even the internet giant Google, which seemed untouchable, reported its first-ever drop in quarterly profit and cut hundreds of jobs.
The New Scenario for Projects
In this environment of uncertainty and constant changes, project market players are facing resource rationalization, limited access to credit, margin pressure, and financial problems with most clients. The decision process becomes longer and the demand for projects is notably shrinking. This new configuration demands that organizations change the way they work in order to survive. A true paradigm shift is necessary. Surviving IT organizations will exhibit the following characteristics:
- Work well in rapidly changing environments, allowing frequent replanning;
- Focus on maximizing the client's return on investment (ROI);
- Help reduce time-to-production or time-to-market;
- Avoid wasted effort and time with subproducts and features that will never be used;
- Always deliver value to the client, even if the project needs to be halted before its end;
- Increase the communication and feedback between the project's stakeholders, so people will know what needs to be done and what's being done.
Scrum is a framework for project development that focuses on all those issues. Scrum is the best choice for projects in times of crisis.
Why Scrum?
Let's look at the players in the project market within a financial crisis context:
- An organization or group that provides service on projects. It must increase competitiveness in order not to lose clients, both internal and external;
- A director or manager needs to cut operational costs so that his organization may survive. He chooses to use internal projects focused on getting better results;
- A client needs to outsource specific projects but needs to cut costs in order to keep them viable.
We will provide important arguments to help these parties (as well as other decision makers and those who can influence them) defend the choice of Scrum for their organizations in turbulent times.
No Waste!
Traditional methodologies spend a meaningful part of the cost and time of the project generating and maintaining massive documents. However, once complete, these artifacts are rarely updated as much as necessary, because changes occur faster than the team is able to keep them current. In the end, a great part of that documentation becomes useless and ends up being dismissed.
In The Enterprise and Scrum, Schwaber states that about 50% of a typical project's time (and money) is spent on requirements, architecture and specifications, and all that is done before building any functionality. However, 35% of the requirements change and 65% of the functionalities described by the requirements are never or rarely used. In times of crisis, such waste of time and effort is not acceptable.
Scrum reminds us that the objective of a project is the product - not the documentation. On Scrum, desired features are captured in a prioritized list called the Product Backlog. The exact specifications and design for each feature on this dynamic list is determined only a few weeks before it will actually be worked on. Features can be added, removed, or reprioritized throughout the course of a project. They are always kept in priority order. A new set of functionality is delivered at the end of each timeboxed iteration, or sprint. Therefore, whatever is delivered has a much better chance of actually being used by the client.
Better Value First!
On a typical waterfall project, the client may wait up to a year before he ever sees a finished product and begins to receive any return for his investment. In today's economic environment, companies can't always wait that long.
Scrum, on the other hand, delivers a return on investment at the end of each sprint. One of the Product Owner’s main roles is to maximize ROI by constantly updating and prioritizing the Product Backlog. This allows the items of most value for the client to be implemented first. Prioritizing the Product Backlog based on value allows the organization to stay competitive by delivering results to its clients faster than the other players, by putting in production functionalities that add better value to their businesses more quickly, or by launching products and new versions more frequently, so that they keep up with the inevitable market changes.
May Changes Come!
Speaking of inevitable market changes, at no time are there more sweeping and frequent market transformations than in times of crisis. Legislation and regulations are created, business rules change, new opportunities appear, important players leave the market, previously available budgets become scarce, companies face big losses, mergers and acquisitions increase, governments intervene to maintain stability.
For traditional methodologies, where change is undesirable, risky and expensive, this kind of upheaval is almost impossible to manage. It creates stress on the project team as well as stress on the relationship with the client.
Scrum follows the Agile Manifesto assertion that responding to change is more important than following a plan. Scrum maintains that change is a natural part of the development process. It has mechanisms in place to make change a constant, rather than a stressor. The dynamic nature of the Product Backlog allows client’s new requests to immediately be introduced on the product by the following sprint. Such quick response to change becomes a great competitive advantage, making it possible to turn a crisis into an opportunity.
Parcels or Partners?
On a typical waterfall project, the client is encouraged to participate at two times during the project: at the beginning for requirements analysis and in the end for the acceptance tests. The client perceives the project as a big package stamped "Do Not Open Until..." , whose contents will be revealed solely at the end of the process. Their only glimpse into the future product is through documentation, most of which is out of date or out of touch with changing requirements. In today's fast-paced, ever-changing market, it's unlikely that what the client asked for in the beginning will fulfill his needs in the end.
On a project that adopts Scrum, the Product Owner is always in touch with client to identify his needs and keep the Product Backlog constantly updated and prioritized. The client frequently gets new versions and can give feedback more quickly to the team through the Product Owner. The client feels involved with the whole process, sharing the responsibility over the project with the team, increasingly trusting the team and the process itself. The relationship with the client ceases being merely commercial and instead becomes a partnership, fostering complicity, satisfaction and fidelity. A long-term relationship is then developed with the client, which can often overcome strong periods of crisis.
Communication doesn't just happen between the product owner and the client. Everyone involved with the project is given a daily glimpse into what the team is doing. Daily meetings allow members of the team to show other members what they’ve done since the previous meeting and what they will do until the following one. The sprint backlog or kanban shows everybody all the activities yet to happen, those already happening, and those which are finished. Working in a collocated environment stimulates teams to communicate. Burndown charts show everyone the project’s progress. Frequent demos show the Product Owner what’s been produced and give opportunities for feedback. Finally, retrospective meetings allow everyone to see what has worked on the sprint and what can be improved.
Keeping communication open between the project’s stakeholders is the best way to assure that everyone knows what needs to be done and what’s being done. That increases productivity, which is essential to surviving a crisis.
What if the Project Gets Suspended?
In times of crises, it is common for the budget to dry up or the supplier to leave the market during the project. When this happens on a non-agile project, what will the customer be able to deliver to the client?
If the project gets suspended right after the initial phase of specification, the client gets a series of documents that won’t be of any use to him. In case it happens in the middle of implementation, he will get incomplete and untested functionalities. Even if it happens in the middle of the tests phase, the product hardly will be trustworthy. In fact, chances are the client won’t be getting any return whatsoever on the investments made if the project is stopped prematurely.
A project with Scrum always produces an increment on the product which is potentially deliverable at the end of every sprint. If the project gets suspended at any moment, the client may utilize what has been generated on previous sprints, minimizing his risks. On an environment of uncertainties, that becomes an important competitive advantage.
What if You Have to Cut Down the Team?
In periods of crisis, it may be necessary to dismiss or relocate members of the team. With waterfall, roles inside the projects are very well defined. On an IT project, for instance, the programmer programs, the tester tests and so on. So, if the designer leaves the project, new windows will have no graphic design; if the tester leaves the project, it will go untested; and, worse of all, if the project manager leaves it, it will go ungoverned. Therefore, the whole project’s success is threatened by the loss of a team member.
With Scrum, responsibility over delivery belongs to the whole team, no matter the roles. Although there is a natural specialization, people are stimulated to develop and utilize their secondary abilities and, in general, will do their best to compensate for the lack of team members. This way, even with less capacity, the team can keep delivering.
It’s important to point out that firing members of the team must never be the first alternative for cutting costs. Shrinking the team also diminishes its capacity to deliver value. Consequently, the client will be less pleased and will search for suppliers that can provide him better service. That makes the organization’s situation worse, creating a vicious lose-lose cycle.
Conclusions
Scrum is the best choice for projects in times of crisis. It surpasses other methodologies for working well on an environment with constant changes, for frequently delivering better value to the client, by focusing on maximizing return on investment, by avoiding waste and prioritizing communication and visibility to what is important for the good developing of the project, and by creating a cross-functional team.
Once the crisis is over, organizations that adopted Scrum will be closer to their clients, focused on results, more compact, objective and transparent. To these organizations, the crisis will have worked like a propelling spring, so that when market recovery comes, these organizations will be ahead.
