I’ve been doing release management and product engineering for almost three years in WSO2. By no means am an expert. Am still learning and trying to tame the beast. However I do have my fare share of experience and knowledge which I have gathered by screwing it all up and also sometimes, doing it right as well 🙂
Recently we have done a successful 1.0.0 release of WSO2 User Engagement Server and I felt writing this post as the release retrospect.
Team
Team is the most important part of any product innovation. Without a strong, competent and hard working team you cannot achieve much (period !!). You feel it when it comes to agile release management. You cannot spoon feed your team. Each member will own a part towards success. You have to believe the quote “A Team Is Only As Strong As Its Weakest Link”, so your weakest got to be quite smart.
Milestones are short, quality of deliverables are high. The build *has* to pass always keeping the master stable. That’s a lot of work. A lot of smart work. So the team does matter and that’s the number one.
Well, WSO2 has the best from the Best and luckily UES had the dream team 🙂
Vision
Number two is the Vision. Its not about the person whose leading the effort need to know the product vision. The team got to have a shared understanding about the vision of the product that they develop. Everybody has to be on the same page. If a button was moved from left to right everybody must know the reason behind that decision.
Non should develop a component without knowing the bigger picture of where that component fits in. (s)He should know the future of that component, what are the improvements can be done, how can it aid to market the product and how does it contribute to achieve the product’s vision.
Reviews
Reviews play a major role. They sync up the team. First you review the design, then review the architecture, the UI/UX and then the code. You get this right, you get a complete product feature.
During UES release, we did a lot of these. Our design review meetings were war zones. We talked about architecture and clean design patterns. Applied them appropriately and iteratively reviewed them. Our UI mockups were all over the whiteboard, we iterated until we achieve perfection. We reviewed our code, identified the improvements.
We never had stand-up meetings, however we discuss the progress in detail once in every two days or so. We reviewed everyone’s work items and discussed the progress.
Scoping
All of us are geeks in my team 🙂 we loved cool new features. When ever a new feature get proposed, we make sure that we find the most creative, most beautiful but most complex way to solve it. Few such examples are, the Dashboard Composer and Site Browser of UES.
However what we should make sure is to be inside the scope. You naturally tend to be carried away, but sometimes you need to de-scope, postpone some to meet the time lines. We have done that, we had bunch of features that shows the collaborative-ness of UES, but we had to remove them and postpone, simply because it wasn’t ready and the amount of work is high to complete it with quality.
You have to learn to trade off and compromise. Scoping is all that.
Milestones
Very important. You got to have it from the day one and stick to it no matter what. It should be your calendar the ONLY calendar and worship it. No matter what, the milestones has to go through, that will ensure you are on track and in control. If one get dragged, its definite that you cannot do the GA as planed, either you have to extend the date or cut down feature. I hated both.
With UES we stuck to the plan (99% of the time). Our initial milestones were feature bound. Our later milestones were time bound and it worked out well for us. In the early phases we wrote code 1000 miles per hr and got them in to the milestone, in later milestones we were only bug fixing and ironing out the rough edges.
Testing
Developer has to be the QA, period. If you write the code, you have to test it and be ashamed if someone else find out a bug. Everybody have to believe it.
With UES, everybody wore the QA hat, tried out all sorts of wired/retard combinations and made sure the thing wont break. You got to make it idiot proof that was our end goal.
I cannot say we completed this 100%, to a done-done state. UES first cut does not have automated tests. If we had that in-place we could have saved some valuable time.
We are working on it, a framework to test jaggeryjs applications and we will make sure that’s in place in our next release.
Documentation
Plays a major part. Its the place actually you realize how usable (or not) your product/feature is. We had those awkward moments, when the person who write the documentation comes and tell us “this doesn’t make any sense”, we had use the entire vocabulary to explain the reason behind some features. So do it early as possible, coz documentation made us remove features and redesign some.
Tools
A life saver. We didn’t have many, but we had few of the best. We used Atlassian Jira to manage our tasks and milestones. We used Atlassian Bamboo to get the build going. We used GitHub to mange our code repository. Those tools made things easier for us. Bamboo made sure that there is a nightly build everyday and Jira dashboards showed us where we were in the release cycle.
In summary above are some of the important things we did right (and wrong). These may not be the perfect way to manage a release, but following the above protocol, did take us where we wanted to go.
Maybe I will learn more with time and realize that there is more to it. But for now I am going to follow this until I realize otherwise 🙂
@nuwanbando 