{{item.videoDuration}}
{{item.title}}
{{item.videoDuration}}
Agile and Scrum, 101: The every person's guide
Agile is a set of values and principles that can be used with various frameworks (such as Scrum) to enable continuous development and deployment.
Increasingly, it is being used in other areas of business, such as project management and for entire organisational transformations.
Agile gives businesses a competitive edge with which to respond to rapidly changing, ambiguous and turbulent conditions.
For those of us not in software development, scrum masters or hardcore Agile practitioners, it can be hard to understand what exactly is meant by doing things the ‘Agile’ way.
In this article we will put Agile into the language of the layperson, enabling a common starting point to explore its concepts. This piece shouldn’t be used as a guide to the detail of Agile and its related frameworks and methods — indeed a true Agile practitioner would no doubt recoil at the lack of nuance to be found here — but hopefully it will give the rest of us a basic understanding with which to learn more.
The first thing to know about Agile? It does not mean just doing things quicker. While indeed an Agile way of working does allow a company to be more adaptable to change, deliver solutions continuously and work smarter — it’s a lot more sophisticated (and beneficial) than just speeding things up.
Agile beginnings
In 1991, a group of leaders in the software development industry got together and created the now infamous Manifesto for Agile Software Development.1 The document outlines the values and principles that make up the Agile mindset — because in itself, Agile isn’t actually a method of work. When speaking of specific configurations of how to organise (or ‘do’) Agile work, people are using the word Agile as an umbrella term for associated methodologies, such as Scrum or Kanban (more on those in a moment).
Agile is built on four main values: that individual interactions should be valued over process and tools, working software valued over comprehensive documentation, customer collaboration valued over contract negotiation and responding to change valued over following plans.* None of these mean that one should be done instead of the other, but talk instead of where the priorities should lie when facing a trade-off.
With these values behind them, the principles then lay out the nature of approach teams should embody to work together and develop a product. They include: prioritising the highest value, delivering outcomes frequently (weeks, not months), and focusing on excellence and simplicity. Teams should be self-organising, cross-functional, engaged and motivated, collaborate daily (with “face to face” conversations), work at a sustainable pace and embrace change. Crucially, they should also reflect on their effectiveness and adapt regularly.
Waterfall vs Agile
From the Manifesto it is clear that Agile is about embracing a less-restrictive and more-reflective way of working. This reflects its beginnings as an alternate approach to the traditional ‘waterfall’ method of software development. In waterfall, development happens in sequential, linear phases according to a plan. One task is followed by another until the project is done. In comparison, Agile development is ‘iterative’ and the product evolves via feedback as the project goes forward. The details are not locked down from the very beginning, so requirements and solutions from regular testing and customer feedback can change the project as needed.
In general terms, this means that with Agile you have the flexibility to adapt your creation to fit exactly what you require — there’s no costly ‘reworking’ when you get to the end and find that your product doesn’t fit your needs — or those of your end user/customer. In today’s digital landscape, where technology and expectations are constantly changing, this is a huge benefit and allows an organisation to accelerate product delivery, manage changing priorities and increase productivity.
The Scrum framework
So if Agile is a set of principles and values, how then does work get done in practice? Different methodologies (more properly called ‘frameworks’) detail the ways teams will work together in an Agile way.2 Kanban, Lean, and Extreme Programming (XP) are all examples of frameworks that can be employed, but the most popular is Scrum.3
Scrum outlines how teams should work in terms of their roles, how they work (referred to as ‘events’), the work or value created (‘artefacts’) and the rules they will follow.4 It also explains the interaction between these parts.
In a Scrum team, traditionally speaking, there are three main roles. A Product Owner is responsible for ‘why’ or the product vision, they manage what work needs to be done (the 'product backlog’) and the priority that it should be done in, represent the customer (or may be the customer) as well as overseeing stakeholders. The Scrum Master is in charge of ensuring that the team and the product owner (and even the organisation) understands how Scrum works via coaching and helps to maximise team effectiveness and remove impediments.
The development team in an Agile environment, which includes the Product Owner and Scrum Master, is unique. The team is self-organising, working out how to accomplish functionality of the product amongst themselves (this is key) as well as cross-functional (no silos), having all the skills needed — from testing, design, build, operations, etc — to deliver the product. Team members may have different skills and areas of focus, but they work as one, accountable, non-hierarchical unit.
Getting stuff done with Scrum
Scrum uses ‘user stories,’ — clear descriptions of a relatively small piece of work which will deliver value to the end user or customer — to develop the functionalities of the product. These give the team easily understandable parts to implement, that can be tested to ensure they work as expected (via ‘acceptance criteria’).
Different timed events then help the team organise their work without the need for an abundance of meetings.** The ‘sprint’ event, usually a period of a month or less, is where the team will create a usable (or releasable) piece of the product, aka an ‘increment.’ Each sprint must stay within the fixed time, keep quality high and make no changes that would get work off track.
Every sprint starts with a planning session where the team goes through the items to be done on the product backlog and commits to work to complete in the upcoming sprint.** Daily scrum meetings (the ‘standup’) are 15 minutes where the day’s work is planned, progress is checked and any impediments are raised. A review (aka a ‘showcase’) happens at the end of each sprint to inspect the piece of the product that’s been completed and the backlog items that have been finished (called ‘done’ — encompassing a shared understanding of finished quality). Finally, a retrospective session examines how the sprint went for the team, looks at what went well and plans improvements to the team’s way of working for the next sprint.
Agile in other areas of business
While Agile started life in IT as a way to develop software, it is being used more and more in other parts of the business. As a mindset, it is quite flexible, and using methodologies such as Scrum or Lean, can give the same benefits to areas such as HR, or in project management and business analysis. A reduction in command-and-control style management and focus on continuous improvement is being seen in a variety of industries, from media, automotive, production, marketing and HR.5
There is also the option of undergoing a complete Agile transformation. As we’ve discussed in Digital Pulse in the past, businesses are increasingly aligning technology, business and support functions to Agile. This is more than a change in the way of working, it is a move away from top-down bureaucracy, and often incorporates new structures, processes and cultures. Doing so offers reductions in overheads, project failure, meetings and manual processes while optimising workflow, customer value delivered, empowering teams and providing better employee experience.
Such a transformation is a big shift, and leadership that understands the nuances of Agile will be critical to success. It may also be necessary to explore different types of investment planning as traditional methods will not be flexible enough to keep up.
Stepping up the pace
Hopefully this has given you a general overview about Agile, Agile Transformation and Scrum. If you would like to ‘do Agile,' or transform your orgnisational agility, we’d recommend a more in depth understanding — the contextual application to your specific goals, context and constraints will be the difference between frustrating employees and empowering them.
In all areas of today’s uncertain business landscape, the ability to pivot quickly as circumstances change is fundamental to success. The iterative nature of Agile can be a strong differentiator, especially as it can work for both simple and complex situations, in product development and beyond. Implemented properly, it will give businesses a competitive edge with which to respond to the rapidly changing, ambiguous and turbulent conditions they face. It will allow them to not only think quickly, but to act in kind.
*These have been greatly simplified for the purpose of this article, full wording can be found at agilemanifesto.org.
**Events all have specific time durations, dependent on the length of the sprint.
For more information on Agile and your own transformation journey, visit PwC Australia's digital transformation site.
Matt is a partner who leads the Technology Advisory practice in Consulting, PwC Australia
References
- https://agilemanifesto.org/
- https://www.agilealliance.org/agile101/
- http://stateofagile.versionone.com/
- https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
- https://www.forbes.com/sites/stevedenning/2016/08/13/what-is-agile/#68c4c72d26e3
{{filterContent.facetedTitle}}
{{contentList.loadingText}}
{{contentList.loadingText}}