Method to the Madness: Agile
March 12, 2015
Today, we’ll look at Agile.
The Agile methodology began a few years ago when a group of software developers wrote The Agile Manifesto. In short, the intent was to empower people to do produce good work.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
It looks like this:
Where it Works
Agile software development works well when you don’t have a set-in-stone outcome, but have a really strong sense of direction. I recently worked with a client who came armed for Sprint 1 with artwork, pictures, stories, and a dream for how the business would grow. Every two weeks, we would show them new features, an improved experience, and they would comment about what they liked, disliked, and where we should focus our energies. Every demo triggered new ideas and new possibilities; we’d parse them, select the most important ones, and get back to work. They watched in fascination as the software grew from idea to reality – it was their flagship product and they were completely invested in its success. It also works when you’re inventing something new. If your tech team can’t chart a straight-line path to your solution, a few cycles of research-plan-execute-evaluate can shed light on a path no one could have otherwise foreseen. When programmers come back to the table with working prototypes and fresh insight every week or two, you can steer the project out of the foggy unknown and into reality.
Who it Works For (And Who it Doesn’t)
Agile works well when everyone involved has the authority and resources to do their job, and a clear vision. This can be a sticky area for both the client and the tech partner, since it involves blending cultures, a healthy dose of both communication and trust, and that rarest of birds: leadership.
Now, while Agile allows developers to present working software every week or two, they’re going to have a lot of questions, and only a few days to turn your answers into working code. If your answers require sign-off from someone who isn’t involved with the project, it might derail the entire sprint.
Talk with your tech partner about how they manage their projects. Clients should have access to comprehensive project tracking: bug and burn reports, feature requests, and hours worked. It should all be there, all the time. (We use Jira to manage our work, but there are many excellent options available.) Be aware that you might have to learn some new tools, or develop some new habits, but it will be worth the investment.
Something else to consider: project success requires responsibility, time, effort and good communication. If your organization isn’t able to commit personnel or resources, or is reluctant to designate a project owner, you may want to consider a different methodology. After all, your dev team might be very excited about your project, and produce a compelling first demo, but without good follow-up, they could veer down the wrong path.
A Programmer’s View
I overheard a conversation recently wherein one person said, “programmers like Agile.” The truth is: programmers like successful projects. It’s a pretty great coincidence that clients like successful projects, too! When you’re shopping for a tech partner, don’t be afraid to ask questions and dig into your options. You want a partner who can advise you well, develop in the approach that suits your business, and let you shine where you’re strong.
Stay up to date with our email updates!