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!

Solving Problems, Together

First of all, without too much advertising, I saw recently an interesting commercial with a powerful message. It was by a company called Wickes and it simply stated:

What more can you say? I think it says: craftsmanship. And it sets the expectation level on quality really high. If you create something and want to tell everyone about that with your back straight, I can imagine myself being interested in what ever you are offering. Hopefully they never have any quality problems. That would shoot them in the leg.

But I was actually going to write about different ways of conflict resolution. The examples that I refer to are from conflicts between parents and their children, but they sound very useful also in agile coaching.

Thomas Gordon's What Every Parent Should Know is a freely available pdf document that describes a conflict resolution where neither party loses. In a resolution to a conflict, if one of the parties needs to "lose", they most probably don't feel happy. They probably feel rather bad. And depending on the circumstances, this might inflict grudge. A historical example of this might be Germany after World War I.

If on the other the conflict can be resolved in a win-win manner, the resulting piece will probably last longer and the resolution process can strengthen the bond between participants. Very practical in parent-child relationships and also in team work.

Another interesting example came to me from my personal life. My son has sometimes difficulties in tolerating changes to plans (well, actually I also suffer from that from time to time.) He gets upset when he has to interrupt building LEGOs and come to dinner. I sympathize with him, but as a parent I also feel as my responsibility to keep the boundaries.

In his book, The Explosive Child, Dr. Ross W. Greene introduces a concept of Collaborative Problem Solving (CPS). If I have understood correctly, it was originally developed for kids with problems in controlling their frustration. Actually, I also found a website that explains the method.

But shortly, there are three ways to solve conflict in CPS: plan A, plan B and plan C. A and C are the extremes. In plan A, the parent wins (and child loses). In plan C, the child wins (and parent gives up his/her plan). The main message of the book is plan B. That's where the parent and the child work together to find a resolution that they both can accept.

There are three steps in plan B:

1. Empathy
2. Problem definition
3. Invitation to negotiation

I can't yet tell anything about the effectiveness of this approach, but if it can offer a win-win resolution for both parties, I think it's worth checking out. 

So all in all, again, everything seems to come down respecting our children/co-workers/others and seeing them as human beings with hopes and dreams. Very common sense stuff that is usually taught already in kindergarten. But we grownups tend to forget...

Also this reminds me of  Marshall Rosenberg's Non-Violent Communication. The main thing to understand here is that we all have needs and we live our lives trying to fulfill those needs. And if you can understand yours and other peoples needs and find a way to satisfy them all, there's no problem that you can't overcome.

People are Weak, Teams are Strong!

If you are familiar with Scrum, you have probably read that Scrum is different. It's different from the management point of view, but also from the developer perspective. In an expert organization where everyone has been a sort of a super hero, it feels weird to suddenly be part of a team. No-one is telling you what you should do next. And you have to be in close collaboration with your team members; possibly for the first time during your career.

Although in literature I often see that the lack of management support is a big impediment for Scrum adoption, I'd say that the employees themselves can also create interesting challenges.

It takes time before people accept the fact that they can get more done when they work as a team. If you have five tasks and five people it is not the most efficient way to start working on all of those at the same time. If you are familiar with Lean this is probably crystal clear to you. But in real life, it's not so easy to let go of the old habits.

Alone you can do small things, but if you are aiming to go higher, I advice you to take a team with you!

On a Ride with Heroes (or Bad Apples)

I went back to work today and read two interesting articles. First one was about "bad apples" in teams. Probably quite many are familiar with these people. At least I can admit that I have seen these.

It is very odd that when the company is going through a challenging period of moving from old way of working into a more Agile way, some of the most senior people see as their divine right to protest. In the past these people have been the heroes of the company: solving the impossible problems at the last minute, making that needed fix in no time and knowing almost everything about their domain.

Somehow these company's finest become anti-heroes. They start to undermine the Agile adoption process by not sharing information with their team members. We often call these people "cowboys". And because of their superior knowledge (especially when dealing with complex legacy software), just showing door to these people is not the option that management is eager to take.

In my opinion, the option the company is left with is to motivate these individuals. Try to see what makes them tick and show them how Agile can work for them. And maybe pipe down about the process talk and concentrate on how they can maintain their status as experts also when working together with a team. But it is not easy for the team. That I can assure you.

The second article was about Ericsson adopting agile. It is always soothing to see others have some similar challenges and we are not alone with our problems.

Creating value through Agile Coaching

I just spent one week at the summer cottage relaxing and going through my thoughts. One thing that I pondered was that do I practice what I preach? I do agile coaching and I'm interested in lean startups. Am I really adding value to my readers with this blog or am I just making waste?

I truly hope that the unique combination of different disciplines that I bring to the table offer some value for the readers. I have been recently interested in Scrum, agile frameworks in general, lean startups and lean thinking, testing, Deep Leadership, software craftsmanship and from my previous career working with legacy software. I'm pretty sure there are many others that have similar backgrounds, but hopefully no-one else with exactly the same. But if you do, please tell me how I should continue. ;)

My tips for today are simple:

• Empower the team
• Try to make them realize limiting work in progress brings results
• Trust and collaboration is the key
• If possible, test your ideas with real customers
• Don't be afraid to pivot if you need to
• Seize the day and enjoy what you do (each day)

Respecting Other People

I think one key ingredient in forming a working team is the respect of other people. People may have different skill sets and they may live in different countries. For as long as we see each others as individuals and equals, we can achieve great results.

I think some people, and maybe more often people with academic backgrounds, have a tendency to look down on others. With distributed or virtual teams this is even easier than in normal teams, since you don't have to see the others face to face so often. It is easier to start thinking about "us" and (or even versus) "them".

I would place respecting individuals and trust as the top characteristics to look for in people who are supposed to work in multinational distributed teams. And of course willingness to learn. But that's probably a must have in knowledge work anyway.

I think in a Scrum Team the Scrum Master should be the champion of these values. Constantly showing example of respecting others. Architects or newly graduates, it doesn't matter. Everyone in the team brings their contribution and help pursuit the common goal. And everyone deserves their place.

Live as if you were to die tomorrow. Learn as if you were to live forever.

Factory settings

Coding practices generally are not something that Scrum pays attention to. Also, teams should probably have  as few outside dependencies as possible. But there are certain support functions that can be centralized. Or at least we have.

We have one special team that takes care of our constant integration server. Automatic build scripts do the compilation and linking and run the unit tests. If the build or some of the tests fail after checking in new code, teams get a message automatically.

Each of the teams have their private playgrounds. In addition we have some integration builds that combine efforts of multiple teams. And some builds that generate data about code metrics: cyclomatic complexity, routine lengths, nesting level etc. These are extra services that save time for all the teams. And they can concentrate more fully on producing value for the customers.

This one special team handles also the packaging of the product. Putting together executable + manuals + creating installers. This knowledge is scarce so we have decided to do these activities by one team. Again, a compromise, but in a multi team environment saves lots of manhours.

If you are familiar with Scaled Agile Framework, this team would be called System Team.

Deep Thoughts

Some of the mnemonics from code writing work in coaching also. For example KIS = Keep it simple. Extremely good thing to always keep in mind. On the other hand, I think DRY = Don't repeat yourself doesn't work that well. Many times (well, always) repetition is the key to learning.

That's why I sometimes find it odd that there are so many different frameworks that basically teach you the same things you usually learn at the playground. Be polite. Say you are sorry. Play nice with others. Everything starts with the way of being with others.

Since we usually forget many of these important lessons, I'm going to mention here one framework that I've been especially happy with. It's called Deep Leadership and at least a couple of years ago Finnish army was using it in the military leadership training.

It's based on four cornerstones:

• Building trust
• Inspirational way of motivating
• Intellectual stimulation
• Meeting people 1 on 1

(I remember these only in Finnish so they could probably be translated in a better way.)

And although people generally seem to think that leadership skills taught in the army cannot be applied directly in working life, I'm a strong believer in this framework. And I think it's well in line with agile values and how I personally see that expert organizations should be lead.

The framework also includes extensive feedback from three directions: superiors, peers and subordinates. And you can never have too much feedback, right?

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.

Building Trust

One thing that I find very interesting in Scrum is the fact that the Scrum Master doesn't have any power over the team. So there's genuine need to persuade the people. Motivate them and get them to do things through leadership. And I think this lack of power is the key in expert organizations.

In case you are dealing with complex products, you probably have very intelligent people working with you. And usually those people know their value. If you boss them around and manage them too tightly, they will just pack their things and move to another company. So you need to have a light touch. Leadership is required.

And I think one key thing in leadership is building trust. Let's say there's a building on fire. Everyone is exiting the building in a rapid fashion. Who knows, the building might even be collapsing soon. But there might still be people trapped inside and they might need help.

a) You are always telling people what they need to do. They don't usually like it and people talk behind your back. You don't care since you get the job done. Who cares if you have to cut a few corners or lie in a couple of places? And if you hear something useful, you usually take advantage of it without thinking about others too much.

b) You always treat people with respect. You see others as persons who have their own hopes and dreams. And you realize you spend a lot of time with these other people, so you like to make sure you all enjoy your time together. If someone needs help, you offer assistance. When someone tells you something private, you don't spread that around. And every time you are true. Whatever happens, people know that you are telling the truth.

Okay, there are now these two persons: a) and b). Which one would you follow into a burning building?

Communities of Practice

During our Scrum adoption we first started by assigning people to teams. Afterwards it's easy to say that it wasn't maybe the optimal solution, but it was what we did. There was not too much steering from above, so the teams were left to figure things out on their own. There are both good and bad implications from this.

Teams were free to choose how they wanted to do different things. On the other hand, the implementations between different teams could possibly vary a lot. But variance is good. Let all the flowers bloom!

After some time the Scrum Masters saw a definite need for collaboration. We had a Scrum of Scrums, which was first only for the Scrum Masters. After starting as the Chief Scrum Master I wanted to modify this practice slightly. I wanted all the team members to have access to the SoS, but the Scrum Masters could still meet on another forum.

This other forum was named Scrum Master Community of Practice. We meet weekly (and if something urgent comes we have an email group and a Flowdock flow) to discuss impediments that go beyond team boundaries. CoP meeting is also an excellent chance to spread good practices. I think this image by Mountain Goat Software gives a clear idea of what I think a CoP is:

Some approaches that have gained popularity through these meetings are Emergency Guy (one person puts down the fire and others can continue working uninterrupted) and more recently a practice that for each story selected for a Sprint every Development Team member writes at least one test. I'm especially fond of this practice, since it has quality assurance built inside.

Leadership is not telling people what they need to do. It's about helping them realize they want to do those things.

Starting the Journey

This blog will paint an image of a small to middle size software company on a journey from chaos to enlightenment. Inspired heavily by the books of Henrik Kniberg. Also, it will be my personal war story as I navigate through the stormy waters of change resistance and try to coach the organization to maximize the added customer value.

Maybe I'll first begin by telling a bit about myself. I have always liked mathematics. And for my whole adult life, I think I have enjoyed challenges. Either physical or mental. Due to my love of mathematics and also in pursuit of challenges, I went to study Engineering Physics and Mathematics. It was great! The guys who tell you that studying is the best time of your life, well... they aren't lying.

After university I started getting paid for solving problems. I did it via programming. My days were filled with adding more features to a legacy product, maintaining the codebase, fixing bugs, etc. I really liked it. But it didn't feel adequate. Something was missing.

During my studies I wasn't really interested in participating student association activities or other networking stuff. I was actually thinking that was more aimed for people studying industrial management and other business stuff. I didn't care about that kind of easy stuff. I was looking for REAL problems. I was young and stupid. (Nowadays not that young anymore.)

Things changed after I started my work career. I have always felt very strongly about people being treated fairly and equally. No-one should be judged by their looks or gender. If they act like idiots, then that's a different case.

Something clicked when Scrum was introduced in company. I was selected as the Scrum Master of my distributed development team. It was awesome! Then at the latest I realised that software problems are not where I get my kicks anymore. It's the people problems. Those are orders of magnitude harder than dealing with (in most cases) predictably computers. But as a Scrum Master I was removing impediments that were slowing my team down. And helping the team to realize how much power there is in a team when everyone is pulling the same rope!

That's how I started my agile journey. Next time I'll tell what happened then.

Take it to the team.