Aug 28, 2014

Second Release Planning Day

Before the summer I wrote about our first attempt to do a whole company Release Planning Day. Since we do releases in regular cadence, now was the time to try this activity again.

After the first trial I had received feedback that doing everything in one day was maybe a bit too overwhelming. One concrete remedy was to divide the activities to two days. Another improvement that I was happy to witness, was that this time the Product Managers really prepared for the event. They discussed and worked on their Roadmaps together with the teams during the past couple of weeks. And this activity really paid of in the quality and in the level of realism.


People took the event seriously. Even though one of our Business Owners and a Product Manager were visiting customers abroad, they took the time to do their part in the agenda. Their presentations were broadcasted over a VOIP connection. But for me the message was clear: this event is really important.

The first day started as during our first time. The schedule for the day had been delivered to everyone already via email, but I briefly revisited the agenda. Then our Business Owners gave an overview of the market situation. What is happening now and how we should prepare for the future.


Next the Product Managers shared their Product Roadmaps. We are still working on these and lot had changed since the last Release. Mainly many not-so-well prepared themes had been dropped and returned back to the funnel stage. There were clear pros and cons for this approach. Now the organization was able to focus the attention on the few Epics, but on the other hand, the longer term visibility was missing from the plans. But I'm confident we can work that out in the future.

We are still figuring out our Architectural Runway and how to coordinate it on the Program level. But as the manager of our System Team, I used some time to tell about the tool changes we are about to carry out during the coming Release Period.


After the common sessions it was time to split into teams and start forming the draft plans. Teams collaborated with the stakeholders and tried to formulate the needs of the business into a realistic set of PI Objectives. Actually, in our company language we call these Epics, since that's how they are called in JIRA Agile. The lunch hour was also incorporated into the first Team Breakout.

The next common session was the Draft Plan Review. Every Product Owner presented their team's draft Release Plan. This way it was easy to spot if something was missing or required coordination with other teams. There were no major surprises. It was as if people had actually discussed their plans together. Oh boy, who could have seen that coming!?


After the Review there were two options. Teams could continue planning today or go home and rest. The next common session was scheduled for the morning of the next day. Since we have development team members in multiple time-zones, I thought it was ok to offer possibility to carry on the planning on one site and pick up earlier on the next morning on the other site. Also the splitting gave people more time to do the planning. And at least I felt rather exhausted in the afternoon already.

I don't actually know how the teams decided to do. Maybe some continued the planning, maybe some went home early. Anyway, the next morning we gathered again to a common session to go through the finalized plans. Most of the plans had not changed much since the draft phase, but I believe it was good to have time to digest them a bit and work out the dependencies if any. There were still some questions and comments but generally people were satisfied with the plans.

In the end I wanted again to have a vote of confidence for the plans. Just so that nobody could walk away from the event and say it was not their plan. At first it felt a bit silly. And it was. So in the end I turned holding the microphone to the crowd and yelling "DO YOU BELIEVE IN THIS PLAN!!?" And they did. :)


Aug 18, 2014

(Release) Version Control

During my holiday I noticed that Scaled Agile Framework had been updated to version 3.0. I did watch the short update video by Lean Samurai (which was nice and compact), but I haven't really had time to get familiar with most of the contents yet. Some positive first observations include dropping Hardening out of the HIP-sprint (nowadays only Innovation-Planning) and making an attempt to include also strategy into the big picture. Although I like IP more than HIP, I don't really like dropping the shippability from the PSI. I'm glad that separation between development and releasing is still there. Maybe I will learn to like Program Increments.

But the topic I was about to write today is Continuous Integration. It has now been lifted to the big picture to get the attention I think it really deserves. Scrum doesn't offer engineering practices (XP does), so companies should amend their processes with some additional common agreements. Let me now write down some clichés that have some valid points behind them:
  • You can't scale crap.
  • You can't go fast if you carry a lot of extra.
  • Integrate often.
Well, one could consider these also as plain facts. But the first two are more or less related to good coding practices and craftsmanship and staying Lean. Also keeping the technical debt as low as possible helps going faster. The last bullet is related to version control and software production.

We are applying the stable mainline pattern. To get a more thorough explanation on this please check here or here (again I find good stuff and it has Mr. Kniberg's name written on it. That guy is a wizard!) We use a rather well integrated set of Atlassian tools. Atlassian Stash as the basis of our repository management accompanied with Atlassian Bamboo crunching the builds. And they both communicate nicely with JIRA. (While looking for some nice pictures, I bumped into this video about making a demo integration. Maybe worth watching.)


When the code changes are checked in, the builds start automatically. They include running the automated tests (unit and integration), followed by more wider range system level tests if everything went well. Good changes are blessed with a nice green color, but any breaking changes result in an ugly red color.


In Bamboo you can configure the plans to make builds for all new branches automatically. This makes the creation of release branches handy (compared to some other CI frameworks where you need to configure a new build for each new branch.)

Finally, the big dilemma when we make releases. We branch the release from the trunk. This is communicated well in advance to all the teams and developers. But after we make the branching, we don't allow any more changes to the code. Stash offers a handy way to do it from the branch permissions. To be more precise, we do allow changes, but they need to be made via pull-requests and approved by the System Team.


My dilemma here is that I'd like to believe in people. I believe most of the restrictions usually hinder development. But then again, I believe many people are aware of the term feature creep. It's easier to fight it if you don't have a way to make changes. And the obligatory pull-requests have a built-in code review which usually helps improve the general code quality.