Engineering Methodology: Theme Based Releases

In continuing with the previous blog on engineering methodology, I wanted to talk a bit more about how to work the requirements funneling and release management process.

One of the challenging aspects of building a product is to figure out which requirements make sense and which don’t and keep the features in line with the product’s goal and philosophy. This gets compounded by what is pushed by sales (if the product had this, i can close a huge deal deal right now!), inspired ideas from visionaries in your team (build it and they will come), your own insights based on the product and customer knowledge (many customers have asked for this), and a myriad of other things.

One approach to manage this is to use a Theme based development stream. A theme basically focuses on one or two large related areas of need in the product. Getting different stakeholders to agree on a theme is much easier than to get them to agree on individual requirement priorities of disparate items. These themes become the place holders and guidance for directing an incoming requirement. And the themes can then be mapped out in terms of relative priority and lined up for the release milestones. Aim for the theme to be delivered in less than 3 months, and each feature in the theme should be done in sprints of no more than 3 weeks.

The themes are flexible. You may have to add or remove features to the themes at any given time. However, if a feature is already in development, most often, it is too late to remove it from the theme. In quicker releases, you might map a single theme to a release to keep the scope down. In larger releases, related themes may have to be released together, but be careful about combining more than 3 themes into a single release. Once you have the themes in your pipeline, you can then sequence these themes into milestone releases. In my experience, this approach allows efficient and effective allocation team members to complete the features and also allow them to work on multiple themes. This way, the entire team can be busy working on delivering one or more themes, and therefore, one or more releases.

Themes also make it easy for your marketing and sales teams to articulate the value of the next release to current customers. Instead of digging out the nuggets to sell/promote from a large list of features listed for each release, you end up having upfront agreement on what the next release is going to be all about. So while the engineering team is working on development activities, marketing and sales teams can work in tandem on collaterals, outreach and other launch related activities. This allows for closer collaboration and more efficient cross-team work to achieve a successful release every time.

Advertisements

JackBe Engineering Methodology

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!