Understand the basics of Agile methodology.
You know the expression, “It’s a marathon, not a sprint?” We say this a lot about long processes that we need to take one step at a time. But, the Agile software methodology takes that old adage and turns it on its head. What if your development project is a sprint? If it’s just a whole bunch of them lined up until you achieve that marathon goal?
That’s pretty much exactly how Agile methodology works. An iterative process rooted in cross-functional collaboration, an Agile software project is completed in short, focused bursts where development happens concurrently with testing and revision. Maybe you’ve heard the term “continuous delivery” in relation to software solutions. That’s in line with Agile, too. Your software team is continuously delivering versions that you and other stakeholders can review and help evolve.
How did the Agile methodology start?
It’s actually a pretty cool story. Like, if you happen to have an in with the Hamilton people, this story is ripe for a hip, rebellious Broadway adaptation. In the meantime, here’s the gist.
In the pre-Agile early 1990s, most software engineers followed the waterfall method, also known as Liner Sequential Life Cycle Model. Essentially, this is a linear method where the whole process is dictated upfront, usually from business analysis through to concept, build, test and release. The project team must successfully finish one phase before another can begin. There’s a lot of documentation involved and it doesn’t allow for changes in scope. Admittedly, a bit rigid.
However, there were a bold few, 17 to be exact, who were fed up with the incessant documentation, multi-year turnaround times and inability to course-correct when business goals (understandably) changed from year to year. They started meeting up casually to brainstorm ways the whole process could be better, faster and more effective. These conversations led to what they called The Agile Manifesto, which they released in 2001. You can read it in full here, but some of the key tenets include valuing:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Hear, hear!
So, waterfall stinks then and Agile rocks?
Not exactly. Like most things, the answer really depends on what your business’s specific needs are. Though rigid, the waterfall method is a lot easier to manage and may work very well for small-scale projects where structure is sorely needed, the requirements are clearly defined and the overall scope is not expected to change.
What’s great about Agile is that it puts a specific use case (or customer need) first and keeps the client team involved throughout the process to ensure that need is met. It’s the right methodology when flexibility and communication are high priorities. It’s also good for when you need to move fast.
Scrum, Kanban and other funny words
You may have heard some additional terms thrown around if you’re getting project estimates from Agile software teams. That’s because the Agile methodology is a pretty big umbrella that has a variety of subsets within it. Some of the most common include:
Scrum
Kanban
Lean software development
Crystal
Extreme programming (XP)
The most widely used Agile subset is Scrum (and, yes, it’s named after the Rugby huddle.) It’s known for being simple yet highly productive, all while keeping overhead low and quality high. It’s a little more structured – with fixed time intervals and set prioritization for each step of the project sprints – but Scrum is proven to be very effective for completing complex development projects quickly.
There are a lot of ways to accomplish whatever digital transformation goal you’ve set for your company. If you’d like to hear more about different approaches, get in touch. We’d be happy to share what we know.
Comments