Is Agile and Scrum applicable outside of software?
Is Agile older than the Internet? Software development anthropologist Gerald Weinberg, the author of The Psychology of Computer Programming and Introduction to General Systems Thinking, remembered introducing incremental development for the first time in 1957 in Los Angeles at IBM. Evolutionary and adaptive approaches emerged in the early 1970s, and all the methods that are now described as Agile have been in use since the 1990s. But the actual Agile Manifesto came out in 2001, the Scrum Guide was published in 2009, and just during the last years, this concept became such a buzzword and gained mainstream recognition as a way to boost corporate responsiveness. Why's that?
Why adopt the Agile approach?
As a general mindset of getting work done, Agile is pretty straightforward, universal, and versatile: we need to adapt to change quickly, know our maximum capacity, and be transparent about what we're doing and what's blocking us on the way. But the reality is harsher and more unpleasant. The 14th State of Agile report found that while 95% of organizations are using Agile development practices, only 63% are experiencing faster lead times as a result. This can happen when the case has not been modeled properly and thus doesn't reflect the team's workflow, or when the decision itself hasn't been well thought-over. The same report showed 84% of teams considering their Agile competence and maturity as average or below, which indicates a strong need in further education on the subject, especially given that 61% of teams have been practicing this way of working for more than 3 years.
That's about software development teams. And what about those who don't code? Why would they want to work in short iterations and be prepared for changes in the requirements anytime? The general aim of this approach is to focus the team's effort on accumulating value and managing capacity. These rules are universal for every team delivering services or products. That's why the adoption of agile practices is possible in teams like marketing, sales, or legal, which often rely on timely communication and short-term goals. The last years' experience shows that HR and supply departments also gain much value by reevaluating their practices through agile frameworks. An additional positive effect can occur in terms of meeting cross-team deadlines thanks to greater synergy.
If we think about it, the end product of agile teams mustn't be code.
Applying Agile practices outside software projects
It's interesting that some Agile practices originated from environments outside software and IT. Agile coach and author Allan Kelly mentions that daily standup meetings are usual among the restaurant staff, and something we know as pair programming is a common way of work for surgeons or aircrew. But is Agile really for every possible team out there?
The Agile methodology can be applied to the development of products like computers, medical devices, food, clothing, and even music - basically, everything that can be released in versions and continually improved. The variety of Agile applications is really astounding even if we do some simple web surfing. To begin with, there's a famous 2013 TED Talk by Bruce Feiler, the author of The Secrets of Happy Families, where he tells his story of running a family and raising kids using the Agile methods (a couple of years later Matthew Jeffrey from Atlassian wrote about a similar approach). Apparently, simple things like regular meetings and chore checklists work miracles when there's an overwhelming amount of work to do and no time for communication. Then Newton Lee outlined Agile music production in his compilation called Digital Da Vinci: Computers in Music. Based on the fact that musicians also rely on some kind of technology to record and produce their compositions, he compared each part of the creative process to its counterpart in the software area and this way produced outstanding results that landed in the U.S. Billboard charts.
If these examples seem more like poetry to you, let's move to the more "practical" ones. During the recent Jira Day Remote Edition, there was a presentation by Karolina Brunet from AstraZeneca where a pharmaceutical company implemented Agile methodologies and tools for clinical data management. Despite being very structured and sequential by design, these types of projects turned out to benefit a great deal from the experiment that increased the company’s competitive advantage through fast test iteration and rapid response to change. Another famous case presented for the first time by Kate Sullivan at Agile on the Beach 2012 was the Lonely Planet legal team, who tried to cope with overworking, multitasking, lack of transparency, and managing lots of internal stakeholders each having their own interests. In short, what saved them was one-week iteration cycles with daily standups and a developed Kanban board with a backlog, work in progress limits, color codes for different types of projects, and sub-columns inside statuses for different priorities. The board evolved over time in the same incremental manner and got adopted among some other teams inside the company.
LonelyPlanet legal team working with their physical Kanban board. Source: LunaTractor
Industrial production benefits a whole lot from Lean manufacturing and Kanban techniques - and invented them, in fact. The iconic Harvard Business Review article from 1986, The New New Product Development Game, described the cases of Toyota, Canon, Honda, and other Japanese companies improving deliverability and introduced the term Scrum comparing their teams to the rugby team divisions. This was the game-changer that reportedly inspired Jeff Sutherland to bring these principles into the software area. A more recent example, which depicts the experimental nature of Agile practices, is the Mission Bell Winery. The experiment that meant to just help with Safe Quality Food Level 2 certification turned out a performance booster, as the distribution team finally could take their time to improve the way they work. Because of this, loading productivity increased from 411 to 425 cases per hour in just 3 months.
Mixed and hybrid Agile methods
Even given all the positive effects resulting from the agile approach, we should keep in mind that it doesn't solve all the aspects of managing a project. For example, Agile is not used in large investment projects like construction and shipbuilding. There are many teams that rarely talk to each other, and one Project Manager who supervises the whole thing, so Waterfall methods are better applicable. But what's interesting, even in such large projects, some smaller ranges of work can be found in which Agile will work. In the shipbuilding industry, when the schedules are delayed, the finishing works such as air conditioning and interior should be carried out quickly, so then Agile can be used.
Apart from that, Agile projects rely on the availability of specialists throughout the project timeline, like designers or architects. When waterfalling, after their phases are complete, their contribution is rather occasional so that someone's absence isn't mission-critical. Also, in such projects, it takes more time to communicate across different functions and specializations, especially in companies where processes and products are highly complex.
So Agile practices can be inefficient in large organizations and for those types of products that can't be versioned or iterated quickly. Managers believe that agile methodologies by the book are too extreme and tend to adopt hybrid approaches depending on their particular situation. This is called method tailoring - every company is different, and so is their approach to making the work done. There are even examples of codified mixed frameworks like Scrumban, where team members abandon the time-limited sprints but stick to the product backlog and Scrum rituals. In software, this is used mostly for app maintenance and ongoing bug fixing.
There are also cases where a team needs to put aside agreed agile practices to work towards a deadline. This is a somewhat extreme case of feature freezing, where the team stops accepting new projects until the important release. This happened once to our Apps team when they were migrating the codebase of Requirements & Test Management for Jira from Cloud to Server, and also recently to our Marketing team when we had to double the sprint length the week Jira Day Remote happened. In fact, many will argue that this is the true spirit of Agile, where even project squads can emerge and dissolve each sprint. But in many situations, having a strategy in place and planning things well ahead is also important - that's why there are all kinds of mixed approaches. In the end, a vague roadmap is better than no roadmap.
Is Agile only for software teams?
Definitely not! If you're considering trying Agile practices with your non-software team, here's a couple of tips to learn:
- Each project should have an owner, who acts as the customer's voice and is in charge of making business decisions, as well as the Scrum Master who helps deliver on time.
- Take care of information transparency and sharing culture. Have a so-called information radiator like a live dashboard with project status, put your meeting notes on the intranet, set regular meetings like standups and retros.
- Work closely with the customers, whoever they are.
- Remember: there's no blueprint for implementing Agile! It's a playbook that you should use according to your team and business needs.
We should remember that agile practices are a great hammer, but not everything is a nail. - Przemysław Gochna, PMO PPM Solution Architect
Deviniti is your guide to the universe of digital transformation and enterprise software. If you want to learn more project management tips and stories, have a listen of our Software Home podcast.
Was this helpful?
Thanks!
Dzmitry Hryb _Deviniti_
About this author
Marketing Manager
Deviniti
Wrocław, Poland
3 accepted answers
2 comments