Digital Transformation is inherently Agile. New technologies emerge and then take hold, while trends change. Software that’s not up-to-date with current customer needs or not compatible with the latest technologies can become like a square peg in a round hole. In turn, your company might not fit into a market that’s already changed while your product was stuck in development hell and suffering from feature creep. Agile development enables both a faster response to and adoption of new technologies so that they can immediately be leveraged in your own product. This is imperative if you don’t want to fall behind.
The Agile framework and Scrum methodology have proven themselves to be perfectly suited to Digital Transformation, which is driven by — and disrupted by — rapidly changing technologies, not to mention ever-changing customer requirements. Agile enables a highly reactive and flexible development mentality, while Scrum provides a methodology and process to transform agility into action. So what are Agile and Scrum, and how can they be put into practice in business and operational units outside of software development?
Agile is essentially a set of principles for software development, and there’s actually an Agile Manifesto. Agile enables faster rollout of working software in order to meet customer needs. It also prevents wasted time and resources on producing deliverables with low added value. Software development becomes leaner and more efficient, and new releases more frequent. In an Agile environment, change is in fact welcomed, and the ensuing discussions enable teams to prioritize changes based on user needs. There’s no real documentation per se, since documentation isn’t what drives getting this feature or that change done. Companies with Agile development principles in practice are able to rapidly adapt to changes in customer needs.
But Agile itself doesn’t contain any specific directions or established methodologies. It doesn’t give any actual, practical directions. It’s a way of being that requires a way of doing. Agile development, then, often uses the Scrum methodology and process. Scrum has defined roles: the Product Owner, the ScrumMaster and the Development Team. (The Scrum Alliance website has some great information and resources on Scrum and Agile.) Scrum enables a faster turnaround, which allows for a high level of agility in development.
Here’s Scrum in a nutshell: Development is made up of short periods called “sprints”, which are fixed time periods (usually around two weeks, or up to a month) made up of several stages. Each sprint starts by examining the product backlog, which is a list of value-added items to be completed in a project, organized by priority and always open to modification. The first step in the sprint planning stage is to put together a sprint backlog based on the product backlog, in order to define the work to be done. What’s important is that it’s more about what can be done during the sprint. By using this realistic and pragmatic approach, sprint objectives can more easily be met. This can prevent teams from getting in over their heads, falling behind other teams, delaying delivery and so on — not to mention becoming discouraged.
During sprints, scrum meetings are held, usually daily and last around (or even exactly) 15 minutes. Unlike other meetings — the ones we all dread — scrums are short and punctual, not long, drawn-out and boring ordeals. In fact, the idea is to minimize time in meetings in order to be more productive in actual creation. Team members share what they got done the previous day, what they can get done today, and what issues they might encounter. Everything is organized on a board, usually with color-coded sticky notes or cards. At the end of the sprint, the work done (and, importantly, not done) is reviewed, features are tested, and the result is demoed to stakeholders. Finally, the sprint ends with a longer retrospective meeting, which isn’t about the work produced but the work process itself. The ScrumMaster and the team take a step back and look at what went well, what didn’t, what can be improved and how, and so on. This is more about looking at the big picture, and Agile principles are used to inform these considerations. And then, the next sprint begins…
As a certified ScrumMaster, I’ve come to really understand how Agile–Scrum has been so effective in software development and IT in general — and I think there’s a place for them in organizational and business units outside of IT. A company’s non-tech departments can benefit from it too. Some areas where Agile–Scrum can be put to use are product planning and marketing, at the same time strengthening and optimizing cross-functional team and department collaboration.
When it comes to product planning, Agile–Scrum can make a huge difference not just in the quality of new products or version updates, but also in terms of relevance and usability. Customer needs are always in flux. An old-school “Waterfall” approach that defines objectives, features, timelines, roles and so on at the outset of a project can ultimately lead to delivering a product that’s already obsolete. Making a change late in a Waterfall-based product development cycle requires extensive revision of the requirements documentation, and often the development team only gets the new documentation months later. There’s no time for that in today’s market.
Agile allows more dynamic cross-functional collaborations between product planning, marketing and development. All of the groups can interact back and forth, with issues or new ideas from development teams incorporated into revised product specifications and features, or added to the product backlog. Scrum enables a fast turnaround time performed by lightweight teams. In a Waterfall approach, all of this might just be handed off to development, who might struggle to deliver a worthy product when having to work with less-than-ideal product plans. While you were busy sticking to a roadmap in a generally rigid development process, you might have missed the boat on changing user needs and preferences, not to mention emerging technologies — and your more Agile competitors might well have beaten you to market with better offerings.
So it’s clear that the Agile framework and Scrum methodology can be applied outside of software development. And since the scope of Digital Transformation extends beyond just IT and throughout the organization, it makes sense that software development principles, methodologies, processes and mentalities can also be extended to other business units and company operations. Still, even though Agile is a way of being and Scrum is a way of doing, what’s still needed is a way of actually creating. Fortunately, Agile–Scrum’s proven track record and ever-increasing popularity have brought about some great new development tools that make it all possible. I’ll be looking at some of these — and how they’re able to produce solid working prototypes within just days, not weeks or months — in an upcoming article.
What frameworks and processes are in use in your organization? Do you feel they’re effective, or could they be improved with a newer approach? Do you agree that Agile and Scrum can be applied in business units outside of IT? Are there other frameworks and/or methodologies you think might be better than Agile and Scrum, and why?