Scaling Agile Peer Conference

Agile Finland arranged a nice peer to peer conference around Scaling Agile. Venue was Life Science Center in Keilaniemi, Espoo. First of all I have to say that facilities were excellent. Top floor sauna with a sea view.

Participants had been pre-selected and there were people from eight companies. All the participants were required to write an experience report about how they had scaled agile or transformed the organisation into a more agile form. The seats were arranged so that everyone could be in eye contact with all the others and discussion was very easy. 

The day was packed rather full. We started already at 8:30 in the morning and finished around 17 o'clock in the evening. As we agreed not to share too much about each others practices and processes publicly, I won't get into details. But some interesting topics/practices I dare to share were the 24 h hackathon, group Backlog and a team building event where people had to self-organize into teams. Also, a topic that was common to almost all the participants was the Product Management. That's the not-so-trivial interface between business and development. Maybe that's the unicorn of Agile. ;)

I'd like to mention a very interesting facilitation technique called Open Season. Everyone had four cards: green, yellow, red and blue. Green indicated that you want to start a new discussion thread. Yellow meant that you still want to add something to the current topic. Red meant that you need to speak right away and blue that this is boring and let's move on. Red and blue were never used, but otherwise the conversation worked very well! Actually you can find a rather elegant guide on how to arrange a peer conference from this blog entry. I think we followed it very closely.

My best take homes were definitely the new contacts. Hopefully we can grow even more agile together! Also it was nice to get to know how other companies have been scaling agile. And by the way, if you ever think of arranging a conference like this, think no more. Do it! It will be great.

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

Scan Agile 2013

On November 11th I participated in the Scan Agile 2013. That's the biggest Agile conference in Scandinavia.

It was awesome! There were plenty of interesting presentations by different agile gurus. Brightest star was Dean Leffingwell who concentrated mostly on the Scaled Agile Framework (or shortly SAFe). Interestingly he was giving a lot of thought on XP practices. I had not realised they were such closely connected with the framework. I'm huge fan of both Scrum and SAFe and it was very inspiring to meet Mr. Leffingwell in person. As a matter of fact I was such a fanboy that I asked for his autograph. :)

(On the next day I participated in another session hosted by Nitor Creations where we sat around the same table. Discussion topic was Scaling Agile.)

There were four separate tracks and one could leap between the different tracks depending on personal preferences. The next talk I watched after Dean Leffingwell was by Arto Miekkavaara. He represented NeuroLeadershipGroup which is an organization founded by David Rock. I've been aware of the SCARF model for quite some time, but a little refreshment never hurts. 

Next I watched a presentation by Neil Killick. It was about the currently very popular NoEstimates. I have to admit that I didn't really understand everything about this. But the main deal seems to be that instead of estimating in non-dimensional Story Points that describe both the size and complexity, we aim to split the work into such pieces that are of same size. That way the number of stories becomes the measure of velocity. Interesting topic never the less.

Even if Leffingwell had the keynote, I think maybe the most inspiring presentation was given by Andrea Tomasini. Good stuff about the Anatomy of an Agile organization delivered with a great passion. Thank you Andrea, I really enjoyed your spicy speech!

Most of the other talks were about processes and frameworks, but Janne Sinivirta went deeper into the actual work. He educated the audience about Lean Architecture. Yes, I believe architecture is needed. (Maybe it's because I'm SAFe fanboy...)

As a conclusion I'd say Scan Agile is a conference worth participating and gathered a lot of familiar faces from different agile circles here in Finland. Again next year? If possible, yes!

In the near future I will keep on pushing the Agile transformation in our company. (Or maybe push is not the correct word. Coaching and collaborating on the issue would be closer to truth.) I will also need to try the role of a Product Owner. Kind of like a jump to the other side of the fence to see if the grass is greener there. Interesting times ahead!

Failure, It's Not a Bad Thing

I stumbled today into a new concept. It is called Day for Failure and I think it is very interesting and should be recognized more publicly. The web is full of those 'motivational' pictures about epic fails. Those are amusing. But on the other hand, I think failure is seen many times in too negative way.

Failure is a blessing! It tells you that you did something that you shouldn't try again. It's offering you valuable insight about how life works and something even more important. Failure opens a door for learning.

Mr. Edison might be the most known people to fail. Or as he puts it, found ways that don't work. But I think the main message is this: you only fail if you give up. If you make a mistake and learn, you haven't failed in this negative sense that so many people use. Or we can call that failure, but it's still a good thing.

Lean Startup along with the concept of Validated Learning has been one of my favorite books. Probably due to it saying the same thing. Experiment. My mistakes. Fail fast. And then try again. The faster we fail, the faster we gain more knowledge. And the safer and less costly we make failing, the more we can utilize its awesome power.

So next week, on October 13th and after that, start building a new culture at your workplace! Share and celebrate failures. They offer you and your colleagues information and learning you could never achieve by always staying on the safe side. And by sharing the experiences, you don't have to repeat the same failures but can try new ones.

Facing the Reality in Product Management

For some reason Software Development is somehow so far from the physical world that it is very easy to neglect the truth for a very long time. Managing products is one area where I have faced some horrendous gaps between the plans and the real world.

This picture of Chinese traffic jam has become one of my favorites lately:

Unfortunately I think it characterizes the amount of things some people think can be done in parallel. A Product Roadmap that has nine things that should be developed in parallel. By one team. Of about nine persons. If you say it out loud like this, it's probably evident that it's not going to happen. But if you just add boxes to a PowerPoint, it's deceitfully easy to just add one more box. ...and yet one more.

My solution asks for another picture. 

"There you go. I think your Roadmap is great, but it only has this one flaw. Everything you have there needs to fit through this funnel." Well the diameter of the funnel of course depends on the team size, but I think one-piece-flow would be something to strive for.

Doing things in priority order one by one. Creating the features that offer the biggest customer impact and added value one after another. Doing things pragmatically and keeping the focus. Let's try to get there!

Children are Excellent Teachers

I recently had a discussion with my son's kindergarten teacher and she told me how my son's group has been teaming up very nicely. They play together and everyone has found their place. Some are carrying sticks, some build things from those while some of the others are more involved with the planning. When, inevitably, there's conflict, they say they are sorry and the situations resolve quickly. And when they do sports, everyone is rooting for the others like crazy!

If preschool children can do this, why is it so hard for us grownups?

When the organization is still going through the agile transformation, it's probably not uncommon that people only think about their own tasks. "I have done my part. It's not my fault if the others don't keep up." But in an cross-functional Agile team you are not merely accountable for your tasks. There are no "your tasks". The team has goals and the team members are ALL equally responsible for the results.

This will probably become clearer over time. But in a bigger organization, I'd like to reach the next level. I see an analogy between one team and a Sprint and between several teams and a Release. My personal vision of a larger organization is such that teams working on the same product pull one rope. If one team is struggling and the others have finished their commitments, they will help. No team is left behind! And maybe in a larger organization this would scale up still one level, but I have no first hand experience about that.

Great things are achieved through doing things together!

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!