Often I have been asked by customers, partners and friends, what methodology we use at JackBe to deliver our product releases. The closest I have come to describe it is to brush it off by saying we use Agile development methodology. But that is just scratching the surface. When you dig me in for more specifics, I end up scratching my head to explain coherently. So I thought I would share my thoughts briefly to see if I can catch the main message I want to convey about this topic. For a brief comparison of the various approaches under the agile umbrella, see what Martin Fowler has already said about that subject.
At JackBe, the methodology we adopted was crafted out of several approaches and stabilized over time. The number one goal was to keep delivering the releases and features, and not let processes get in the way. And we did that successfully over the past 7 years, averaging 3-4 releases per year, which I believe is a significant and consistent achievement in enterprise software products business. Let me discuss around the 2 most popular methodologies and my take on how they were relevant to our approach:
- On XP The values espoused by the XP approach (Communication, Feedback, Simplicity, Courage, and Respect) were fundamentally intrinsic to our team, and that took a lot of time and effort for us to cultivate initially. However, once this was in place, as new members go on the team, they quickly absorbed and contributed to the approach and became an integral part of the team very quickly. However, though we initially started with a bit of Test Driven Development (TDD), but over time it became hard to maintain that in our development cycle. This often meant, that tests took the back seat to other aspects of development, but we were only accumulating the technical debt, as testing the software later racked up the bill. The number of unit tests we were writing as a team dropped drastically as the rush to push out new features became a business priority, and this is one of the traps that most development teams fall into.
- On Scrum While Scrum recommends a periodic sprint (say monthly) that the entire team coalesces around delivering, we sometimes adopted this principle. However, we did not follow the daily scrum meetings and there was no Scrum Master to do this. Instead, we valued open and continuous communication between all the members of the team including myself so that no task would get held up in order to reach the goal of delivering a software milestone. Our team did not wait for daily scrum meetings, we just took up the issue as it arose and resolved it. We did have the weekly team meeting as it was necessary to get everyone aligned and re-aligned to ensure we were making continuous progress. But the main work of communicating and aligning was done daily on a continuous basis allow the weekly meetings to provide a wider update and status check for the team. Many others in the industry who use the Scrum approach rigidly, have complained that the team finds the daily scrum meetings which should be taking very little time, turn into hours of debates. If you have a good scrum master, perhaps this can be avoided, and it also depends on the overall personality of the team and individuals in the team. See http://www.scrumguides.org/
So in my experience, there is no one single methodology that one can simply adopt for the entire team. I believe it is the collective responsibility of the engineering leader and the team to craft the team’s own agile methodology by choosing the various best practices that are best suitable for the team, the product and the business. Each methodology comes with its own framework, values, practices and constraints. They are meant to provide guidance in determining your own successful course, and there is no need to be rigid about what you want to box yourself in. Make your own agile methodology by choosing the best of breed, blending with your own and team’s experience and skill set.
At any cost, do not forget the original purpose of your work, which is delivering high-quality software, and become a slave to the process. After all, delivering software is our business and we must enslave the process to do our bidding!