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!

Why are companies hierarchical?

I just had the pleasure of writing a "primer" on how it came to be that most companies have an hierarchic organizational design, and why this is bad. And I also realized why command-and-control companies match so well with the infamous Waterfall project process. So I thought I would share the text here too!

Before the industrial revolution, knowledge on how to build for example a wheelbarrow or a carriage was passed on from generation to generation within families or guilds. This knowledge existed in the craftsmen’s brains and was not documented. Standardization, for example for tools and screws, was non-existent.

However, as a consequence of the industrial revolution, this started to change in the 18th century. In order to be able to mass produce carriages, for example, the knowledge on how to build the carriage had to be documented, so that new workers could learn fast. Standardization of tools etc also became a requirement - imagine the chaos that would come if one attempted to mass produce wheelbarrows without standardized screws!

As the industrial revolution continued, craftsmen were replaced by workers. Where craftsmen saw “the big picture”, workers only saw a small sub part of the entire manufacturing process. “The big picture” was only seen by management. Management became the brain and workers the hands of the industrial revolution.

Hierarchies were built. Work was divided into detailed sequences, which were documented and taught to new workers. This type of organizational structure is called “command and control”; top management has full command and full control over what the workers do. Hence, a manager’s top priority became to control his workers.

The command and control setup might have worked in the Ford factories of the 1920s. However, in a modern world the many problems with an hierarchical organization becomes apparent.

People are often organized in functions and only know of that function. An example of this in the software development context is that in this type of organizational design, requirement people, developers, testers and operations people sit in different departments. Organizing people in this way means that handover of information has to be done between the functions, otherwise it will be impossible for the organization to work together. Very often this type information handover has to flow up and down in the hierarchies. That tends to become very slow and inefficient. Hence, the information flow between these departments becomes sub optimal. As a result, developers may spend weeks developing something that was just a misunderstanding between the requirement people and the developers. In turn, the developers may continue for weeks writing sub-standard code that won’t test correctly, just because they don’t sit next to the testers. And even if the code does test correctly, it might not be possible to install in the production environment, since the operations people never discussed the new operation system with the developers.

Another problem with people sitting in functions is that only top management has “the big picture”. But only in theory, since we just stated that the hierarchical information flow is often slow and inefficient. Which means that not even top management has “the big picture”.  Therefore, one might argue that the people in the top don’t have the best knowledge within the organization, but the worst. Still, it is these people that make all the important decisions!

Because of slow and inefficient information flow, it may take really long for a company to correct its course. Let’s say nobody buys the company’s most important product since a competitor just entered the market with a much better and cheaper solution. If information flows slowly it may take months before management acts on this. And then it might be too late!

Essentially, the classic command-and-control organization is an organization where all work has been broken down and sequentially defined. It is an organization without any working feedback loop. The way software development projects are run within this type of command-and-control organization is very similar to the actual organization. Projects in an company where work items are broken down in advance and sequentially defined must of course be… just that. A project in this type of organization therefore normally attempts to follow the Waterfall process.In a waterfall process, a project starts with creating all the requirements. When these have been signed off, the project moves to the next phase: design. In this phase, it is decided exactly how the system shall be built. Huge amounts of documentation is created. When this design documentation has been signed off, it’s time for the actual development, which should - in theory - be very simple since all the design has already been made. And when the development has been completed and signed off, it’s time to test the software. And if it actually tests ok - and why shouldn’t it, as long as the design has been followed :-) - it’s time to sign off the test phase and deploy the product in production.

And of course, this usually fails. Quite often it fails miserably. It fails because you cannot write good requirements without having any real feel for the actual end result. You cannot create a good design without input from the development, test and deployment phases. The waterfall process may look really neat on paper. So does the command-and-control organization. In reality, neither works in the modern fast-changing world!

You may try to get it to work anyway and make a fixed time fixed scope agreement with your customer. It will fail. The time originally designated for testing will be used for developing workarounds and fixes for nasty bugs. And when you finally go into production three months late you will realize that much too much time was spent on writing overly detailed requirements for complicated features that no customers use.  While your main competitor managed to deliver a similar but more streamlined and less wasteful solution six months earlier...

- "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!

Focus and the meeting culture

Today I would like to talk about one of the biggest threats to focus and productivity in the free world: Meetings!

Don’t get me wrong, having a meeting is not a bad thing by definition. Working together is a great thing, so meetings could actually be fantastic. And sometimes they are, but very often they are disastrous to morale, focus and the general well-being of the employees.

Now why is that, and am I not exaggerating a bit? I believe that meetings are often bad because they disrupt the team’s focus in a severe way. Imagine a workday where we have two one-hour meetings scheduled for the team. Let’s assume the team members work 08:30 AM - 5 PM and go for lunch between noon and 1 PM. Also let’s assume that daily scrum is held 9:00 - 9:15 AM. Now, if the two meetings are scheduled to 10 - 11 AM and 2 - 3 PM, my experience is that most of the workday is wasted. The team doesn’t have time enough to enter a state of high-focus collaboration, except for maybe after the last meeting. In order to work effectively, my experience is that either the entire morning or the entire afternoon must be free of meetings.

I once listened to a TED talk where the speaker said that working and sleeping are similar in that you can’t get quality work or quality sleep if you’re interrupted all the time. As a father of two, I can relate to this. If your sleep is disturbed ten times during the night, you are destined be an unshaved sleepwalker at the office the next day. If you are a programmer and get interrupted all the time, you will never enter the zone of total focus. As a consequence, the quality of your work will be much lower.

The lack of great outcome from the team adds a lot of stress to its members. A stressed-out team will be even less productive. They will also start questioning the scrum ceremonies. The team will start feeling that retrospectives are time wasted. A vicious circle has been formed.

The only exception to this rule is when the meeting creates more value than what all the wasted focus time costs. And there are a few tricks you can use to minimize the negative impact of a meeting:

• Make it as short as possible. Try cutting the standard duration of your meetings in half - if you usually schedule one-hour meetings, try to cut them to 30 minutes! 
• Create a crisp agenda. Personally I am sick of all those two-hour meetings without an agenda you’re invited to. If you know the agenda well in advance, you will have the chance to prepare for the meeting. You will also have the chance of responding with an informed decline, as you will be able to assess whether your participation will actually create value. 
• Only invite a skeleton crew. The fewer that are disrupted from their work, the better. 
• Make the invitations optional to the highest degree possible. Don’t insist on attendance if it is not absolutely necessary! 
• Place the meetings in time so that the negative impact on focus is as small as possible. Right after daily scrum and lunch are great choices. 

It is always hard to practice what you preach, but I have been playing around a lot with cutting down meeting duration. I often separate room bookings from meeting bookings, so that a meeting can overshoot its alotted time if that is really needed. And if we are done after fifteen minutes at a thirty-minute meeting, we cut it short!

Last but not least, trying to change your organization's meeting culture too fast might turn into a conflict. In that case, I suggest meeting halfway!