Release Planning Day

Earlier this year I wrote about our Release Pre-Planning. This time I wanted to take things a bit further. We had previously been discussing about the Release Planning Event described in the Scaled Agile Framework. Going for a two day meeting with the whole company sounded like something that could be useful, but would maybe require move convincing than I could do in a short period of time. But if I started with just one day...

So I made a preliminary plan for a one day's Release Planning Event. Rough schedule with the important events and list of requirements from some of the key actors like the Product Managers and Business Owners. Then I communicated this to our technology head who received a nice buy-in from the whole management. Of course something like this could not take place without a proper management support. After this I invited everyone in the company to the event.

Fig 1. Schedule of the Release Planning Day

As a groundwork, the Product Managers were asked to put their Roadmaps in order and the Business Owners to prepare for a short presentation about the current state of our business. All the necessary meeting rooms were booked. The main meeting hall has high level audio-gear with microphones and loud speakers. We have development teams on multiple sites. (Actually I booked almost all of the meeting rooms in the office to make sure people would concentrate on this event. ;) )

At the start of the day I gave a really short overview on what would be coming. Then we quickly moved into the business context. Our two Business Owners told us briefly about the most recent trends in the markets and what could expected in the future.

Fig 2. Different levels of planning.

Next, our Product Managers presented their updated Roadmaps. Figure 2 is very close to the view I have on breakdown of different levels of planning. Outside the outermost circle I would still like to have company strategy, but I'm lazy with the pictures. As the Roadmaps are still rather new concept for us, they again raised a lot of discussion, but in a constructive spirit.

Surprisingly after first hour and a half, we were still on schedule! After going through the Roadmaps I explained the plan for the rest of the day. The purpose for the whole day was to craft Release Plans for our product teams. In addition to those, I wanted people to identify the possible dependencies and potential risks. Making those transparent would help us address them later.

Then we had the first Team Breakout. People moved into their team rooms together with the stakeholders. Target was to get some kind of draft plan that could be refined later. This time period included also the lunch (most people are more productive if they get a decent meal during the day.)

One o'clock in the afternoon we met again with the whole company and started to go through the draft plans. This was also a time to face the reality and notice that some Product Owners and one Product manager were not present hence making it impossible for some teams to craft their plans. This was remedied by agreeing that those plans would see the daylight next week. No panic there.

But going through the draft plans helped to identify a couple of topics: as quite often, some of the plans were really optimistic. And there were dependencies between the teams and some general confusion about what to do. We didn't settle these problems right there and then. They were just identified publicly and settled later by the teams themselves.

Originally I planned to have a physical board for writing down Risks and Dependencies and a webcam for having it visible in the remote offices. Then I realized that it would make more sense to have the board in digital format, so in the end the things were written to a Confluence page.

Second Team Breakout helped to build more realism into the plans. At the end of the day we met again at the common square. This time the plans looked a lot more realistic and people gave a (really symbolic) vote of confidence on the plans. Some of the plans could have been refined a little more, but the results were satisfactory. We had plans for eight teams working in three countries!

After the day it was quite clear that this will be a practice we will keep on doing. Personally I was really happy to see people take this seriously but with a small twinkle in their eyes. People participated, teams got their Release Plans and people from business and development worked together. In the end, I believe that's the essence of Agile Software Development.

Some things that were left for the next time: estimating the business value of the release objectives and things regarding the architecture vision. Also worth considering if this could be worth spending the full two or one and a half days on the topic. At least I think it's better to have it in one go than to plan for weeks.

Proper Technique

Again, I'd like to share some real life experiences and thoughts they have provoked. I learned how to swim at the age of seven. Since then I have been able to float on the water and transfer myself from one place to another. But I have never been very fast. And some of my friends have politely described my swimming style either as resembling a beater or that I'm "trying to crush the water".

This week I attended my first swimming technique course. We were swimming just freestyle and practicing the breathing technique. We were in the pool and the instructor told us what we could improve. I'm not sure the results were tremendous right away, but with every pool length something was improved. Towards the end of the session, I felt like I had learned to swim in a new way. (Interesting fact: only 10 % of the propulsion is produced by legs. And for amateurs not even that much.)

There are some important lessons to draw from this. Coaching, mentoring and teaching are efficient ways to share knowledge. If you don't know the techniques, you could seek guidance from a master. It's not embarrassing, it's wise. The second thing to note is that you will easily become blind to your own performance. An outside observer with a fresh pair of eyes can help you notice new things. And finally: only practice makes perfect. Now, after the teaching, I have a faint idea of what the proper technique is, but without practice I will just regress back to my old style. 

And the same applies also to Agile software development. Get your team a Scrum Master or an Agile Coach. Or if you are such person, consider seeking guidance from a more experienced practitioner. Mastery is an asymptote which you can never reach. But you can always get better. 

Perfect road is always ahead

Development Discussions

When I think about development discussions I have a bit mixed feelings. I strongly feel that people need to be nurtured and given chances to develop themselves. They should be encouraged to find their current limits and surpass them. Organization needs to support employees professional development by allowing (or even insisting) time to be allocated for practicing and learning new things. But then again, the initiative should come from the person him-/herself.

One of the saddest things I know is when people afterwards say that "no-one developed me". In this case afterwards means when people have been fired due to their low performance or because their skills have been outdated beyond repair. Fortunately these are extreme cases, but I also feel bad when people who still have jobs are not interested in learning new things.

I seriously doubt that it is possible to learn everything you need to know in school/university and then just apply that knowledge at work until you receive a gold watch and a nice retirement package. Maintaining your attainments is simply a must. And not just in a niche speciality area. Let's say you knew everything there is to know about VHS cassettes. After the introduction of CDs, Blu-Rays and set-top boxes rules of the game changed. The things you knew just weren't valid anymore. Or they were valid alright, but no-one cared because no-one used VHS anymore.

And this is why I believe everyone should craft their own development plans. Your knowledge/career is your product and you should be managing it. Think about where you want to be in five or ten years and what skills you still need to obtain. Then keep that in mind in your next development discussion. If you don't say it out loud, how can your company help you reach those goals?

Set your own goal, keep it in mind and pursuit mastery. External motivation is so 90s. :)