Importance of Environment in an Agile Transformation

I attended today a SAFe 4.0 event arranged by a Finnish training company called Nitor Delta. As a guest speaker they Michael Stump from the Scaled Agile Inc. The event was also a good meeting place for SAFe practitioners. I must say that I saw quite a few familiar faces. And met many new people who I can hopefully later exchange experiences with.

After writing a case study, my company has drawn a lot of attention from other (potential) SAFe adopters. I have a bit mixed feelings about it. Of course I'm happy and proud about the attention, but being a Finn, it's difficult to handle the situation. And then again, since I see all the daily difficulties we deal with, I sometimes feel tempted to say "..but we still face these difficulties". But maybe there's no need. I guess everyone understands that things are in reality much more complex than in theory.

From http://finnishnightmares.blogspot.fi

But from the conversations that I participated after Michael had finished his presentation I learned that environment matters a great deal in SAFe/Agile adoptions and transformations. First I was somewhat against the idea of training everyone at the beginning of the adoption process, but maybe my first impression fails me there. In some cases I think even training is not enough, but some people should get their brains totally rewired. I mean, if you have done something in the same way for decades (or even years), it could be overwhelming to modify your daily routines.

If I think about possible factors why the transformation was successful in our case, I could easily list at least a few. There was a big management support. Previous and current heads of R&D were supportive for the idea and also the Chief Quality Officer. I think also the CEO saw potential in the new practices.

We had already been trained in Scrum when the big organizational change was initiated. All developers had received training in Scrum essentials and every Scrum Master and Product Owner was certified. Scrum Master and tester Communities of Practice were also formed right at the start. So good practices had distribution channels.

Release Process was established even though at first we didn't plan the releases. But the decision to shorten the release cycle was made. Release Manager, a person who would facilitate the release planning and execution was also appointed right away.

Then I think a big deal of the change can be credited to a couple of champions. People who were in key roles (RTE, Owner of Software Development Process, Chief Portfolio Officer, line management of R&D) made big contributions. Having a vision of how things could be done was important, but just as important was the support from these champions. And finally the support and engagement of employees. Everyone wasn't eager to embrace the change at first, but enough many were.

During the conversations with other companies I have realized that there are other, more subtle things that supported the transformation. Some that I had never even thought of since they are rooted so deep in the culture and operations. The organization is not flat, but there are exceptionally good possibilities to access information, suggest new ideas and to participate in the decision making. Also the developers are treated as experts. And there's one company value that I hold in the highest respect: Enjoy Working Together.

In the development money is not an issue. I mean, there's no unlimited budget, but people in development get to fully concentrate on the contents. If something is considered worth doing and there's clear potential, it will be done. There's no sharing of the blanket between different business units. (I have never needed to worry about CapEx or OpEx.)

As a conclusion, I think there were quite a few things that made the transformation possible. Some are such that people living inside the system do not even perceive. In a way I'd be tempted to say they don't realize how lucky they are. So let me conclude my post with a few pictures.

Office Breakfast

Foosball table

Hackathon trophy

Release Planning With Customer Focus

I've written about our Release Plannings already (here, here, here and here), but maybe there's still something to add. These blog posts also help me understand how things have evolved over time.

This time we had agreed the Release Planning Day, our common company event, would only serve as a deadline for having the Release Plans done. So all the actual planning was done before hand. One tool that we extensively used was Microsoft Yammer. It has proven to be handy for sharing something get insights from different stakeholder around the globe. In addition there was a lot of face to face planning between the Product Managers, Product Owners and Development teams.

I had split the day's agenda into the following parts:

• Agenda and purpose of the day delivered by Release Train Engineer
• Where We Are Heading, market insight and Portfolio funnel status by Chief Portfolio Officer
• Product Roadmaps by Product managers
• Lunch and team break
• Each teams' finalized Release Plan by Product Owners
• Launch Plan for each product/solution by Product Managers

I think out of these probably all other items are familiar from SAFe except the Launch Plan. And actually even that is in SAFe. There the name is simply Release. But in our company lingo we have used the word Release for both the Potentially Shippable Increment (PSI) and for the actual Release.

Previously our Release Process ended when the PSI was done. Development and releasing were decoupled. Although this is often beneficial, it had proven to generate a lot of confusion. Sometimes we had a PSI, but no plan on what to do with it. We had concentrated too much on the technical side and forgotten what our whole system was supposed to do: provide our customers with new increments of working software and added value.

Launch Plan is an attempt to look at the same topic, Release, from the customer angle. In bare minimum I want the Launch plan to answer these questions:

• Who are the target audience for this Release?
• How will we communicate about this Release to our target audience?
• How will we deliver the Release to our customers?

Also the Launch Plans seemed to reveal interesting new things about the organization. What we talk about as Release is usually just release of the software component. Creating the PSI doesn't take into account how it will be delivered, configured, trained to new users or marketed. All these are really relevant topics and especially relevant for the customers.

I think generally the Release Planning Day was successful. It was shorter, more focused and took the customer view better into account. In short I would claim it was the best release planning we have ever done. But just as a note for if you plan to try this in your organization: this wasn't our first time. Without the shared history and previous steps on our path I don't think it would have gone like this. So don't try this at home. (Or who am I to decide. Maybe this is the killer recipe that works as a silver bullet. I've tried it once and it worked for me. :) )

As a main takeaway for next time I think we'll be increasing the cross functional collaboration and trying to take all relevant functions into the game, not just development. I think by tweaking our system we can reach so much further than where we are today!

Release Planning in One Day

In this blog I have shared experiences of our Release Planning Days. Of course the first one was most memorable since back then everything was new and exciting. Second attempt proved that it wasn't pure luck, but that the concept was actually working. I documented also the third one, but after that I thought that it maybe isn't that exciting anymore.

One unfortunate thing to mention is that the day was a public holiday in one of our offices. But quite a few of our colleagues from that site were willing to come to work on that day and get another day free in exchange. I call that going the extra mile.

But maybe I can tell about the most recent attempt, since it was again a bit different from the previous times. For our latest Release Planning I had given some of my colleagues a few chores to fill in advance. Here's the list:

• Portfolio Backlog is in presentable state
• Product Managers have discussed their the Roadmaps with teams working directly with them
• Product Managers have made an initial Launch Plan for their products
• Product Owners have crafted Draft Release Plans for their teams

Out of these, the first task went to our Chief Portfolio Officer who is like the Grand Vizier of the Portfolio level. Second and third tasks went to Product Managers (Program level) and the fourth one to the Product Owners (Team level). 

Launch Plan is a term that isn't originally from SAFe (as far as I know). It communicates the intended usage of the Release if and when it would be successful. Previously we had identified a waste of extra waiting time when the Release was ready, but we had not decided what to do with it. The accompanied business needs are in most cases clear already when the work on the release starts. That's why it is practical to craft also a plan about the usage. And if something is left our the Release scope, the plan can be adjusted.

So, in essence we skipped the first Team Breakout. Also the organization of the presentations was modified. In our past Release Plannings all Product Managers have presented their Roadmaps in a row. But since we had the Draft Release Plans already available at the beginning of the event, I wanted to form logical entities of the Roadmaps and associated Release Plans. This also helped in focusing on one subject at a time.

The morning part of the day was heavy. That was clear already beforehand. But we didn't come up with any better alternatives. At least grouping the presentations in the new way was seen as an improvement.

All in all things went pretty much as expected. During the Team Breakout some plans were modified but most of them were almost the same as during the draft phase. The new, more compact way of conducting the day seemed to work well and we will probably do it like this also next time.

Answers to Open Questions

This time I'm writing a little differently structured blog post. Pierre Godts asked me the following questions at the Scaled Agile Framework group at LinkedIn. The question is related to the SAFe Case Study I wrote some time ago. So let's dive a bit deeper into some topics that were left our of the study.

Can you tell us more about the change at employee level? 

The change touched mostly people in the development. Previously all developers (coders and testers) had been in one big group and everyone shared the same supervisor. Work was organized around projects that were resourced from this pool of developers on a monthly basis. Projects were steered by people working in the business units.

After the change people were assigned to (Scrum) teams. Each team was appointed a Product Owner who was a member of a business unit. POs reported to the heads of business units (Chief Product Owners or Business Owners). Teams started to follow scrum way of working. During the same time our internal processes were also identified and written down. Release cycle was set to three months although we knew that we would probably face problems in the beginning.

Each team elected their own Scrum Master who then started to facilitate the events and see that we followed the scrum ceremonies. They were all certified (as were the POs). Scrum Master Community of Practice was also established and Chief Scrum Master started to facilitate it.

At the beginning Scrum Masters participated in a weekly Scrum of Scrums meeting. This was later replaced by a meeting that was between any member of each team. Scrum Masters started to have regular get-togethers where they discussed process related affairs and possible impediments that needed to be raised to company level.

What was their commitment to change? Were employees skeptical or not willing to change? 

People are all different. Some were more skeptical and some were more like early adopters. I belong to these guys who usually get excited about new things easily. But generally I'd say people were rather committed to the change. The previous state of the company was not really optimal either so I think there was a really fertile ground for some change.

And as depicted in many change management related books the early and late majority just needed a bit more time and discussion. Maybe with some more coaching the change could have been faster. In our case teams were more or less left to figure out the steps themselves. But maybe we just did it with some luck.

Did some employees got fired? 

No. No employees got fired during the reorganization. But some didn't like the new way of working and decided to seek their destiny somewhere else. Some started their own company, some simply changed employer. I claim that quite many of these people had been thinking about the change already for a bit longer while. The reorganization was just the final nail into the coffin.

But one really positive thing is that some people have returned. They have seen the greener grass but understood that maybe it's due to more fertilization...

Were new employees hired? 

Yes. The company has been growing and new teams have been established during the past years.

Was there an increase in number of employees? 

Yes. Same as previous question.

What about stress level, increased or decreased? 

This is tough one. Depends. No-one probably misses the long death marches when we tried to get the release together after a year of development. Or the feeling that if I don't get this feature into the product the customers will need to wait for it for another year. (This would inevitably increase the scope creep and result in not so well tested additions at the really late part of the release cycle.)

But then the other side of the coin is that previously some developers had a really big areas of responsibility. This would mean that you could potentially save the whole company by fixing some issues and get credit from everyone. When you are working in a team, it's usually the team that gets the credit. But I see this again as one inevitable thing that happens when a company grows over certain limit.

What about the budgets/costs, controlled? 

Honestly I don't know the answer to this one. Probably the budget was controlled, but it was done in so smooth way that it was never evident. More I would say people didn't take the full benefit of their empowerment. When you have been just a resource and someone else has been managing you or your project for long enough, you don't really understand what it means when your boundaries are removed. It's a slow process to get people to see that "Hey, can I do this? Ok, wow, I can!" And it feels great. As an employee it's a bit scary. But as a supervisor I think it's great to empower others!


Did the use of Jira cause problems/difficulties?

Not really. With our distributed setup JIRA was really an essential tool. I like physical boards and post-its but with multiple sites it's a luxury you can't really afford. And when you accompany JIRA with other Atlassian tools you can get real transparency to the development. You can see whole chain from idea to source code to testing and finally to the product. And with documentation included.

Using Scrum for Strategy Work

I'm continuing with the same subject I wrote about last week. Repetition is key to learning. And another important way to make things stick is to tie new information to previously obtained knowledge. At university I noticed the same thing with equations, groups of equations, matrices and linear operators (and functionals). Once you study enough maths you see how beautifully many things are connected...

But getting back to the point. I'm participating in our strategy work. Probably going into details about it would be wrong in so many ways that I won't even consider such option. But I think the (Agile) process how we are producing the new strategy is so interesting that I'd like to share it.

One way to produce a new strategy is to assign the task to a couple of persons. Then they spend some time (X months) to gather data and make relevant analyses and present resulting strategy to CEO and/or Board. Then the strategy might be accepted or some modifications are requested. Process is effective, because the people working on it don't need to negotiate much and they can move fast. On the other hand, the result is produced by the mental energy of only a couple of people. And these are also the only people who know the new strategy at the beginning.

In our case the work is split into work streams. Each work stream has an Owner, a Facilitator and a dedicated team. Teams produce their own piece of the general strategy puzzle, but they need to make sure they are aligned with the other work streams. This is achieved via cross-team communications (which is always non-trivial) and facilitated through weekly Facilitator Calls. Teams also have regular sessions when they all meet, present their current findings, challenge each others current results and generally push each other forward. This is also a session that feeds the overall strategy which will be the crystallized result of all the combined efforts.

If you have used Scrum with multiple teams you might spot some similarities. I think the work stream structure is a one-to-one match with a Scrum Team. It contains (Product) Owner, Facilitator (Scrum Master) and a (Development) Team. The Facilitator Calls are like weekly Scrum of Scrums sessions that are used for cross-team synchronization. (Of course this close relationship with Scrum is not that much advertized.)

I can't think of a good Scrum match for the session that combines the results of the different work streams, but there's one in SAFe model. These regular sessions bring to my mind System Demos. All in all the work is like traveling on board an Agile Release Train. The end result will be full-fledged strategy that is already well understood by the people who have been crafting it. And although this probably costs the company a lot more in the short term than a strategy crafted by only a couple of persons, I think it's a clever investment. If we have N work streams with M members, it totals N x M people who are already quite familiar with the new strategy. I think that is already a really nice sized Guiding Coalition.

And maybe still one thing that I want to add (because I'm so proud of it): the strategy process is out there in the open! Not in the basement, nowhere lurking in the darkness. Anyone is free to give input. People are encouraged to discuss and even the meetings are held in open space. Transparency. A cornerstone in Scrum. To me it signals trust.

Maintenance vs New Development

Blogoverse is awesome! Here everything I say is the truth, because there are no counter arguments. In reality it's not always that easy to get people convinced. :)

I'm giving here an example situation and my opinion for a solution. The readers are more than welcome to offer their opinions and join the discussion.

Our releases are planned in cadence. Teams craft their own objectives which we call simply Release Plans. Then the Release Train Engineer (which is me) gathers those so anyone in the organization can quickly get an idea of what will come most probably is coming out in the next Release. The Release Plan is a list of features and changes to the software that we predict to be ready by the next Release Day.

Now, depending on the magnitude of technical debt, maintenance burden, customer contacts and possible fire-fighting issues, some teams have a lot less capacity for developing new features. It can be that over half of their time is usually spent on something else than new features. Like fixing bugs or refactoring. Taking into account all the facts, that's ok.

Somewhat due to misunderstanding and also because it doesn't feel nice to present an empty Release Plan, the teams urge to have also the maintenance issues in their Release Plan. This would make it easier to communicate why they are not able to create so much new business value. Seeing how some people have failed to understand the difference between Release Plan and what activities the teams are doing during the release period, this seems like a valid point.

But personally I find this to be a dysfunction. I think it's the team's choice anyway how they spend their time. And since we have all the maintenance issues in our Product Backlog, the people who are interested in what's happening in the team's daily work can check the situation there. Or participate in the Sprint Reviews. Or go and have a chat with the team or just look at things are going. There's no lack of transparency, people just need to go and have a look.

I see an analogy between this and the work of individual team members in a Sprint. For me the essence of Agile software development is that we have skilled and disciplined individuals who are the best judges of how to do their work (and spend their time). No-one should be micro-managing them and telling how to do their job. It's an issue of responsibility. And trust. If you are more into waterfall, go get yourself a Project Manager. ;)

But as the Scrum Master is educating and coaching the team, I find myself responsible for educating the organization. Don't worry, I'll do my best. Challenges make life interesting!

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. :)

Leading SAFe

Since sharing personal impressions about SAFe trainings has become almost a norm in the field, I also want to stick my spoon in the soup.

I participated in a Leading SAFe training given by Maarit Laanti from Nitor Delta. After reading many rather critical blog posts about these trainings (actually they have mostly been about SPC trainings), I was very curious to get some first hand experience. Probably the quality of the class depends on many things: the trainer, the participants and the chemistry between the actors.

I was very positively surprised! We were given opportunity to ask questions and share our expectations at the beginning of the course. Some were more interested about the Portfolio level, some about the Program and the Agile Release Trains. Contents of the course were customized according to the participants' interests. I think all the questions were answered in a credible way and the shared real life experiences were the bread and butter. Maarit also demonstrated a very healthy criticism towards some of the contents. I don't give big credit to people who just preach without understanding what they are really talking about. I think our trainer displayed profound understanding of the topics she taught us about.

And (good) videos are always nice. I was already familiar with some of them like the Daniel Pink's video about motivation

and Henrik Kniberg's excellent animation about Product Ownership,

but for example the video about Deming's willing workers and the effect of the system was a new acquaintance to me. Served as a good eye opener.

In the end, Leading SAFe course (and the Scaled Agile Framework) includes topics about Scrum, Lean and Systems Thinking. The highest Portfolio level doesn't seem to be that mature yet, but I see that and some of the more prescriptive parts mainly as extra tools. If you set those aside, the rest is something that not many Agile gurus (= people who manage to stay successful in ever-changing environments) could have anything against.

Sami Lilja has criticized that scaling in itself is solving the wrong problem. But I don't think people and organizations always have a choice. Decreasing the size of the system or splitting it into smaller pieces could be the ultimate goal, but personally I think having this toolbox at least helps to cope with the current situation in many organizations. Every path starts with taking the first step.

Owning Products and Owning Companies

In the corporate world mergers and acquisitions happen. A start-up first has a dream which the people working there actively pursuit. If everything goes well, there might someday be a financial success and possibly another company will decide to buy this start-up. This might take a short time or a longer period, but the fact is that most start-ups fail to see this day all in all. But what does this have to do with Agile? Maybe something, let's see.

I'm sharing here an example where I think an acquisition happened as smoothly as one can ever imagine. The buyer is not looking for a short term profit. They have a solid cash register and they invest according to their values. And they value quality and reliability over anything else. Getting dirty hands is OK. It's a sign of being a professional. You are ready to do what is needed.

I like to map things to a smaller scale because it's easier to apprehend. I think above mentioned acquisition compares nicely with a Development Team having a new Product Owner. And in this case the Product Owner is clearly stating that instead of feature creeping, the PO is more interested in getting solid increments of working software. What more can a team ask?

The bought company will also stay independent and can continue operating as they have done before. Talk about empowering the team. And this message is delivered by a very senior executive with a background in culture where losing your face is avoided by all means. And he wants to deliver the message personally because he sees the face to face interaction as a must. I think that builds trust.

Just a few hours after the announcement the people in the company are able to carry on their work and with a rather high spirit.You know something has been done correctly. Or at least not totally screwed up.

Build trust. Empower teams. Strive for quality over quantity. Envision the shared dream. These things scale.

Successful Pre-Planning

Sometimes things just go smoothly! Today was one such day. Today was the Pre-Planning of our next Release. Everyone was well prepared. As I have previously written, we are currently experimenting with Scaled Agile Framework (SAFe). We have Product Visions and Roadmaps. This is an area where we have especially put our efforts on lately and it really starts paying off!

We had a two hour session. First some general information about the schedule and then introduction to not yet so familiar concepts of Themes and Roadmaps. Then the Product Managers introduced their latest Roadmaps and explained the business drivers. It was nice to see the leap in the quality since the previous Release.

After the Roadmaps, the Product Owners shared their teams' draft Release Plans. Some of them were not yet very realistic or contained way too many things, but it was good to have visibility to this none the less. Seeing some draft gives a lot more possibilities for improvement than having nothing at all.

Hopefully this two hour event gave the whole company a better view on where we are and where we want to go next. As the coordinator and facilitator of the event I felt it hit the spot. But I have a tendency of being over-optimistic from time to time. ;)

On a side note, I finished reading Management 3.0 by Jurgen Appelo. Great book! I can already see myself trying this stuff in action.

Planning Releases

I believe I was just getting the hang of this Scrum thing and I thought I could do some decent Scrum Mastering. But now the things have changed slightly and I need to jump "over the fence". For a bit over a month I've been working as a Product Owner and a Release Train Engineer. I can see that it's actually a lot easier to identify missing Product Owner as an impediment than to actually be the Product Owner and try to live up to the requirements of the role. There just doesn't seem to be enough hours in the week to constantly keep the Backlog in order and think about all the details. But maybe that's exactly the point. No-one is able to know everything in the complex world of software development and that's why letting go and giving the team the space they need comes rather naturally.

But then something about planning Releases. In Scrum everything happens around the Scrum team. Team forecasts what they can achieve during a Sprint and that's it. Achieved velocity, "yesterday's weather", helps to forecast what can be expected in a longer run if the backlog has been refined into a decent degree. But there's usually no mentions about what to do when you have multiple teams, multiple products, a bit of legacy and all in all a more complex situation than just complex.

I think Scaled Agile Framework offers nice way to see this from a higher level. Scaling to the level beyond teams and Sprints, I see Releases as a good logical logical next step. Also it seems like a good idea to set some higher level goals (or Objectives) that can be then divided into Stories when the actual work starts. Of course there will be some uncertainty associated with these goals, but I think they should be treated more as commitments than just some initial guesses that will be reformulated right after the first Sprint. Still, I don't support big upfront planning or waterfall. I just think that a bigger enterprise can't live without ability to plan ahead for longer than just two weeks.

Anyway, the actual planning of the Release is a complex task on its own. As the Release Train Engineer I wanted to arrange a so called Pre-Planning where all the teams share their initial plans and everyone gets some indication about what is to be expected. Then there will be time to work the plans out until everyone (or at least most of people) are happy with them. Then we can have can simply agree that this is the plan that we try to implement. And if it needs to be amended along the way, so be it. But the train will take off and only the future will show what's going to happen. ;)

Increasing Internal Communication

After the vacation I've been absolutely on fire at work! Seems that everything I do or try just goes pretty much as well or better than I had expected.

I can't remember exactly where I heard the term, but I got interested in Coding Dojo. We have suffered from teams being in silos and I've been thinking about possible activities to gather developers from across the teams. So I decided to arrange a Dojo!

Coding Dojo is a sort of workshop where everyone participates. There's a driver and a copilot (like in pair programming) and audience. Every five minutes (or any other agreed interval) people change places. Copilot becomes driver, driver goes to audience and someone from the audience becomes the new copilot. There ought to be one sensei also, but we didn't have one.

The subject for the first ever Coding Dojo was Async. No-one knew the subject that well and the group was able to successfully implement a small demo program. One improvement suggestion was that a bit better preparation would have saved a couple of minutes from the start. Point taken, inspect and adapt. ;)

I'm not a big fan of email, since people tend to ignore those messages. Or at least it is very hard to know if your message has been received and understood. I wanted to create a blog. First blog post could be a short report about how the Coding Dojo went by one the participants. It would be nice to get a developers perspective on this.

Third form of internal communication that I've tried this week was video. In a multi site company where people are spread around the globe, it's not possible to get everyone into a meeting room and just give a short training. And as I already mentioned, I don't have too much faith in people reading their emails.

I tried something new. I made a short PowerPoint presentation and uploaded it into our intranet. Then I started recording and talked through my presentation. It took less than ten minutes. After finishing the video and uploading it to the intranet I sent an email with links to both the slides and the video. I can warmly recommend this approach; the feedback was very positive. Of course, if it is an option, stick with the face to face conversation.

This video by Henrik Kniberg about Agile Product Ownership is simply the greatest educational video about any Agile subject that I have ever seen! It's been of great inspiration to me in the way of describing very complex concept in such a clarifying way. Thanks Henrik!

Scaling Scrum Beyond Teams

Our teams do Scrum. The lowest level of inspect-adapt-loop is the Daily Scrum. Above that are the Sprints that usually take one to four weeks. Most common is probably two weeks. This level is planned solely by the Scrum Team.

Our Sprints belong to Releases. We are currently satisfied with a pace of four releases per year. That means that a release comes every three months. With two week Sprints it means that we can fit six Sprint per one Release.

I know that in the most pure form of Scrum, teams produce each Sprint potentially releasable content. And there are probably no bugs. Unfortunately my version of reality contains a legacy product that has some known bugs. And since we have a long history and some dependencies, we really need to do some integration testing at the end of the Release cycle.

So we carry out an extensive Release testing at the end of each Release cycle. Currently we have reserved the whole third month of each Release for this, but the teams are free to use their best judgement on this. If they have everything tested in time, they can start new development already before the Release period is over.

The idea of four releases per year is actually taken from Scaled Agile Framework. We do not want to re-invent the wheel, so we rather use practices that someone else has found useful.

Release planning is carried out between Product Managers and Product Owners. Of course in the end the team needs to "accept" the plan, so we iterate until a mutual agreement is found.

Beyond the Release level are the Product Managers Roadmap and product Vision. And even above this is the Strategy. This whole setup is rather new, so I'll tell more once we have experimented a bit further.