Continuous reviews

Lately, I have been thinking a lot about how to increase the value of reviews, with the goal of making reviews great again. 

In a well-functioning team, I regard peer reviews of code and designs as key in making sure that the team’s deliveries are of high quality. Code reviews are also great for spreading knowledge within the team. This learning process goes two ways: the reviewer gives valuable feedback to the reviewee, thereby growing her into a better coder or designer. And the reviewee gives the reviewer new knowledge, through sharing her code. (Yes, reviewee is an actual word!) Therefore we might get just as much value from a junior programmer reviewing the code of a senior developer, as from the senior-reviewing-junior setup.

Hence, reviews are both a stamp of quality approval and an instrument of learning. Reviews grow both quality and people!

However, many teams have come to see The review as just a required step in the development process, a tollgate which has to be passed through before testing is begun. To me, this feels too much as waterfall. With such a mindset, the code review process may easily degenerate. Teams will hurry through reviews with the mindset of getting them done as fast as possible. Ultimately, the review may become a ceremony that adds no value. What started out as a way of ensuring code quality might end up as a cargo cult.

Instead of regarding The review as part of the development process, regard it as part of the coding process. When you are working with a user story, do not wait to send out review requests until you are ”done”. Instead, get your code reviewed continuously. If you continuously send the reviewer digestable chunks of code to review instead of insisting on reviewal of huge piles of code, she will have a much better chance of making a high-quality review.

One could of course argue that this type of code review is borderline pair programming, and that we should instead experiment with replacing our reviews with pair programming, if we find that the review process has failed. And that may be true. But still, for a distributed team where pair programming is hard or impossible, I believe continuous reviews can be a great tool, with the potential to maximize both delivered customer value and learning.

If do you go for continuous reviews and have a Sprint/Kanban board with a review column, I strongly advise that you remove this column. Remember, the review is not a step in the development process anymore. Instead, it is something that is done continuously as part of the coding.

Happy continuous reviewing!

Mr Data is our new boss

In my May post, I wrote about product management by dictate and the feature factory that this non-agile way of working results in. My conclusion was that in order to shut down the feature factory, we need to build a value-driven organization. Instead of believing that customer value is created by product management pushing features to the customers through the development organization, the role of product management shall be to define which effect all the hard work shall actually result in.

A number of things must have been put into place before transforming from the old feature factory into the brave new world of value-driven development:

• The organization must have articulated a clear and complete vision. Otherwise it will not be possible to break down the vision into clear missions and measurable goals, which is a prerequisite for the transformation. 
• It must be possible to deliver customer value continuously, at least once a sprint. And it must be easy to measure the impact of a delivery. Otherwise, the feedback loop from the customers will be severed.
• The organization must have a culture where it is safe to fail. The journey to becoming truly value-driven will mean a lot of experiments. Some of these experiments will fail, but failure is actually learning in disguise, as I wrote in a previous blog post. 

Classically, the four basic management skills are defined as to plan, organize, direct and control. I believe this is still valid, but with a twist: In management's new role, "directing" boils down to setting an organizational vision, together with team missions and effect goals. The "planning" and "organizing" parts of classic management are carried out by the teams. The "controlling" part is implemented through the build-measure-learn loop. This loop also continuously tweaks the "directing".

Therefore, in a value-driven organization, the team's bosses will be the mission and the data.

Since management will no longer need to plan, organize, direct or control the value-creation work, they will be able to grow into servant leaders - people with great skills in listening, empathy, healing, awareness, persuasion, conceptualization, foresight, stewardship, commitment to the growth of others, and building community - based on the works of Robert K Greenleaf. This type of management will take the organization to a whole new level of success.

After the fall of the feature factory, gone will be the days when a product manager could push a big project through the organization and celebrate it as a huge success, even though it actually did not result in a huge increase in real customer value. Gone will also be the days of the old-style manager.

In a value-driven organization, we make sure that both people and product reach their fullest potential. Now that is something worth celebrating!

Solving the Feature factory dilemma

I had an epiphany on The feature factory and its root causes a few days ago, so I really need to write this blog post. I have been extremely busy through all of April and May with a huge project that has eaten most of my productive time-off hours, but this epiphany of mine fitted perfectly in the urgent swimlane of my internal Kanban board.

In short, the feature factory dilemma hits an organization when the development process has shifted to agile, but the product organization is still stuck in a command-and-control way of working. Such an organization's optimization goal is throughput. Throughput of "stuff" decided on and prioritized by product management. This stuff is, given that we have an agile development process, pulled from the product backlog, developed in the teams, and the pushed out to the customers. For better or worse.

Product management cannot see that there is a problem with this setup - everyone is busy processing their backlog! So what is actually the problem?

And this is where this week's epiphany comes in:

Customer value is not something that you push unto your customers. Customer value is something that the customers pull from you!

The customers use the organization's feedback loops to pull value from the organization. But in a feature factory, these feedbacks loops are of secondary importance, if at all implemented.

If the product backlog is dictated solely by product management, we will probably end up creating vast amounts of waste since we don't take into consideration what the customers really want.

What we want to do is to replace this throughput-driven feature factory with value-driven product development!

The solution to the feature factory dilemma is to make the product organization agile! Implement feedback loops so you can see more clearly what the customers really think of your product. Instead of having the PO dictate what the development team shall work on, identify applicable value streams/domains and form Product teams within these that take full E2E responsibility for delivering real value to the customers.

Another great thing with product teams is that we once and for all tear down the walls between the development and product organizations. We need the product and development compentences to be on the same team, not in separate silos!

- "We need to be more efficient!"

Imagine that you are told by your boss one day that your teams need to become ”more efficient”. ”Oh, interesting!” you answer. And then you ask: ”So what do you mean by more efficient?”

Now it gets interesting, because chances are that your boss will respond with ”More efficient means that we deliver more stuff, of course!”. Then you go on asking ”Deliver more things, you mean by focusing on flow and reducing cycle time?” - ”No”, your boss answers, ”I meant that we need to be making more stuff, so we need to make sure nobody is idling!”

And this is where you get the urge to exclaim ”Ah, so management decided at their last meeting that the organization’s optimization goal shall be busy-ness?!”

So many managers are overly focused on resource allocation. They want to make sure that everyone is working as much as they possibly can and that idle time is kept to a minimum. Instead, what managers should focus on is value flow. It’s like in a game of soccer; Watch the ball, not the players! In soccer you optimize for the flow of the ball, in order to make goals (= create value), You don’t optimize for the individual players. (If you did, everyone would behave like Zlatan, and the game would be immediately lost.) Optimizing for the individual players is a local optimization. Optimizing for resource allocation of your team is also a local optimization. Lean teaches us to Optimize the whole. In an analogy with soccer, we need to optimize for the delivery of value. One great way to do this is by limiting your work in progress and implementing continuous delivery. Delivering continuously will make sure that you get a continuous feedback loop that tells you if what you have delivered is actually of value. Delivering continuously will make sure less time is spent on non-value adding activities, which is waste. Limiting your work in progress (WIP) will make delivering continuously much easier. Limiting your WIP will also lower your lead time - that is the implication Little's law. So WIP is key in transitioning from optimizing for busy-ness to optimizing for delivering value!

There are other possible optimization goals, one of which is to optimize for agility - to be able to ”turn on a dime” and constantly adapt to the market's demands. I plan on returning to this and how optimizing for agility might differ from optimizing for delivering value.

An organization can also be optimized for secrecy. I think that may be the case for the CIA.

So as an organization, it is absolutely crucial that you know your optimization goal. Without that knowledge, how will you know how to organize? And if you can't organize optimally, how could you ever win?

The eighth waste: Wishful thinking

- "Bend it in!"

These words were repeated again and again by the commercial director at a somewhat chaotic meeting in the organization I was working with. We were under heavy pressure from our competitors, and we needed new features. Fast. So we would somehow bend them into the existing product.

Of course those features were never actually bent in. Thinking that it would be possible to just bend something that complex into an existing product without any trace of a holistic approach was just plain wishful thinking.

But this experience ten years ago wasn’t complete waste, because it opened up my eyes to what I now call the 8th waste: Wishful thinking. 

In Lean software development, we talk of the seven wastes - Partially done work, Extra features, Relearning, Handoffs, Delays, Task switching and Defects. (These were defined by Mary and Tom Poppendieck and are based on the classic seven wastes in the Toyota Production System.) 

To this list I would like to add Wishful thinking.

Wishful thinking makes you underestimate the challenges ahead. Wishful thinking makes you commit to plans which are impossible to follow. Wishful thinking makes you leave your desk much too late to get to that meeting room in time. 

Wishful thinking is a soothing feeling that replaces logical thinking.

It is wishful thinking that makes the team overcommit sprint after sprint. It is wishful thinking that sets release plans that can never be met.

Wishful thinking can even make you want to bend in onboard entertainment into a communications platform.

Of course, wishful thinking could be seen as the root cause of other types of waste, such as Extra features. But I believe wishful thinking is such a huge source of waste that it is a waste in its own right. A waste that we should try to eliminate!

Unfortunately, eliminating wishful thinking is harder than one would expect. Wishful thinking seems to be part of our culture and part of our beings.  But the next time you hear a colleague suggesting that you could just bend something into your product, please ask her if that is not wishful thinking. I will!

How big is a team?

When I first started out with scrum in the mid noughties, the Scrum guide’s recommended team size was five to nine people. Since then, this has been changed into three to nine. Now, there is a huge difference between a team of three and a team of nine. So when should you be three and when should you be nine? Maybe it’s better to play safe and always stick to eight?!

Well, that depends!

The more people on the team, the harder it gets to maintain a single focus. A big team may easily become fragmented; suddenly you spend half of the fifteen minutes of daily scrum zoning out from the meeting, since you’re totally disconnected from what five people in the team are doing. Because you’re in a sub team that is doing something completely different!

Setting a crisp sprint goal for a team of nine is very hard. Usually, you end up with three goals at every sprint planning, which means that the team won’t have a clear guiding north star for the next sprint. 

So obviously, big is not always better.

I firmly believe that team size should reflect the number of people that need to work together in order to focus on one major initiative at a time. If your organization deals with a lot of complex and big initiatives, a bigger team size probably does makes sense. This may also be true if your deliverables are huge legacy applications. However, if the majority of your initiatives are quite small, it makes sense to have smaller teams. Especially so if you have begun transitioning to a micro-service architecture.

But if some initiatives are tiny and others huge beyond comprehension? Does this mean that team size will have to vary over time? And wouldn't that mean that we will be stuck in some sort of perpetual "Tuckman loop" jumping between group development stages every time someone is added to or removed from the team.  (N B: By ”Tuckman loop” I mean constantly transitioning between the Tuckman stages of group development.)

My bold proposal is to have your cake and eat it too! Build teams big enough to solve your smaller initiatives. Make sure that the team members work well together and complement each other professionally. Let's assume you do this in your organization and that you then end up with six four-people teams. That covers small initiatives. For big initiatives, build together eight-people teams from the four-people ”atom” teams. You will end up with teams where you know that the majority of team members work well together. This is a big difference from the old-fashioned way of forming project teams from a pool of people (or even worse: resources), where you will never know what to expect!

I am not saying this is a silver bullet, but the joint-team setup has been successfully used for one of my teams over the past two sprints. "My" three-person team is teaming up with a team of roughly equal size in another location for a limited time. With great result! I have also seen other successful examples of the joint-team setup, so it's not a one-hit wonder. 

When putting together two teams in this fashion, my observation has been that they function much like two sub teams do in a larger team. The two micro teams do the sprint planning and sprint review together. Daily scrum and retrospectives can be done separately or jointly, depending on what is best - in the initiative I mentioned above, we have kept having our separate standups and added a full-team standup on top of that, two times a week.

We call this setup Micro teams. Most people who have worked in this kind of micro team love it and don't want to go back ever again to big teams. They love the short, relevant standups. They love the feeling of all team members working on the same thing. And they love the focus.

This is the kind of team that can deliver fantastic value!