In Part 1, we explained the difference between the waterfall and agile models for managing the specialist work in software projects.
Now let’s throw a spanner in the works by looking at an example of a common phenomenon in respect of popular frameworks, methodologies and other ‘systems’. Using Scrum as an example, we discuss why the endeavour of ‘getting some new thing going’ often goes horribly wrong—and how to prevent this from happening.
As we mentioned in Part 1, the subject of the article is complex, and some Information Systems specialists may find our explanations annoyingly simplistic, or “not so true where I work”. We’ve written it, though, to open a window to lessons for both those who are familiar with the subject and those who encounter it here for the first time.
“Scrum is a…”
Scrum is an agile framework. In it provides a set of practices and guidelines to lead specialist teams in an agile way. The working day typically starts with a Scrum meeting led by a Scrum Master. In this meeting, the team determines what everyone is going to work on that day. The team members then go off to do their work. After a predetermined number of days (called a sprint), the Scrum Master presents the provisionally finished product to a decision-maker, and after that, the next sprint begins. In the next sprint, the product produced in the previous sprint is refined, or new parts are added to the product. There are several such sprints in a project.
There are Scrum user groups all over the world, and you can even earn formal credentials in Scrum.
Now for the twist in the tale.
We typed the words “Scrum is a” into Google, and these are the predictions which came up, based on what other Google users typically type into the box…
Huh? But why?
There are a number of reasons. Below, we give two examples. At the end of the article, we explain the basics that must be addressed to prevent a “waste-of-time implementation” of Scrum, or of any other framework or methodology.
A false dichotomy
Some people mistakenly think of Scrum as a replacement for Project Management. The waterfall model looks similar to a traditional Project Management lifecycle, so people sometimes think that “Project Management” and the waterfall model are the same thing. They believe that if they throw away “traditional Project Management” and use Scrum instead, they will be saved from the problems they had when they were still working to rigid deadlines, fixed costs and a clearly defined scope.
Now, the way in which projects were managed before these people “got Scrum” may indeed have been quite nasty. We often find that people who see Scrum as an alternative to Project Management don’t really know what the discipline of Project Management is supposed to entail. Project Management is the integrated management of stakeholders, scope, quality, time, cost, procurement, communications, human resources and risk. The Scrum framework deals with only a few of these areas. So when Scrum is brought in to replace Project Management, people typically fail to give due attention to important aspects of a project.
So, although Scrum is supposed to help us get products out faster and more cheaply, it can easily turn into a longer, more expensive project after all.
Legalism and lip-service usurp principles and values
The Agile Manifesto is a statement of beliefs and values.
The Scrum framework is one of a number of frameworks that was designed to give guidance on how these beliefs and values could be put into practice by a team of people working together in the same space.
Unfortunately, as these frameworks became formalised (with a ‘priesthood’ in the form of Certified Scrum Masters and other credential-bearing roleplayers), a change took place within the new ‘religion’. Rules and jargon began to take the place of the spirit behind the Scrum framework. Wisdom gave way to legalism. Ironically, then, while agile processes are supposed to be people-focused and flexible, some Scrum devotees become set in their dogma, unable to see the value of other people’s ways of thinking.
Lessons from this ‘waste of time’
A similar thing often happens in the realm of Project Management beyond the software development industry. People often see a software product (such as Microsoft Project) or a methodology (such as PRINCE2®) as the solution to their problems. (The custodians of PRINCE2® refer to it as a method. For consistency in comparisons to other highly formalised approaches, we call it a methodology.)
The ‘new system’ is implemented with a great deal of hope, but in the end it just adds more clutter and red tape to an already dysfunctional environment.
The consequence of such a failed implementation is an organisational culture characterised by cynicism.
The problem is often not with what was implemented, but with the who, when, how and why.
It is not necessary to change. Survival is not mandatory.
— W. Edwards Deming
The wry quote above shows us why change is essential. But it’s also essential to think carefully about what to change and what to change to. Wrong ideas about the problems lead to inappropriate solutions, which create more problems.
In Part 1 of this article, we said that the change must be a good fit for the culture of the organisation. Put simply, culture means “the way we do things around here”. Sometimes the culture of the organisation isn’t ready for any new framework or methodology, even if a change really is needed. In such cases, it is the culture that must change if we want to introduce major improvements.
Getting the basics in place first
What are the basics?
The kind of culture which makes a successful implementation possible has several key characteristics. These include:
- critical thinking, contextual thinking and systems thinking;
- personal mastery;
- team learning;
- a shared vision; and
- the practice of timely risk reporting and mitigation.
Most of these are characteristics of a learning organisation (a term coined by Peter Senge and others).
How is this done?
Changes in organisational culture are the result of focused efforts by a resolute top dog.
When an organisation invites us to support them improving their management of projects, our first focus is to understand the organisation’s existing culture. (We must figure out what effect this culture could have when the organisation tries to move from the present reality to the envisaged future reality.) We don’t work on “getting buy-in” from the top dog. Instead, our efforts go into ensuring that we’re working with a resolute top dog.
As the process unfolds, individuals in the organisation may start to experience the exhiliration of the synergy between their personal growth and the growth of the team.
Successful Project Management isn’t driven by the implementation of fancy systems. Rather, it is an environment enabled for teamwork and transparency that will lead to the best choice of systems, and to making them work in practice.