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

Software Development - More Than Coding

Think about software development. I'm assuming you have an image of someone writing code in your mind. Well software development is that, also. But it's also much, much more.

In my company I'm responsible for the software development in this more broader sense. When I think about software development, everything begins from the customers. Developing software is solving customers' problems. Selecting what problems to tackle as a company is a strategic choice. Strategy narrows down what you develop and helps the company focus. Probably it also states in which markets you want to compete in.

Strategy helps the company define it's portfolio. What customer problems we want to solve and what kind of solutions we offer? The solutions can be products or services. Strategy should guide you in this. If it doesn't, refine the strategy.

Let's now assume that in your offering/portfolio you have product(s). Each product should have a vision. What the product will be in the future? What customer problems will it solve when it will be in it's ultimate, final form. (This form will never see the daylight. Vision serves as a distant goal, something to strive for. It's an idealisation that will be even more magnificent when you get closer.)

Vision will help you define a roadmap. Where as vision can be hazy, the roadmap should be really concrete and tangible. I think of roadmap as a guidebook for the next steps toward the vision. If your strategy is planned for the next 5-10 years, roadmap could cover maybe 3 years. It's worth noting that it's still a high level plan and as for any agile plan, subject to changes.

In software development roadmap is implemented in releases of new software versions. They are usually developed in iterative and incremental fashion. Old functionality is modified and improved with new features and bugs and defects are fixed. Many times companies try to shorten their release cycle. The ultimate case would be Continuous Deployment where every change would be deployed to customers. But this is very much industry specific. In some cases the overhead of taking new software version into use is so big that customers don't want to do that often. Then it's practical to select a release cycle that suits both the company and the customers.

In agile development, software is usually created by small teams in an iterative fashion. The length of these iterations or sprints is usually limited to less than a month, a little bit depending on the selected methodology. Sprints are like mini-projects; they are planned, executed and in the end there are sessions for examining the results and for learning from the experience. ...and then cycle starts over again.

Daily work in sprints is carried out by the development team. Developers are experts in their field and select the most fitting methods for the implementation. They have the authority for carrying out daily decisions.

We got to the part where the coder writes source code. But as there are many layers in onion, there are many layers in software development. Writing the code is just one of them. Never the less, it's an important craft if the software is to be of any use and even more so if it is to be maintained.

Slack & Blink

I read Tom DeMarco's Slack and it made me question my own role as a process owner. The whole book seems to be somewhat manifesto against the sort of 'efficiency' that targets keeping everyone busy and also for management by objectives. The second one has been criticized ever since W. Edgar Deming, who I most relate with systems thinking.

In the end, Slack isn't against efficiency. At least that's my interpretation. It tries to make a separation between making individual parts (seem) efficient (busy) versus making the overall system efficient. I guess the lean approach would anyway consist of having enough slack to keep the flow smooth.

Another topic Slack points out is the culture of fear and how it can effectively prevent organizational learning. In a culture of fear organization you can not take time to learn new things. You always need to be efficient and busy. Inevitably this will keep people in their comfort zones because taking the time to try new things is just too risky. To transform such organization into a learning one you would first need to make people feel safe, cut off internal competition (between units or other silos) and give people enough slack for deliberate slower-than-expert training.

Slack got me thinking about process development. Just to keep in mind that busyness and effective value delivery are two very separate things. I sure hope it stays clear to me. Reminder from time to time doesn't hurt.


After Slack I started reading Malcolm Gladwell's Blink - The Power of Thinking without Thinking. It concentrates on our first impressions and thinking that we do unconsciously. I think it's very much related to Thinking Fast and Slow by Daniel Kahneman. (Now I realize that Gladwell wrote Blink six years before the other book. I just read them in reverse chronological order.) I analyzed Kahneman's book in my previous blog posts (here, here and here). Blink also supports the idea that we operate a big part of our day on an autopilot. Many of our choices are just too import to be left for our overanalyzing conscieousness. Instead they are made more efficiently, unconsciously.

Interestingly, we cannot tell how we end up with our unconscious choices. They happen 'behind closed door'. There are many studies that indicate that we don't have a clue. We can say we like this brand more than that, but usually the reasons are not known to us. And the setup of the experiment also matters. In short sipping test Pepsi usually wins Coke. But when you drink a whole bottle at home, you might change your selection. Or artist that you don't necessarily like after hearing a short sample might still be a huge success live.

Both books have been really enjoyable and worth reading. I can easily recommend both of them.

Developing Metrics for Development

Last month I wrote about my intention to try Cycle Time as a metric for software development. Back then it was still hypothetical, now it's real. Maybe it's still a bit early to draw any final conclusions, but it's already evident that I failed miserably in communicating the reasoning behind the change. And the criticism is well deserved.

I selected the average Cycle Time during past month as the metric for each team. In a way it is a good metric and gives indication about how quickly the value was realized after the work on a backlog item was started. But all backlog items aren't equal and also work type and intensity differ during the release cycle. In the beginning of the release cycle teams mostly work on the new development. Nearing the end the period emphasis is shifted more towards testing and bug fixing. Issue life cycle tends to be much shorter with bugs than when creating new functionality.

It is also questionable if one monthly average number can help in decision making, in essence serve as an actionable metric. You can see the trends in longer time intervals, not much more than that. Another angle is that a team can be really mature and produce outstanding results even though they don't split their Stories into very small parts. Their average deviation can be small and thus predictability high.

Then again I feel that the metric got a little unfair criticism when it was compared with Lead Time. In the end the company is interested in how the customers experience our products and services (Customer Experience = CX). But this includes many topics that are out of scope for software development. Like the company brand(s), how salesmen conduct their business and how the customers are served by the customer service. I think the software development part of the system (company) can greatly affect the User Experience (UX).

 

I would love to get the big picture correct. So personally I feel that the CX is more important than UX alone and Lead Time more important than Cycle Time. But in both cases the internal part is relevant component of the whole and deserves a metric of it's own. (It would be so cool if I could somehow bundle measuring UX and Cycle Time somehow... Probably there's no such easy connection. I think relationship between Lead Time and Customer Experience is much easier to show.)

Now the current bleeding edge is to try using the whole information provided by the JIRA Control Chart instead of simply one number. I haven't yet figured any cons, but on the pro side you get trend lines of where the performance is developing and standard deviations. Of course you can still identify the release cycle from this data, but you can draw other conclusions too. Increases in rolling average or standard deviation can signal trouble. And when the figures are followed regularly, the team can be aided in a timely fashion.

 

Currently I feel like I'm making too rushed decisions. I'd like to involve other people more and ask for their input already before I make an experiment. Now I mostly just measure the impact and make amendments, but I'd like to concentrate on this more. Let's see if the Santa Claus and New Year will bring a difference. In case this will be my last blog post this year, I already wish you all Merry Christmas and Happy New Year!

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!

Complexity of Multiple Development Locations

There are multiple reasons why companies spread research and development activities into multiple countries. In some smaller countries it might even be that the job market is not big enough to cover all the needs or that at least talent is really hard to find. That's why it is many times natural to spread activities to locations where the talent pools are bigger. Also the salary level can be a tempting factor especially in cost competitive countries, like India.

But there are certain challenges that are good to keep in mind before taking the step. I have no hidden agendas, my intention is to simply state some things that you might want to consider before starting activities in a new location.

Time-zone differences are good to take into account. Of course they can even be a positive thing if you are looking for 24/7 response times in services and you need to follow the sun. But if you are attempting to have distributed teams (members in more than one time-zone), they will have a limited number of common hours. There are some 'sharing the pain' approaches to this, but none the less it's a real challenge.

I think that if at all possible, people who work together should meet face to face at least in the beginning of their common journey. That helps to build trust and makes the team work easier. It's also easier to explain things and build understanding while being physically close. While this is nice, it will of course create some expenses when people need to travel. Again by far no show stopper but something to consider.

Having multiple development sites has an effect on the communication also. With one site you can rely mostly on physical boards and getting people together, but with multiple sites you need to have proper technology. Things like online backlog tools and communication software become a must. And I think many will find chat tools like Flowdock or Slack beneficial. Internet connection speed will also prove to be important. This depends also on your products, but if you need to transfer gigabytes of data there's a big performance penalty if moving files takes hours rather than minutes or seconds. Thus the local infrastructure also plays a large role.

Job rotation pace also varies between countries. Somewhere it might be possible to stay with one employer for the whole career (maybe not realistic nowadays anymore) whilst in some countries people tend to switch jobs every couple of years. If employee turnaround is really rapid, tens of percents annually, building silent knowledge might be difficult. I mean such information that slowly accumulates while you learn more and more about your field. I think rapid job rotation is also where bad for good team spirit. It's not easy to build trust between people who often change.

Cultural differences should be also taken into account. Countries differ in many things. For example Finland, USA and India are really different. To better understand one another it is good to study a bit what kind of things are valued in the other culture. One nice site to check the differences between nations is here. There you can check how the six pre-selected factors differ. It might explain why your colleagues behave as they do.

Inflation rates are also really different between nations. For example in Finland the tech salaries are high, but there's hardly any inflation. In India it's vice versa. Salaries are in general smaller, but they are raised in bigger chunks and more often. And one of my guidelines is that in the global economy talent is cheap nowhere.

Final thing that comes to my mind is the local laws and amount of bureaucracy. I guess many times the amount of bureaucracy can be bundled with the amount of hierarchy, but that's just my assumption. (What I mean is that if you always need to get bosses bosses boss's signature, you are probably in a hierarchical and bureaucratic setup.) Having a local representative who knows the culture while starting activities up is probably priceless.

Well that was my not so short list of things to consider. Topics are not in any specific or prioritized order. But hopefully they will be useful for people who are pondering about spreading activities to new locations. Make sure you understand the challenges. Some are just risks that may or may not realize, but some of these you will encounter for sure. But if your plan is clear and you are doing it for the right reasons, you have a good change to succeed.

By the way, if you are academically interested in the topic, you might want to check out DD-SCALE project.

SLUSH 2015

If you are not familiar with SLUSH, it's a sort of a startup event. Or I guess at least originally the idea was to gather together startups and investors. And it's still a lot about that, but it has expanded into something huge. Not only startups are interested in being there, but also many established not-anymore-startups like NOKIA, Samsung, GE or F-Secure. Also the set of speakers includes people like former president and Nobel price winner Martti Ahtisaari, president of Estonia and prince of Sweden.

The size of the ~2 day event was around 15k attendees. I included the approximation sign, because two days is far from the whole truth. During, before and after SLUSH the Helsinki region is filled with all sorts of side-events. So it's actually a really great situation to have a product launch. I think at least Comptel, Nokia and F-Secure took advantage of the situation.

I participated in SLUSH as a representative of my company. We were not looking to sell the company, nor to acquire any others. But we are included in the Merit Project along with other Finnish maritime companies. So we had an own stand alongside Eniram, Arctech, Ixonos, Aeromon and others. Honestly there weren't many potential customers, but the emphasis was in trying to suck the most out of the inspiring atmosphere. :)

In the beginning everything was rather shocking. Dim lights and huge laser beams crossing the ceiling. So many companies represented that one got disoriented almost right after stepping in. And due to the fact that I represented my company at the stand and because the event all in all was huge, I didn't watch many of the presentations. But I can recapture some that were most memorable to me.

Risto Siilasmaa told about NGP, Nokia Growth Partners. It's a 700M$ venture capital. Now I have to admit that I'm not that familiar with venture capital companies, but my impression was that they most give 'just money'. Interesting in this NGP concept was that in addition to the investment they also offer a lot of their own contacts, experience and wisdom to the startups. That might be a huge advantage compared to 'just money'.

Then I watched Dyan Finkhousen from GE talk about Open Innovation. I think it was Lean Startup where I read about GE's approach to having separate units that are fully autonomous. They can operate in the new environments without the inertia of the big company. But on the other hand they can also benefit from the 'big shoulders'. I think that's really interesting. There are other similar examples about these sort of intrapreneurs. From Finnish companies Reaktor Ventures is operating similarly.

Ilkka Paananen told that the bar of success has raised significantly during the last five years. Before Angry Birds it was huge to get million downloads. Now with hundreds of millions or billions of downloads it's hardly worth mentioning. He also got big applause for saying that he believes the next Google could come from Finland.

I'm not sure if that is likely, but the atmosphere of SLUSH was such that anything could be expected to happen. I guess many startups could find their investors from the event, but for me it was a source of great inspiration. You are allowed to think big, currently there's venture capital for good ideas and there are no limits. Digitalization is regardless going to happen and it's going to change everything.

(In addition to following the official program I did get some low-quality selfies with various people I admire. One I missed... Daniel, the Prince of Sweden, maybe next time. :) )