How Epics Flow Through Our Value Chain

If you are familiar with my previous posts, you probably know that I'm a Release Train Engineer. But as I've told, that's not all I do. Nowadays I'm not anymore Product Owner, but instead I try to concentrate more on being an owner for the value chain. So let me next try to describe the flow from idea to implementation.

When new (big) ideas are introduced, there are first a few prerequisites. There must be a business case. When we plan few years ahead, the idea must be profitable. Forecasted amount of revenue must exceed the direct development costs and the future maintenance costs. We also need to analyze roughly the size of the effort and amount of resources needed. Checking the time criticality and whether we have the capacity to squeeze the job through our pipeline in time are essential factors. It's also practical to check if the idea is in line with our strategy in general.

When all necessary groundwork analysis is done, our Portfolio Managemenent Team will make either a Go or No-Go decision. If the idea is approved, it will be added to a product Roadmap and scheduled for development. At this stage the idea is called Roadmap Theme. In SAFe the corresponding term is Epic.

The Roadmap Themes enter development through Release Planning (PI Planning). They are broken down into pieces that can be implemented within our release cycles and formed into JIRA Epics. After that the Scrum teams will further refine the Epics into Stories and tasks. Then they will work on them in an iterative and incremental fashion in Sprints.

Then comes the part that SAFe (to my knowledge) doesn't answer anymore. As in Scrum, there are lots of activities left for the organization to figure out. Also for releasing, there's usually a lot more than creating the software package. Even if you have managed to get your act so well together that you are practicing Continuous Delivery or Deployment (which we are not), you still need to communicate with your customers. People don't like surprises. Even if the changes are improvements, many times people will get pissed if they didn't know about the changes or asked for those.

For me the final touch for releasing are the accompanying activities. Do we have the marketing materials ready? What do we tell the customers? How do we sell them, whats the story? Sometimes we might need to train people. Or the very least we need to let the customers know about what they will get. And we need to distribute the same information internally. Otherwise communicating the new added value might be really difficult.

Product or solution might be only one layer inside a big onion. For some companies it's even relatively tiny compared to all other things. For example Supercell uses over 400 M$ on marketing. I don't think the budget for game development was anywhere near that sum.

In practice (in our setup) all these different activies for an Epic should be lead by Product Manager. S/he isn't the one who should do everything, but make sure they happen. As a Release Train Engineer and Value Chain Owner I try to ensure this happens. It is maybe worth mentioning that through SAFe, the activities related to writing software are rather well formulated and established. The cadence based thinking still needs to be implemented for these other activities.

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

From Forecasting to Cycle Time

I like measuring for the sake of improvement. I believe that measuring something helps to understand its nature. And by measuring you might learn if something is good or bad and going to positive or negative direction.

We have been using so called forecast hit-rate to measure how well the Scrum Teams are able to predict their velocity. It's the result of dividing planned number of Story Points with the actually realized number of Story Points for a Sprint. But in case the number of stories is small, there's easily large deviations when things don't perfectly as planned. And usually things don't go perfectly as planned.

Also this measure can result in some rather nasty dysfunctions. Teams start to favor keeping the forecast instead of trying to maximize the amount of customer value in a Sprint. Or even though some Story becomes obsolete it isn't dropped because that would flaw the statistics. This isn't nice.

We use Atlassian JIRA and JIRA Agile for our Backlogs and Scrum boards. (I guess I should start calling it JIRA Software soon.) It offers a handy Velocity Chart where one can follow these planned vs. completed results. This is essentially the source of our forecast hit-rate information.

But due to all the possible events that affect the Scrum Teams and the #NoEstimates movement that gains momentum also in our company, the data has a really high variance. Even after couple of years it shows no signs of stabilizing. (Of course it can argued that is a systemic dysfunction. As it is. But let's not go there.)

Another tempting alternative for this metric that I've been thinking about is Cycle Time. Average time that a Backlog item takes between the start of work until it is completed. Let's assume that such metric would be easily available and that there would be target on it or that management would follow the number. What kind of behavior would this drive?

My assumption is that it would make the Stories smaller. That teams would strive to get things done faster instead of having mammoth size stories. So In the end there would be a bigger number of smaller Stories and tasks that could be made in shorter time. I would like that. Also it would fit nicely with #NoEstimates.

Since this is still simply hypothetical, I don't have any results yet. But this is an experiment that I'm about to try.

Answers to Open Questions

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

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

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

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

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

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

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

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

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

Did some employees got fired? 

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

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

Were new employees hired? 

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

Was there an increase in number of employees? 

Yes. Same as previous question.

What about stress level, increased or decreased? 

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

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

What about the budgets/costs, controlled? 

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


Did the use of Jira cause problems/difficulties?

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

Using Scrum for Strategy Work

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

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

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

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

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

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

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

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!

(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.

Excellence as a Habit

I'm a big fan of quality. It's not that hard to understand that the user visible quality of the software is a necessity. If the customer is constantly disappointed, (s)he won't be a happy customer. And probably quite soon not a customer at all. But the visible quality is not all. Most of the time it's just the tip of the iceberg.

With software also the internal quality matters. How well your interfaces have been defined, how long/short are your routines and how much coupling there are between modules. If you know what you are doing (and you are the one who wrote that code) you might be able to navigate efficiently in a bit hairier spaghetti. But for the other non-swamp guide developers it can be much harder. Yesterday's code will be tomorrow's legacy. Keep that in mind.

But writing good quality code requires another kind of quality also. Quality in operations. Into some extent I believe this equals having skill and discipline. Again, I'm raising up the need for craftsmanship. For software development with multiple programmers and teams quality in operations includes also commonly agreed coding standards.

I have always found it much easier to define rules than to actually get people to follow those (although I'm usually working more in the implementation side than in the definition). People either forget, they haven't cared in the first place or simply haven't even been informed about the existence of the rules to begin with. So, there's value in both crafting the rules and in making people understand the value of the rules. Many times the rules are enforced by different actors than their creator, which is fine. Different people have different strengths. And finally: there's value in reminding people about the rules.

Systematic built-in quality in operations requires someone to take good care of the big picture. Practicing wishful thinking is not enough, someone also needs to see the evidence that agreed things really happen. Quality systems and audits are a practical way to see if the organization really plays by the rules it has set for itself. Some see them as heavy or bureaucratic, but frankly I think those people usually lack some self-discipline. If you play by the rules then someone watching over isn't hindering your progress. And if the rules suck, please help improve them instead of whining!

And it's also all so natural and fitting for Agile ways of working. Working software should be the sole measure of progress. And for example in Scrum it is shown at the end of the Sprint. Talk and PowerPoints are cheap, demonstrating new functionality rocks!

Instead of sometimes succeeding and most of the time being unpredictable, make excellence a habit. Learn the rules, break the rules, be the rule: Shu-Ha-Ri. And apply the same principle on all levels of the organization. Self-discipline is needed in the Development teams but also in the management. Dare not to expect something from the people working for you that you are not willing to do yourself. If you want people to walk the extra mile, be prepared to walk in the front.

Agile and Military Methods

"What? Dude, your out of your mind! Agile methods emphasize individuals and are cool. Military stuff is all about hierarchy, command and control. Yuck!"

Well, that's one view and I don't really argue about the hierarchy and C&C. But I do find a lot of similarities also. If you need to lead people in battle, the level of trust between you and your team needs to be high. You need to show example and as a leader you go always in first. Would be nice to see the other people following. Your people need to trust you and you need to trust your people. I believe that's a characteristic of efficient Agile teams also. Although in an ideal Agile team everyone is a leader.

And really army and the command and control part is not so black and white. Setting goals instead of giving specific instructions works best in both worlds. In software development requirements change and the only reasonable thing to do is to embrace this change. In his book Management 3.0 Jurgen Appelo summarises agility as

"Staying successful in ever-changing environments." 

In the heat of battle it is probably also safer bet to adapt to the current situation than to follow a predefined plan. US Marines and special forces like Navy SEALs operate with small yet effective teams with no centralized control.

The final example is maybe a bit more far fetched, but maybe just for amusement. If you are familiar with close-order drill, you know that it is a training where certain action is trained repeatedly. After each command the trainer will give feedback about the execution. Now my boldest comparison is between these drills and Sprints/Releases. After Sprint, there is a Review where the results are inspected and the team should get feedback. Improving the actions of the team happens in Retrospective. Iteratively the team improves its execution. Only in this case the whole team acts as the trainer (Scrum Master can catalyze the process).

And finally, practice and discipline are the basic requirements in both. Real professionals keep their heads cool and write those tests before making changes! Regarding discipline, I think the people in software development should take inspiration from the world of military. Lack of discipline in implementation seems to be a common stumbling block for many Agile adoptions. I think the pragmatic programmers and Clean Code movement have understood the significance of practice. Mastery doesn't just appear. It is earned through practice.

Personal Communication and Decision Making

Individuals and interactions. Customer collaboration. I find it really hard to do that without meeting the other person. And if at all possible I prefer meeting them one on one. Or if that is not possible, I usually call using phone or voip. Why? Because it is so much more efficient than writing emails! ..or instant messages or anything else in writing.

I use such tools as JIRA, Lync and Flowdock quite a lot during my days. They are all great for asynchronous communication. And so is this blog post. But getting feedback for anything is a bit too slow to be really agile. Maybe one of the most frustrating features in instant messaging clients is to see that the other person is writing. Then you look at that and wait. If the other person has lot to say, you wait for a long time. But if you go and just have a quick chat it will all be done in no time. Simple and you get to do some nice human interaction also. I count it as a plus!

Well, you cannot always win. Sometimes the face to face conversations may not be pleasant. Sometimes you and the other person just disagree and there might be no getting past it. Or you need to give the other person some feedback that is not so easy to swallow. During those times I suggest just to focus on the facts. Don't get angry or frustrated, just deliver your message. Then you might want to let the other person to cool down before attempting anything mentally challenging. Because frustration simply blocks down our ability to think clearly.

Another interesting topic is the decision making. If I haven't totally misunderstood things, it's actually rather central topic in Agile. Empowering teams gives the teams (and individuals working there) power to make decisions. And thinking about it with some common sense, it does seem wise to do the decisions where the best knowledge is: in the teams. In Scrum the role of the Scrum Master is to remove impediments. A pending decision is an impediment. It's better to make a decision and move on than to waste time in pondering. So, Scrum Master can help facilitate decision making in order to keep team moving.

And I think the same principle applies when going "up in the food chain". Management should provide people with decisions. That's their job. Creating a better working environment through making decisions. Or empowering other people to make those decisions. But that's already a valid decision (and often a very good one.)

Finally I'd like to share this interesting link. Cult of Done. So simple yet so powerful! Starting things is easy. Anyone can do that. But what really counts is getting things Done! Finish starting and start finishing. Have working software as your only metric of progress. Done is the engine of more!

Knitting Processes Together

Interfacing is hard. Even if you take a simple example, (well, maybe not really that simple) a software development team and think about how the information flows from the original customer requirement to an implemented feature. Here I'm assuming that there is one Scrum Team developing one product.

First there is an interface between the customer and the Product Owner. The Product Owner interprets the requirements and maybe writes them down as a User Story in the Backlog. Then the Development Team starts working with the requirements and refine them with the Product Owner's assistance. Finally they implement a new piece of functionality. Something that is hopefully close to what the customer originally wanted.

Probably many have experienced cases where everything didn't go according to the customer's plans. Product or service did not meet the expectations. Fortunately this earlier mentioned development process can be improved by collaborating and working closely with the customer. But still, things tend to get a bit harder when you scale.

Depending on how you (or some others) choose to shape your organization, you might have a set of small start-ups where every team can do pretty much everything. But quite often your operations are modelled by separating different functions and processes. And I don't think it's always bad. I'm not really that into accounting, so I prefer someone else doing that for me. Or even thought I like interacting with customers, I'm perfectly fine with someone else closing the deals and me just providing some cool new functionality.

In addition to the different functional roles, there are processes applied in these functions. And these processes interact. In sales function there's the sales process and in R&D the software development process. One of the most common pitfalls in process oriented companies are the interfaces.

Even if you apply the idea of Continuous Improvement, you are usually just optimizing one process. And even if you have a state-of-the-art software development machinery it makes no difference if you cannot get the products to customers. Or if your sales or marketing cannot find your customers and make them aware of your superb new products.

The approach I have recently been involved with is the so called Value Chains. Instead of concentrating only on the individual processes, you take a helicopter view and think about the whole chain of actions from customer need to customer satisfaction. And then examine closely also the interfaces between the processes.

Of course this approach requires a healthy amount of collaboration between the functions. And maybe someone to pay attention to the whole. Quite often we tend to just stay in our little silos and see everyone outside as, well, outsiders. But get past that! Go to lunch with your buddies at sales or go have a cup of coffee with some people working in customer service. Or if you don't know anyone there yet, go and make some new friends!

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