It’s just not as easy as saying “I want to go Agile.” It takes time, the right people, and an appetite for failure.
I want to go “Agile.”
You may have heard this statement made by someone in your organization. Maybe it was a developer. Maybe it was a Project Manager. Or maybe it was the new young CIO trying to bring their IT organization into a new era – where traditional waterfall methodologies are akin to that old VCR covered with dust in the corner.
Sure, your organization has plenty of VHS tapes but is that a reason to keep the VCR around or is there another reason?
No matter where it comes from, “I want to go agile” can mean many different things. From just wanting to break out of the rut of traditional project management. Or making a complete shift in the way things are accomplished. To following Scrum down to the letter of the Agile Manifesto. In either case, change is required in the way projects are attacked and the way your teams are aligned.
But where do you start?
How to Start With Agile
Agile development is surely a big shift in the way things happen (or don’t) in an organization. Whether it’s learning to slim down documentation to the proper level, or giving a team the ability to calculate when a project will be done (rather than scrambling to meet a date), Agile can be a big departure from the norm. Or maybe it’s not as far out of reach as you might think.
How does one go about changing from the traditional to the modern? Maybe we can take what people already know about project management and change their view. What is Agile but many tiny waterfalls performed at the most appropriate time in the overall project lifecycle.
Take a large project, for example. We have all been on those projects that take a year to implement and when we are finally finished, we already have a page long list of enhancements or changes to be made.
The crux of Agile would say to break work down into the smallest deliverable units possible. Then work on as many of them in a predetermined amount of time as you think you can accomplish (aka, a Sprint).
With concepts such as design, develop, test, and deploy still in place with agile, what is a sprint other than a mini, time-boxed waterfall project? One Sprint likely won’t complete your entire objective for your intended audience. But when you have completed enough, these mini waterfalls projects bundled together will accomplish your vision.
Before you know it, your teams will be working Agile in its very basic sense. Before you say, “but Agile is way more than that!” – just know that I agree. Point is, it doesn’t have to be the hardest thing an organization will face. You just need to set the cornerstone and the whole foundation can fall into place.
To me, Agile has always been an equation best solved by people and process, not necessarily by just tools and technology. Yes, there are many products out there to help you plan your sprints, track your tasks, calculate team efficiency, and more.
But if the team does not know how to work in an iterative manner, the tools become just extra overhead and their use will likely begin to fade – instead of people finding their own way to track their work. It’s not always an improvement. Sometimes switching things up can expose some weaknesses.
Perhaps some of your developers are too narrowly specialized. Or your business analyst has a difficult time interpreting requirements from the project sponsor and the web designers have covered their shortcomings. Agile can expose both weaknesses and strengths. Don’t be surprised if you discover both.
Start Small with Agile
Try drawing a line in the sand. Pick a small internal project. Maybe you are updating your company logo on all internal websites or creating a new report for HR. Create a small team. Business Analyst, Developer, QA Tester, and someone to oversee it all, let’s call her a Scrum Master.
Build a backlog of stories as a team and let the team estimate how much effort each item will take. You can use that snazzy new scrum software you just installed or keep it simple and agree on a network drive to store your documentation.
Decide on a reasonable amount of stories to attempt in your first three weeks (Sprint 1). Go! The Scrum Master can meet with the team each morning to see how they are progressing and if anything is in their way.
At the end of your three weeks, have the team meet and decide how well they think they did. Did they bite off more than they can chew? Did they have some free time? Before you know it, you have just had for first retrospective and you are onto Sprint 2.
Back to step 1 and chose the next set of stories to complete. Lather, Rinse, Repeat.
Over time your original team could become experts. At the very least, the team learns how to work extremely efficient together giving you a pre-built team ready to tackle the next project.
Maybe you failed, but at least you failed in the quickest way possible and you have plenty of things to learn from.
No matter how you transform, it’s just not as easy as saying “I want to go Agile” and presto, you’re Agile. It takes time, the right people, and some appetite for failure.
