At Lullabot, our client services team works with all kinds of folks to deliver projects. Sometimes, we start with the back of a napkin, and need to discover all the requirements and priorities alongside our client. Other times, there’s a clear goal complete with annotated wireframes, photoshop files and other assorted documentation.
Our clients come to us with varying degrees of rigor when it comes to project management, too. Some have a mature development culture that slices the work to be completed into bite-size chunks, sets priorities, and manages the delivery of those tasks. They may even have a defined quality assurance and deployment process. With a client like that, we use the tools and processes they’re familiar with, and look for ways we can streamline our partnership even more.
Other clients don’t have development processes in place when we meet them, and just want to know when their project is going to be done. In these cases, we’re often in the position of establishing processes, selecting tools, and educating the client about how we can work best for them.
Making Lemonade
A client lacking rigorous processes is not necessarily worse off than a client with clear project management methodology. Loose project management requirements at the outset make it possible to fit the process to the project, while rigor on the client-side means we have less to reinvent.
Of course, a lack of process could be a chaotic mess, but navigating existing processes can be also be a minefield. In every case, we have to adapt as we go. Every project is different, and we try to adapt to whatever tools and processes our clients bring us.
Of course, we’ve got our opinions about how a software project works best. Our project managers and developers all agree that the easiest and most fun way to deliver good software is by working closely with a client to build what they want, getting feedback along the way. In that respect, we’re basically an Agile development shop.
Agile?
If you’ve never worked on an Agile team before, you may be asking “Will this require physical fitness?”. Before you go put on your yoga pants and start stretching, I’ll explain:
Agile software development has been around for 20+ years in one form or another. The name Agile and the core ideas come from a group of seasoned developers who got together in 2001 to discuss what makes software projects succeed. Together they wrote a short statement called the Agile Manifesto, which captures the values they agreed were important. Here’s what they came up with:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
OK, what does that mean?
As I read those values, the first two are high-falutin’ ways of saying that software development is a human process that should result in working software that you’re happy with. That means the people you’re working with matter to the end result, and it’s better to build things than talk or write about them.
That doesn’t mean process, planning and documentation aren’t important - far from it. But plans change, and documentation goes stale. Ultimately, happy people and working software matter more to the end result.
And what about the other two?
The second two values recognize the fact that plans change and new ideas happen late in a project. Trust and flexibility on both sides of a client/vendor relationship are required to accommodate change. That kind of two-way relationship with a client is often the opposite of a fixed-price/fixed-scope contract.
Traditional fixed-price contracts are inevitable, especially when we haven’t yet built the kind of trust together that would allow a different kind of arrangement. In the end, we want to work as smoothly and naturally with our clients as we can. Where that trust exists, we have the freedom to do our best work, and you have the freedom to change your mind as needed along the way.
What does that look like?
Practically speaking this means that we don’t make a big plan and then go hide out for months, until THE GREAT UNVEILING of your project. Instead, the process looks more like this:
- we work in short sprints of around two weeks each to deliver working software bit by bit
- at the start of a sprint, we set priorities with you for the work to be accomplished in that sprint
- meet on a daily basis to talk about what we’re doing and clear any roadblocks
- at the end of the sprint, we demonstrate the work that’s been accomplished and get your feedback
- then we start the cycle over and set new priorities with you for the next sprint
Through that process, you interact with the software we’re developing and give us feedback that allows us to refine things.
Agile development has various flavors - many of them have funny names, like Scrum, Kanban, or Extreme Programming. If you want to learn more about formal agile methods, there’s a good, general overview at Wikipedia, and the specific flavors have their own proponents, like the Scrum Alliance.
As I’ve said, we have to fit our processes to the client in most cases. Due to that fact, we don’t rigorously adhere to Scrum, XP, or any of the other methodologies in the Agile family. We do, however, borrow at will from them to make our projects work better.
In future articles, we’ll be delving more into specific topics around project management and agile methodologies, and how they seem to fit different kinds of projects we work on. Stay tuned!