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.

Strategy, Vision, Story, Culture

First I need to admit that I'm a total newbie in any strategy work. I can openly admit that most of what I have is just scratching the surface and guesswork. But I'm getting increasingly curious about how to craft a strategy.

Even the best strategy isn't worth a penny if people don't know about it. People need to hear about the strategy. They need to be able to discuss it and ask questions. Possibly even help in crafting the strategy. I believe that's not always possible and maybe everyone doesn't even care too much about such things, but it's easier to embrace something you have been involved with early on. (I believe same things apply for leading change also. And well, strategy is about changing the company from one stage to another.) Communication becomes critical when executing the strategy.

I have recently learned that I've confused crafting a strategy and crafting a vision in my mind. I mean, if we start making a new strategy, first we should have a goal. Ambitious and challenging, yet reachable with some stretching. Or even unreachable. I was again happy to watch a video about Spotify. The second part of Spotify culture introduced the Definition of Awesome. I think company Vision should be something similar. What you aim to be in the future, the ultimate goal.

And then Strategy would be 'just' those steps that take us towards that goal. There might be big and scary actions that will need to see the daylight, but more or less this is how I see it. Now I'm facing some doubts. Spotify is emphasizing the importance of culture. Almost all companies have values. The recent presentation by Eric Schmidt from Google seems to point to the direction of culture plus right people and even directly saying that having a strategy is stupid. In today's fast moving world the strategy might be out of date quite soon after it has been crafted. Old truths don't hold anymore.

Experience is less important than skills, enthusiasm and willingness to learn. Months and weeks have turned into seconds and you can be either a dinosaur or a small and agile mammal. Those who don't adapt will become fossils and relics of the past.

But maybe strategy can also be to create an kick-ass culture while pursuing that vision. If you aim to be the best damn player with the most awesome products that customers love, that vision is not going to get out-of-date soon.

Fourth interesting concept related to the same topic is the company Story. I read about this from Ville Tolvanen's blog (who unfortunately blogs in Finnish). I like this approach of having a Story. Stories are easy to remember and they don't need to be precise. Using metaphors is often a powerful way to get the message through. Maybe the trick is to tell a story about a company that had an awesome culture and was chasing a glorious goal...

Software QA and Testing SUMMIT 2014

I participated in a Finnish QA and Testing conference. It was actually my first related to this subject. Never the less, I found the presentations to be really interesting. (The conference would actually last two days, but unfortunately I can't attend the second day.)

IT Quality from the Management point of view - Quality Assurance is much more than testing

The first keynote presentation was given by Reni Waegelein and Karri Kolehmainen from Veikkaus. Veikkaus is a Finnish provider of gambling services. The only one of its kind, they have a monopoly. Maybe the main topic was that the business is moving in ever faster pace. Earlier things happened weekly, like the Finnish lottery (Lotto-arvonta) and the main co-operation partner was post office. Now playing and transactions happen almost every second. There are 300 million gaming events per year.

So is it worth investing in quality (assurance)? It depends. One should always consider what we can achieve with the testing and what we could lose if we don't. What and how big are the risks? According to Waegelein it's not necessary to have the site always accessible. But keeping people's transactions secure is a must.

The perceived quality or the impression of it is more important than the actual level of quality. A lot of it is psychology. People usually remember from their experiences three things: the worst thing, the best thing and the end. Essential part is to find the critical situations where the quality needs to experience good quality. For websites it's usually the arrival and departure from the site.

Usually failures make good stories. They told about a time when after the Keno lottery broadcast was already over, one the official administrators found a ball outside the lottery system. In essence that meant that for customers who had played with that number there had been absolutely no change of winning. So they decided to redo the lottery. But because official results had already been announced they couldn't help but give out the winnings for the past lottery. They took a big financial hit and had to make a lot of manual work, but I think it was indeed the best choice all things considered.

Another thing they wanted to clarify was that testing doesn't produce quality. During their last big release efforts before jumping into more agile way of doing things they spent 25 thousand hours on testing a release! And when they wanted to do things differently some people thought this safety net was taken away.

But to be fast, the focus needs to move to an earlier stage. Quality assurance needs to start already during the development and even before. It needs to be part of every project. When testers are involved already at the planning it more easily means that only the necessary parts are implemented. Usually normal Product Owner would specify the product up to 130% and end up adding even more. With the testers are involved in this it's easier to stay focused.

They don't have people separately responsible for test automation. Everyone knows how it works and everyone is responsible for it. The cases are written in Gherkin which is easy to understand even for non-coders.

The Agile Project Model of Veikkaus is a combination of different methodologies. It combines selected practices Lean, Agile, Scrum, Kanban and XP. They were also aware of the Scaled Agile practices and familiar with the things happening at Spotify. Many of the things sounded really familiar. We have been studying and experimenting the same practices.

After the presentation there was a round table around the vision and future trends of testing and QA. One comment was that QA seems to nowadays be almost a synonym for all the other software development activities except testing. People had also noted that in some places people have widened their job descriptions. They aren't anymore test engineers or development engineers but just engineers. Reminds me of Scrum and everyone in the team being a Developer. The importance of (test) automation is increasing.

After a coffee break there were a couple of short presentations by tool providers. I'm not going to advertise those here, except I want to share a couple of cool pictures. Ulf Thornander talked about the tightening pace in development. We are moving from Continuous Integration to Continuous Operations. But I think this is a bit hard to reach for certain types of business, but anyway a good Roadmap for the future.

James Fenton talked about how we should integrate testing into Continuous Delivery. There were a couple of good slides, but I personally liked the one about moving testing to the left best. It's so much cheaper and productive to find the defects when the product hasn't reached production. A no-brainer, but still somewhat hard to do in real life.

How to get Quality Assurance included from the beginning of the Project?

Maija Sanisalo from UPM concentrated on the human part of QA. She told that a good QA person is visible. That's how (s)he gets involved and hears things. Having people with great skills isn't enough. They will need to be able to work together. And the quality assurance needs to be part of people's daily work. As an amusing side note she mentioned how it's important to decide that 'today is going to be a great day' and start your day with a Peter Pan or a Winner pose. It will affect your mood and consequently your whole day. (People might also think you are crazy, but you shouldn't care about such petty details.)

 

CASE Nokia: HERE Maps for Windows story: How to adopt changes without scarifying quality

The last presentation I had time to enjoy was held by Tatiana Smekhnova from Nokia, Germany. She's the QA Lead of the HERE maps. According to what I heard, Nokia has done some remarkable improvements on the empowerment of people. Or maybe HERE Maps is just so small unit that things are easier to change there.

The quality of the application is the responsibility of everyone. Processed should help in this. They had a challenge with regression testing. It could have taken five days to complete. But when you create software in short sprints, five days is way too long. So they set a challenge to shorten the time to one day.

They seem to really live according to agile values. Team makes decisions together, they review their Definition of Done regularly and they have working Retrospectives. One particular example of team making decisions about their own ways of working was that they decided that meetings should take a maximum of one hour. From the principles Tatiana showed in her slides I found also lot in common with the Management 3.0 principles. Face to face meetings, setting goals together, improving everything. I guess many people have read the same books. Maybe they are indeed good books. At least I personally believe so.

All in all as a conclusion Software QA and Testing SUMMIT was a good investment of my time. In addition I had opportunity to speak with interesting people and find out new things. Actually this left me hungry for next year. :)

My Bookshelf

Since I stopped doing value adding work (writing code) and started being an administrative expense (management & process stuff), I have read many work related books. I try to balance between reading fiction and other lighter material and then management books. Originally I was rather strict that reading books that benefit the company should happen during the company time, but I've a bit softened my view on this. It sounds like a cliché, but reading and learning new things is really an investment. So, since I also like reading that stuff, I've given myself permission to read interesting books also during my leisure time. :)

Now I'm dropping the bomb: every management or process book ever written isn't a pearl! That's right. Actually, many really, really aren't worth a read. That's why I'd like to save everyone's time and just list the ones that have somehow made an impression on me.

I start from the one that has maybe made the biggest impact on my thinking: Coaching Agile Teams by Lyssa Adkins. I read this when I had just started as the Chief Scrum Master. I'm still on the voyage, but this book actually started the journey. Well written and worth reading if you want to help teams as an Agile coach.

The second one in the series of really good books that offer something new and neat is Lean Startup by Eric Ries. It doesn't go into the category of coaching, but has given me a lot of nice ideas regarding product development. I think it should be a must read for any Product Owner and could be really thought provoking for any Agile Developer. Some great catches from the book: Minimum Viable Product, experimenting, pivoting and actionable metrics. Just read it! <3

Third one in the series I actually read when again starting in a new role. This one is for Agile managers and is called Management 3.0. It's written by Jurgen Appelo and belongs to the same Mike Cohn signature series as Coaching Agile Teams. (This is not a paid commercial, but I just say that that series has a lot of good books.)

I'm not sure if the ideas are really original, one might even say that they are copied and just put under one cover, but it doesn't matter. Like Scrum combines many useful practices under one easy name and is easy to get a buy-in for, Management 3.0 groups a set of management practices. It's easy and fun to read and I think quite many managers (people who are responsible for the well being of others) should read this book. In most cases people are working in a company voluntarily. They are free to vote with their feet. Especially skillful, talented people. As a manager you should realize this and create an environment where these people enjoy working.

For the rest of the books I won't give such a lengthy description. These are a couple of easy to read books about change management:

• Who Moved My Cheese?
• Our Iceberg is Melting

Then these didn't make it into the top three, but I'm still a big fan of Henrik Kniberg's work:

• Lean from the Trenches: Managing Large-Scale Projects with Kanban
  
• Kanban and Scrum - making the most of both
  
• Scrum and XP from the Trenches
• Lean Mindset: Ask the Right Questions (co-authoring with the Poppendiecks)

This book by Daniel Pink is an excellent introduction to intrinsic motivation:

• Drive

All of the above a books that I could recommend people to read. Of course you should consider what fits your personal needs. 

Finally, a couple of books that I've read, but maybe wouldn't promote that much. If you are the author of these books, I'm sorry. But maybe you can take this as an improvement opportunity. ;)

• Lessons in IT Transformation
• Virtual Team Success: A Practical Guide for Working and Leading from a Distance
• Agile Software Development with Scrum (sorry Ken..)
• Agile Project Management with Scrum (..and once more)

And truthfully, many of these books aren't really in my personal library. But we have them at work and some I've borrowed from the local library. In addition to books you can find plenty of interesting (and free) material online. Blogs and videos are also good ways to stay up to date.

Edit (12/2015): Since the original time I wrote this post I've read a couple of really interesting books. Thinking Fast and Slow by Daniel Kahneman and Rocket Surgery Made Easy by Steven Krug. Both are excellent if you want to understand human behavior better.

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

(Release) Version Control

During my holiday I noticed that Scaled Agile Framework had been updated to version 3.0. I did watch the short update video by Lean Samurai (which was nice and compact), but I haven't really had time to get familiar with most of the contents yet. Some positive first observations include dropping Hardening out of the HIP-sprint (nowadays only Innovation-Planning) and making an attempt to include also strategy into the big picture. Although I like IP more than HIP, I don't really like dropping the shippability from the PSI. I'm glad that separation between development and releasing is still there. Maybe I will learn to like Program Increments.

But the topic I was about to write today is Continuous Integration. It has now been lifted to the big picture to get the attention I think it really deserves. Scrum doesn't offer engineering practices (XP does), so companies should amend their processes with some additional common agreements. Let me now write down some clichés that have some valid points behind them:

• You can't scale crap.
• You can't go fast if you carry a lot of extra.
• Integrate often.

Well, one could consider these also as plain facts. But the first two are more or less related to good coding practices and craftsmanship and staying Lean. Also keeping the technical debt as low as possible helps going faster. The last bullet is related to version control and software production.

We are applying the stable mainline pattern. To get a more thorough explanation on this please check here or here (again I find good stuff and it has Mr. Kniberg's name written on it. That guy is a wizard!) We use a rather well integrated set of Atlassian tools. Atlassian Stash as the basis of our repository management accompanied with Atlassian Bamboo crunching the builds. And they both communicate nicely with JIRA. (While looking for some nice pictures, I bumped into this video about making a demo integration. Maybe worth watching.)

When the code changes are checked in, the builds start automatically. They include running the automated tests (unit and integration), followed by more wider range system level tests if everything went well. Good changes are blessed with a nice green color, but any breaking changes result in an ugly red color.

In Bamboo you can configure the plans to make builds for all new branches automatically. This makes the creation of release branches handy (compared to some other CI frameworks where you need to configure a new build for each new branch.)

Finally, the big dilemma when we make releases. We branch the release from the trunk. This is communicated well in advance to all the teams and developers. But after we make the branching, we don't allow any more changes to the code. Stash offers a handy way to do it from the branch permissions. To be more precise, we do allow changes, but they need to be made via pull-requests and approved by the System Team.

My dilemma here is that I'd like to believe in people. I believe most of the restrictions usually hinder development. But then again, I believe many people are aware of the term feature creep. It's easier to fight it if you don't have a way to make changes. And the obligatory pull-requests have a built-in code review which usually helps improve the general code quality.