At some point during a project kick-off meeting, I usually explain what we don’t do at Bigger Boat Consulting. I’ll say something to the effect of “We don’t gather a bunch of requirements, scurry away and disappear for three months, and then come back to deliver our database solution to the client with a smile and a ‘Hope you like it! Hope it’s what you wanted!'” Generally, this story is greeted with at least one person nodding knowingly and wincingly. Or simply curling up on the floor in a ball.
If you’ve never experienced the pain of a project like this, lucky you. Often what happens during the course of a project is that requirements change at some point during the three months that your consultant is heads-down building. Or when the solution is presented, everyone discovers that what the client said and what the consultant heard were two vastly different things…
We were tired of that sad story, so we switched to an agile process that allows us to collaborate with you on an ongoing basis.
Here’s how we approach it. We do work in two-week cycles or “sprints”. At the beginning of the sprint, we work with the project team to determine the goal for the sprint. At the end of the sprint, the work is complete and either tested and accepted by our client or tested and rejected by our client. If rejected or incomplete, we assess and determine if the work should be moved into the next cycle. Then we start it all over again.
We think this process really is the best way for us to partner with our clients to design, build, and implement a great solution.
Some of the benefits we’ve found are:
- Higher quality. The product is tested and approved throughout the entire implementation.
- Greater communication. The project team, which includes both consultants and client project leads, is always aware of how the project is progressing; consultants do not disappear “heads down” on the project for extended periods.
- Greater flexibility. We plan and build as we go so we can respond quickly to organizational changes (staff changes, priority changes) as well as changes in requirements.
- Improved staff knowledge of the system. The project team sees the new system earlier and, as a result, has a more thorough understanding of the system throughout the rollout process.
And the best thing for our team is that agile allows us to approach our projects in a flexible way with a constant eye toward improvement. Hey, nerds love that stuff.
Still reading? Please take a look at some of my favorite agile resources.
- Building Iteratively Our post on how to build a system your users and organization will love
Agile Methodologies Gives you a quick rundown of what we usually refer to as “agile”. (though Scrum folk will insist Scrum is a framework, not a methodology)
The Agile Manifesto
The Scrum Reference Card
Agile Product Ownership in a Nutshell (16 minute video)
Personal Kanban Includes a Kanban board for kids!
Lean from the Trenches This book inspired me. Thanks to Jesse Snyder for introducing it to me a few years ago.