May 14, 2018
Our work at Valtech is fast paced. We deliver digital experiences that have an impact on large audiences for well-known brands. We are entrusted with a brand’s reputation and are expected to succeed every single time. We juggle projects, requirements, dates and budgets to make sure we provide the best experience for our partners. However, we also are expected to wow them, delivering impactful solutions that go beyond what everyone thought possible and that few others would be able to deliver!
Amidst all this organized chaos, we have a not-so-secret weapon that we consistently wield to succeed. The secret is the Agile Methodology.
There are many flavours of Agile, but Scrum is the most popular, so that’s our focus for this article.
Agile/Scrum (or Scrum, for short), is a liberating management style for teams that has revolutionized how we create digital projects. Initially, a methodology employed for software engineering, the Agile method can be used for many projects due to its simplicity.
Though this is not a complete definition of Scrum, at its core, a Scrum Team has no manager, and no one is assigned work. Instead, in a Scrum Team (which usually consists of 4-7 people), members look at a prioritized backlog and collaboratively pick the work they know they can deliver in a calendar period called a Sprint, which is usually two weeks.
The Backlog is the responsibility of the Product Owner, who also sets the priorities for the tasks in the backlog. Officially, the backlog defines the requirements for the project but is generally not all encompassing. Think of the backlog as “what” is being built in the short term, but most definitely not the “how” it is built, nor is it everything that will be built. The backlog generally has enough work to keep the team busy for several sprints, but one of the key concepts of Scrum is that the team does not wait for a full backlog before they can begin to work.
The Scrum Team also has a Scrum Master, who is the person responsible for ensuring the smooth operation of the team. Notice how the Scrum Master is not a team leader nor a manager of the team’s work. The Scrum Master is a facilitator of the process because the team members and the product owner collaboratively decide how and when the team tackles product features. Yes, the team follows the prioritized backlog, but any team member can bring up anything at any time for discussion. It is not uncommon in projects for the backlog to contain many items that the team members themselves bring up, and that the product owner accepts and prioritizes into the mix.
Contrast this with the classic Waterfall Model of project management, where teams of experts might spend months carefully defining what a project’s requirements might be. They might spend so much time in this endeavour that by the time there is a finished specification, some of the requirements might not even be valid due to changing business, environment and competitive forces. Even worse, if some of the later requirements depend on early decisions, the entire requirements document might be obsolete or based on incorrect assumptions. For this reason, we could think of the Waterfall Model as the House-of-Cards model. A card at the bottom of the structure (a changing requirement) might topple the entire structure.
Finally, in the classic Waterfall Model, there is no product to see for a long time. It might be months or more before a product owner gets to see a hint of the product being built. By the time the business starts to see the product, it is often too late to make any meaningful changes, again contributing to the high failure rate of classic projects.
In an Agile project, the product owner (and the business) generally start to see results even after the first or second Sprint (in weeks, not months). Furthermore, the entire team (and the business) can see early on how features might really work and can quickly adjust. More importantly, we are accountable as a team.
Note, Agile teams are not “the wild west,” and they do indeed follow established patterns and practices in an organization. Just because the team is empowered to make decisions for the implementation of a project does not mean they act in a vacuum. It is very common for organizations that have central architecture groups to provide at least one member of an agile team.
Many read this and immediately think “there’s no way this works.” We can attest to the fact that it does indeed work, and very well. Furthermore, it works not just for the team members, but also for product owners, stakeholders and the people using the digital product or experience.
Imagine “seeing” progress every two weeks? What is more tangible than seeing results, regularly and consistently? Imagine delivering new features to your customers regularly (maybe once a month or more)? Then contrast that with a project where a year goes by before a new version is ready for customers – and when it is, has a much larger potential to cause disruption and anxiety (because generally, the product changed so much since the last product iteration.)
By the way, we are not alone! See the ‘State of Scrum Report 2015’ where nearly 5,000 respondents, on average, felt that Scrum is successful 62% of the time! And if a Project Management Organization (PMO) was involved, success rates jumped to over 90%. Wow!
Plus, thousands of companies create and maintain projects this way. You generally can tell who they are because they are always updating their software or product (imagine that!)
Have you noticed that your Facebook app updates, more or less every two weeks? Now you know why.
Interestingly enough, Agile is not a new concept and has been written about extensively. See ‘Agile: The World’s Most Popular Innovation Engine’ and countless other articles that have been published in the last few years.
As with any concept, there are those that don’t agree with the praises of Agile.
I’ve heard folks say that Agile is an excuse for teams to avoid deadlines or engage in proper planning. These could not be farther from the truth, of course. Once you understand what Agile is, you know that Agile does indeed provide for planning (lots of it and regularly actually) as well as deadlines (every two weeks). Sure, you might not spend months in planning at the beginning of a project, but we’ve presented how that’s actually a good thing because you are planning all the time in Agile and can, therefore, learn from early small mistakes and make your digital product better. And sure, you might not deliver every single product iteration to end-customers, but you bet you’ll be delivering many more when you are incrementally producing an iteration every Sprint.
I’m not saying Agile is perfect. There are plenty of ways to screw up any project (Agile or not). What I am saying, though, is that in our practice and in what we’ve seen with others, Agile projects have a higher likelihood of producing solid results, cost-effectively and with less risk than the classic waterfall model.
To me, Scrum is second nature. To me, Agile is how you build projects. To me, Agile/Scrum is liberating and empowering, and I am apprehensive to participate in projects using a non-agile process. Honestly, working with an organization now that does not follow an Agile practice makes me question the organization and whether or not I want to be involved with them. (I wonder how successful they are. Judgmental? Absolutely! When you’ve “seen” better, it’s hard not to be judgmental.)
However, I can personally attest to the fact that Agile/Scrum has brought back joy and self-fulfilment to my projects. I’ve seen this in myself as well as my teammates who feel that they are now part of something, not just an extra hand on a project.
I can also attest to many happy clients that also feel like they participate in projects and are in full control of the process at every step. Contrast with the classic model where you give someone your requirements, they go away for three months, then come back with something that is nowhere near what you thought it would be.
If you are a leader, non-technical manager, product owner, marketing manager, C-level executive, etc., I recommend you start with ‘The Scrum Guide.’ It’s a short read, so don’t delay. Then, share this with your technical team. Getting this knowledge will allow you to support them and encourage them to move in this direction. Make it clear this is the direction you want to go in (because some Engineering teams can be stubborn about ‘a new thing.’) Also, review ‘Introducing An Agile Process to an Organization’ and follow some of the ideas.
What’s in it for you? How about seeing “your product” improve every two weeks? No, you might not ship it to clients every two weeks, but YOU (and your stakeholders) will see progress, quickly, regularly. How’s that for accountability and measuring ROI?
If you are a Software Engineer, Developer, Project Team Member (or an Engineering Manager, Team Manager) you must immediately become familiar with Scrum. It will change your life (and your teammate’s lives) – believe me! Start with ‘The Scrum Guide.’ It’s not very long and it’s easy to understand. Then, perhaps try ‘How To Implement Scrum in 10 Easy Steps.’
Then, JUST DO IT. Sure, you might need some buy-in from the business, but I’ve seen where Engineering teams can start moving in the direction of Scrum on their own initiative. The point is: saying “we’ll do this one day” won’t change anything. You have to start one-day, so “one-day” might as well be today!
If you hire outside resources or outsource your project development, start with ‘The Scrum Guide’ but then ask your partner company about their Agile process and what role you will be playing. You should likely be the Product Owner, but if you are also contributing team members, they too need to participate in the Agile ceremonies and processes. In some cases, you also might want to provide the Scrum Master as well (even better if that person is in your PMO.)
One important consideration is that as Product Owner, you retain a critical role but it is one that comes with great responsibility considering your ongoing attention will be needed. Whereas in a waterfall project, you might work hard initially to create requirements then hand them off to a team, in an Agile project, you’ll be participating on an ongoing basis. The work might even be a little more considering you are factoring in changes and unknown factors, but it is spread throughout the life of the project as opposed to front-loaded. However, the potential for success is also much higher (and easily makes up for the extra work) since you will be able to make adjustments very quickly when compared to a classic project.
With technology moving as fast as it does these days, every organization engaged in digital projects, that wants to stay competitive and relevant, has to take a serious look at Agile. The consideration is no longer if to adopt Agile, but rather why are you not already using this method of project management.
Consider this: if internal motivation is not enough, it is very likely that your competition is already using an Agile methodology and also likely that they are outperforming you – every two weeks!
This article is by no means a full and complete definition of Agile/Scrum. For the full definition, please visit Scrum.org, ScrumAlliance.org or Google “Agile Scrum Methodology.”
