Agile basics: Scrum

Peter Strempel

The value proposition of agile methods is speed of incremental delivery, trimming away of bureaucratic overhead, and more productive teamwork than conventional project interactions.

Like all value propositions, it’s contingent on being aligned very tightly with a strong customer-focused value stream–meaning that every step in the ‘sprints’ and processes driving an agile method must add value.

My experience is mostly with the Scrum method.  If Agile is a framework or state of mind about teamwork, Scrum is a specific way of implementing that framework, or of turning a state of mind into practice.

Scrum

As the name implies, the method revolves around a team scrum, the rugby method for re-starting play after some types of infractions.  Unlike the rugby practice, no one is injured in an Agile scrum, which is really about bringing teams closely together to drive development or other efforts, in small sprints, towards an iterative completion, being the satisfaction of the client demand.

You could think of this as breaking a traditional project stage into even smaller pieces.  As well as removing some of the more formal project overheads, like documentation, reporting requirements, navigating an entire change management process, and updating the variety of registers and schedules usually associated with projects.

Agile and Scrum are terms often applied as if synonymous with software or systems development, because that’s where these approaches are most commonly applied.  However, the popularity of the approach has seen it spread into other kinds of projects.  My experience with Scrum has been around integrating software and systems development into wider change projects.

It’s easier to talk about Scrum by visualising its various components and processes, so I have prepared Figure 1 below.

Scrum architecture
FIGURE 1: a simple Scrum architecture.

Let’s assume that projects are initiated the usual way, by business case and sponsor approval, a Scrum project is driven largely by the following team players–

Product owner: a high-powered individual responsible for all aspects of the product, including especially the product backlog of known client requests and specifications.  The product owner also represents the client by maintaining a sharp focus on client value at all times.  This individual has many of the characteristics of a visionary leader, senior project manager, and everyone’s favourite go-to confidante.  But the product owner is more like an ITSM service owner than a project manager, more like a business analyst than a developer, and more like stakeholder manager than a team leader.

Scrum master: the person who injects the necessary minimum discipline into the Scrum teamwork efforts by undertaking most of the work traditionally performed by a good project manager.  Responsibilities include facilitation of daily scrums, planning the sprint meetings, limiting overreach or scope creep, acting on sprint reviews and retrospectives where necessary, and maintaining the Scrum board–a cork-board or wall, or a piece of software that shows all work in progress and sprint items to come.  In addition, the Scrum master may also be tasked with managing the team in meeting individually with team members to address any frictions or performance issues, offering internal consultancy on a range of project issues, mentoring younger or less experienced team members, eliminating external roadblocks to meeting goals, and motivating the team whenever spirits are low.  I have functioned as a scrum master, using my business analysis and project management experience.

The Scrum team: this could include solution architects, developers and programmers, business analysts, and so on.  But in a Scrum team no one stands on titles.  Everyone pitches in to a sprint wherever and however they are able.  Team members learn from each other how to solve problems most effectively, and aspire to self-direction and self-correction.

It is best to co-locate such teams for the duration of the project so that communication is free and open.  And also to promote team cohesion when Scrum team members are drawn from various other functions and operational teams.

The Scrum team may come together for a variety of purposes of its own devising, but in Scrum three kinds of meeting are mandatory–

Sprint planning meetings map out who will do what to use which inputs for what outputs.  These meetings should be limited to between one and four hours, conducted before each new sprint, and include a meaningful summary by the product owner of the state of the backlog. The product owner should also pass on all stakeholder feedback, and any other input necessary to maintain focus, or to refocus on client value.

Daily scrums or standups, often conducted while standing to keep them brief and focused, where everyone talks briefly about what they will do today to advance the sprint objectives towards the increment (the deliverable of the sprint).  This is also where everyone can raise problems encountered yesterday.  The scrum master musty keep a tight rein on these meetings by shutting down off-topic issues, but should follow up on those later if they indicate important insights or obstacles.  Daily standups might centre on a Scrum board–the visual representation of all items that need to be completed for the current sprint, and any other work in progress (WiP).

Sprint retrospectives and iteration reviews.  In Scrum, a sprint is generally the same thing as an iteration, but that isn’t always the case in other agile methods.  The retrospectives after about feedback from all stakeholders to drive lessons learnt and continuous improvement planning.  To ensure this is more than formality and words, the Scrum master should develop and drive agendas developed for such improvements.  Iteration reviews are the showcasing and celebration of increments.

Another critical element of the Scrum method is the user story.  This is a very brief narrative description of how a specific kind of user might want to achieve what task.  A user story should be a statement in metaphor of the user value embedded in all work, and in the increment of the day.  User stories might be told in pictures, or even video clips of rôle plays, and there can be a number of user stories for each sprint, but they must be unambiguously about the project’s value stream.  Users in such stories are rarely real people rather than composites by rôle, or by personality, or by some other generalisable user focus.

In Figure 1 above, I have described the process pursued by the Scrum team as iterations of product backlogs and sprint backlogs.  Iterations being cycles of repetition, the product backlogs need to be updated as sprints elapse and client requirements change.  The same is true for sprint backlogs, albeit subject to shorter cycles.

Variations on a theme

One of the reasons Scrum is a popular Agile method is the relatively uncomplicated overview that all team members can gain and maintain.  This simplicity is illustrated in Figure 2 below.

Scrum roadmap
FIGURE 2: the Scrum ‘roadmap’ is very simple to keep front-of-mind.

The diagram is adapted from various sources, and shows that a relatively few elements can be shuffled, expanded, or collapsed to suit many different types of project and other teamwork-driven efforts.

Another popular Agile method is ‘Kanban’, after a Japanese word for signboard or billboard.  Kanban is not necessarily iterative, like Scrum, but focused on similar goals (client value), and uses visual cues, like lots of sticky notes, coloured paper, or software, to–

  • Visualise workflow
  • Limit work in progress (WiP)
  • Stop starting (beginning new things too often)
  • Start stopping (finishing WiP)

The method became highly effective for Japanese just in time (JIT) manufacturing, and remains a good fit for projects where work packages arrive unpredictably, and deliverables are offered as they are completed, as opposed to waiting for a batched delivery.

Critiques

The first and most serious critique I’ve heard of Agile in general, and Scrum in particular, is that it reinforces ‘brogrammer’ culture and alienates women.  I think this is a serious critique often reflected in the blokey culture of development teams, but not a characteristic of the method itself, even if Scrum is a football term.

It becomes the responsibility of the Scrum master to wash out discriminatory attitudes from individual team members and the team overall.  And I have undertaken that rôle in the past in a team where frictions existed across gender as well as cultural lines.

Traditional project managers and teams also sometimes criticise development teams using Agile methods as justifying bad programming (dodgy increments) and immature approaches to work ethic and discipline.  I have seen that happen.  Again, though, the governance part of projects that seems stripped away in agile environments is the responsibility of the product owner and Scrum master to watch over and enforce when necessary.  Other critiques that focus on appearance rather than substance are probably more about maintaining a formality of workplace culture than about deficiencies in client value.

There is also murmuring about high-minded Agile values and principles not being reflected in the normal spread of flawed human behaviours in Agile teams.  There is no doubt in my mind that this is often true.  I have seen many nominally Agile teams behave just as dysfunctionally as more traditionally structured project teams.  And I have yet to see a project manager, product owner, or scrum master empowered to sack a team member for corrosive behaviour patterns.

As a project manager I would always try to counsel one or more team members who make it hard for others to achieve their goals, and to replace those team members where counselling doesn’t help.  However, the last resort usually falls to senior managers of the host organisations.

If you are interested in applying Agile methods to your project needs, contact me to discuss your needs.