Roadblocks when implementing Agile processes in a traditional organization
Many companies struggle to successfully implement Agile into their more traditional company culture and structure. In this video, Kelly Morrison, a client partner at Praxent, describes 3 common roadblocks that tend to come up for our clients when implementing Agile that have easy solutions.
Video Transcript
Hey y’all, my name is Kelly Morrison and I’m a client partner here at Praxent. As a client partner, I’m responsible for overseeing a number of our accounts and making sure that the products we’re building for our customers continue to meet their high-level business objectives and really move the needle when it comes to innovation. Today I’m going to be talking about how you can introduce Agile processes into your traditional culture.
Team Structure
The first thing that can cause a roadblock is the way that you structure your teams. So in traditional organizations, we’re used to seeing teams structured around the people and in Agile methodologies, they recommend structuring the teams around the work or the product. And so what that means is that in traditional organizations it’s very common for us to see a team that’s focused on the database, and another team that’s focused on the API or the backend, and another team that’s focused on the frontend. But a downstream effect that that can have is that it will take a very long time to validate any given feature all the way through.
So the example that I always like to use is a login example. If you’re building a portal then you’re likely to have a login feature and it’s likely the first feature that your team is going to begin to tackle. But if the database team is focused on building out the entire database, and the backend team is focused on building out the entire API, and the frontend team is working on building the foundation for the entire application, it can take months or years for you to be able to validate that the login is working correctly.
In the Agile process, they recommend structuring the teams around the work or the product. And so in this example, we would recommend having a cross-functional team. So you’d have representation from the database team, from the backend team, from the frontend team. We also often see that those teams could include members from our quality assurance team and the designers as well. And so this team is now focused on releasing demo-able work. So if we’re talking about this login feature the team is going to do everything that they need to do to get the login feature out as soon as possible. So what that means is that you’re able to see releases much more frequently, you’re able to see fully functioning work. And, it prevents so much rework that we see in traditional teams where, when we finally get a test login, we realize that something is broken in the database and we have to go back and rework a lot of things that have already been developed.
Structuring your teams around the product or the work instead of around the people will enable you to successfully release early and often, and obtain customer feedback so that you can be sure that the products that you’re building truly do meet the customers needs. And it’ll also enable you to iterate very quickly and take in feedback in almost real time.
MVP Understanding
Another thing that can cause roadblocks when introducing Agile processes is the word MVP. For those of you who aren’t familiar, MVP stands for Minimum Viable Product — and that word can be scary with those who are unfamiliar with it. The goal of the MVP is to release early and often so that you can get user feedback as soon as possible. And we really focus on defining the minimum set of features that can provide value to the end user. When talking about MVP product, it’s important to make the distinction that an MVP is just one version of the product — it’s not the final version of the product by any means.
At Praxent we run on two week sprints, which means that we’re working on and releasing on new features every two weeks. So when we’ve released an MVP product, that version of the product lives in the wild for two weeks before we’re introducing new features and a new version of the product. A great example of a company that does this so well is Facebook. If you think back to what Facebook looked like 15 years ago versus what it looks like today, they couldn’t be more different. But if you had to pinpoint a point in time where Facebook made drastic changes to the application, you probably wouldn’t be able to. Now this is because Facebook is releasing new features daily, and sometimes even multiple times a day. And what that enables them to do is they can get user feedback in real time. They’re not holding a set of features back to have this big bang release, but instead they’re making small, incremental changes that they can get feedback on and that actually drives the direction and the priorities of their roadmap.
So that’s a really important distinction to make when you’re talking with your team and with your stakeholders — that the MVP is not the only version and it’s not the last version. It’s just the first version and it’s only one version and it won’t live there for very long. But it will enable you to put something on the market, to get user feedback in real time so that you can validate that the product you’re building meets the end users’ needs and really achieves your high-level business objectives.
Stakeholder Inclusion
A third and final thing that can create roadblocks when transitioning to an Agile development process is not including senior stakeholders in the conversation and in the transition. It is critical to clearly set your stakeholders’ expectations throughout the process and throughout the transition so that they understand the ‘why’ behind the process shift and they really understand how its going to benefit them in the long run.
Steve McConnell, who is a software estimation expert (he’s analyzed over 10,000 software projects), has found two statistics to be true. The first is that 68% of software projects fail, and the second is that 64% of features are rarely used.
By shifting to an Agile methodology you’re guaranteeing that you’re able to release much more frequently which will enable you to get feedback both from your users and from your senior stakeholders so that they can have an input on the product roadmap and the priority of the features. For senior stakeholders this is critical when they’re thinking about how these features are going to have an impact on their ROI.
I hope this explanation was helpful for you. At Praxent, we focus on helping financial services companies modernize their legacy application, and this can often include helping them implement some of these Agile best practices. If you’re working on a similar project or running into similar issues, we’d love to help out.
One of the pain points that I mentioned was around unmanageable release sizes. But there are three others. We’ve written an entire Ebook on this, called The 4 Reasons Why Software Modernization Projects Fail (and 12 Strategies for success). We’d love for you to check it out.
(End video transcription)
—