At Shockoe we have the unique (and awesome) opportunity to work with a lot of emerging technologies and methodologies, which is why I’ve always preferred to work for start-ups. There’s less of “This is how its always been” and more “This is new…how can we try to use it?” This is exciting and challenging in a fun way. Not only is my team embracing the latest and greatest in how we build mobile apps, but also in how we manage projects.
If you’re on the project management career track, “Agile” is one of those buzzwords you hear a lot. Even though the idea/methodology is not new, it is currently very ‘hot’. A lot of companies are trying to move from a Waterfall way of running their projects to being Agile. Most of the clients I’m working with at Shockoe have told me “We are used to being a Waterfall organization but we’re trying to embrace the Agile way of running a project”. That, or even if they don’t plan on moving away from Waterfall, they’re interested in our project process and are intrigued to see Agile in practice.
There’s a lot of benefits to being more agile. The big one (for me) is better quality end-results. This happens because you are not saving testing to the end, but instead incorporating testing and then adjusting based on those tests throughout the life cycle of the project. Secondly, there’s more wiggle room for change. In the waterfall world, if you’re saving the testing until the very end of the project and your business/product owner during testing realizes a bunch of things they didn’t consider and now want changed, you’ll find yourself out of either time and/or money.
Running our projects using Agile lets us reduce risks to the quality and getting last minute change requests. However, getting our clients to move at the same pace as we want to can sometimes be challenging. Right after the project kick-off, we’re basically ready to go. This can be quick for some of our clients, who find themselves waiting on Change Review Board or internal PMO to green-light the project.
What this means is there can sometimes be some initial lag time, which usually gives us time to do “Sprint 0” which is when the initial designs and technical architecture documents are created – so once the client tells us they’re ready for us, we can hit the ground running. This is a good way to mix the Agile principles of continuously analyzing, developing and testing throughout the life cycle of the project, with the Waterfall ones of having a plan set forth before you start creating anything.
This has helped ensure that we’re able to deliver what we set out to, and in a way that makes our waterfall clients comfortable with the process, while still allowing for agility in our project management practice. We have so many examples, this is just one, of how we’ve been able to successfully marry our agile practices with our waterfall clients, and delivered a high quality product that everyone was proud of.