At Jama, we work with a wide range of companies using different software development processes. And, despite all the evangelism by the process gods in our industry, if there is one thing we’ve learned over the years it’s that no single process is the best practice for all companies. What works for one company, may not work for another.
Too often, our industry gets caught up in labels, and “Agile” is a great example of that right now. Agile is as trendy a buzzword as “innovation” or “Web 2.0”, but if you lined up 100 different developers and asked them what Agile means, you might get 100 different answers. But, is that really the point – are you Agile or not? Agile itself isn’t a single process – there’s different flavors such as Scrum, Crystal, XP and others. And, as the Agile Manifesto outlines, the underlying concepts of Agile are common across all flavors, such as breaking things into smaller projects, welcoming changing requirements, delivering frequently and having frequent conversations with the customers and users of the application you’re building.
So, the question isn’t so much about whether you’re Agile, but which techniques within these Agile methodologies will work for your team? How do you build great products that are safe, reliable and customers love to use? That’s what it’s about.
Like a lot of dev teams, we’re constantly looking for ways to improve our own process internally in building our product, Contour. So we decided to blog about our experience with Agile techniques, not as experts or evangelists (there’s plenty of those), but simply to share what’s working, what’s not, what we’ve learned through our own experimentation and retrospectives.
Over the next several months, we’ll be incorporating different techniques and enhancing the ones we already use to optimize our process at Jama. Also, we’ll leverage what we learn to enhance the features within Contour to support a range of techniques – for Agile, traditional methods, CMMI or other practices our customers need.
Last week, as an interesting exercise, we had two of our senior developers do a showdown of Scrum vs. Crystal Clear – two of the more popular Agile methods. Derwyn representing Crystal Clear and Frank representing Scrum. What ensued was a bloody, mixed-martial-arts-style cage match of epic proportions. Well…not really. Actually, it was a civil meeting over lunch with our team and both came armed with notes from their favorite books and brief presentations on the realistic techniques that we can weave into our process at Jama.
The net result of our discussion was that we’re not purists of any one specific methodology. There’s a blend of techniques that we’re leveraging. In fact, one of the principles Crystal teaches is this sense of evolution - that your process needs to fit your team, and not the other way around. Point Crystal. Oh wait, we’re not keeping score…
Here’s the rundown of what we’re doing at Jama (click image for .pdf):
Our development team works within the same office, so we have the advantage of being able to do daily stand-ups and we use a large whiteboard with sticky notes for managing tasks that are active for our current iteration (a.k.a. sprint). We use Contour to manage our product backlog which includes new feature requests, defects, requirements and tasks.
As we do our planning, we group these together into releases and shorter sprints. In context to labels, I guess you could call our mixed approach “Agile Hybrid” – and really the only way to top one buzzword is to add another to it, right? In all seriousness, our approach is rooted less in theory and more in what we realistically see ourselves adopting and having success with - and it evolves.
Techniques we’re doing now:
- Daily stand-up meetings
- Frequent delivery/iterations
- Product backlog
- Whiteboard with task cards
- Requirements documentation (yes, it has a role in Agile)
Techniques we’re not adopting:
- Use of points or velocity score
- Self-organizing teams
- Pure pair programming (we do side-by-side programming at times)
What we’re experimenting with:
- Blitz planning
- More thorough retrospectives with each release
- Implementing burn-down charts
In future posts on our use of Agile, we’ll share more examples of the techniques we’re experimenting with and we’ll tackle the often-asked question, “What’s the role of requirements management within Agile development?”
Share with us your own experience: How has your process evolved? Which techniques of Agile have you had success with? Email us directly or feel free to post a comment here.
If you’re new to Agile, here’s a few of our favorite resources to help get you started:
