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!

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!

Outsourcing kills the feedback loop!

It is human to optimize locally. In this blog post I would like to shed some light on one specific local optimization: Outsourcing your maintenance.

It all sounds very logical: Instead of slowing down the teams by having them fix the bugs that their software causes in production, let’s form a specialized team that will take care of that boring chore! So that our best people can focus on creating value! And better yet, let’s outsource maintenance altogether! We don’t have time for bugs, let’s focus on the customers! Let’s be customer-centric!

This looks neat from an accounting perspective too, with separate teams for CAPEX (new investments, i e new products and features) and OPEX (operational costs, such as correcting bugs).

However, when you put on your Agile glasses, you start seeing that this is really bad. The first thing that strikes you, is that the feedback loop from production back to the development team has been severed. In an organization that outsources maintenance to a separate team, there was probably not much of a DevOps setup to begin with. But the team was at least informed about the bugs that were found in production, since they had to fix them. So this was the feedback loop. And now it has been cut.

Without a feedback loop, learnings from production will never reach the development team. Let’s say the team forgot to close database connections in their code. After an incident in production, the maintenance team creates a hotfix to correct this. But the development team isn’t in the loop, so they never learn of the problem. So, in the next release there is yet again a problem with the database connections. And so it continues.

The second problem is the amount of waste this creates. The development and maintenance teams need to do constant handovers if this setup is to work at all. Handover is a Lean waste. Wasted time and energy. Since the maintenance team has to fix bugs in software that they don't fully understand, there is a high risk of overprocessing, which is also a Lean waste.  

The third problem is the organizational culture that might be the root cause of the local optimization. Somehow, the organization thinks it is most efficient and best that specialized teams do specialized task. This degenerates fast into a sequential waterfall which rids the organization of the dynamics of crossteam knowledge sharing. Put simply, the Organizational intelligence will not reach its fullest potential, since people will work separately instead of together.

Instead of insisting on local optimization, be Lean and Optimize the whole! Instead of outsourcing, insource! Keep maintenance within the team and also insource operations! Don’t just fix the bugs, find them before the customers even notice them - by insourcing monitoring!

This approach is also a great way to switch the focus of the organization from delivering as much functionality as possible to delivering as much value as possible. And that's being customer-centric for real! 

Seriously, do celebrate your failures!

Celebrate your failures! is a ubiquitous Agile mantra. But what does that actually mean - and why on earth should you celebrate your failures? It is your successes that should be celebrated, right?!

It is true that team successes should indeed be celebrated. Celebrate these often. This is a positive feedback loop to the team that enhances good practices! But do make sure the entire team get to celebrate - we don’t want any heroes or favorites in the team, as that will damage the team spirit - ”hero personas” within the team will surely decrease collaboration. 

But what I want to talk about in this post is not how to celebrate successes. I want talk about failures. Of course, there are different types of failures. I am not talking about failing to come in to the office in time for the daily standup. An example of a failure that does fall within this post is:

"We decided to skip writing unit tests for one of the features we delivered last sprint. The team had committed to it in the sprint backlog and the Product Owner really wanted that feature to be deployed at the customer’s site by the end of the sprint. As a consequence, we have spent this entire sprint trying to fix the chaos that resulted from deploying the release."

In this case we can identify a few obvious learnings: Lower quality (no unit tests) does not mean higher speed or faster delivery - on the contrary it means lower speed and late delivery. Also, the team may be overcommitting, which might be the root cause of the incident. And on further analysis, maybe the old-style habit of committing to a sprint backlog is a local optimization in this case; perhaps it would have been easier to optimize the whole if the team had committed to a sprint goal instead? 

Ergo, a failure is actually a bunch of valuable learnings in disguise!

The Retrospective is the ceremony at which the team extracts learnings from their failures (and of course from their successes too). There should be no blame and no punishment. Instead, strive for an open and positive ceremony where everyone feels at ease. Focus on finding the root cause of failures and discuss how problems can be solved. Create (a limited number of) actions/experiments and commit to these. And then celebrate the failures! I suggest bringing Swedish "fika" such as cinnamon rolls to the retrospective.

For continuous improvement to work, the feedback loop from the retrospectives is essential. Now, imagine we are in an organization where failures are hidden and never talked of, due to a culture where they are unacceptable and therefore punished. In a such an organization, the improvement feedback loop will run dry. This means that the organization will cease to learn, stop improving and probably get behind its competitors, eventually going out of business.

Therefore, celebrating your failures is the antithesis to going out of business. And that is my point: Celebrate your failures, or you might eventually go out of business!

Continuously Inspect and Adapt!

In this short post I would like to share an experiment that I have been doing over the past year - the concept of Continuous retrospective.

Usually, a team's retrospective appointments are booked well in advance. For example, in my teams we try to have our recurring team retrospectives once every four weeks. The meeting is timeboxed to between 45 minutes and an hour, depending on team size.

But sometimes it feels much too rigid having to wait for many weeks between retrospectives - you ideally want that feedback loop start flowing with learnings right away! Therefore, some of my teams have started to do ad-hoc retrospectives when we feel the need for it, for example after a chaotic deployment or if there is a conflict within the team.

As the retrospectives are ad-hoc, we just go find a room and get started. Keep it swift, go around the table and discuss what went well and what didn’t. Try to find root causes for problems - 5 Whys is an excellent tool for that. Make immediate adjustments or commit to experiments (Not too many, preferably just a single one!) that might solve the problems. Then get back to work. 

The implementation of Continuous retrospective makes the team-process feedback loop run continuously instead of delivering learnings in big batches. Also, problems get addressed faster which means that they won’t have as much time to grow!

Inspect and adapt, continuously!

Trading Persona for Trust

One thing that has been on my mind lately is how to coach a team in order to help it reach the Performing stage in Tuckman’s group development model. Even if a team does incorporate all competences that are required to fulfill the team’s mission, I find it common that the team gets stuck in a stage where everyone stays in his or her comfort zone. Cooperation within the team is realized through handover between competences (or even worse: roles), which is of course a local optimization. Ergo, this is a team with a lot of I:s - contrary to the well-known saying.

My experience is that this type of environment is not a fertile ground for collaboration. To me, collaboration is a high-energy state where the team acts as one and where the whole is greater than the sum of its parts. When this type of team is iterating over a new design or hunting down a performancy issue, you often don’t know which of its members that came up with an ingenious breakthrough. This is because the team can somehow collaborate to the extent of becoming one mind. Therefore, who came up with an idea is both impossible to know and irrelevant to ask. This type of team is an example of the Lean principle Optimize the whole.

Teams that have reached this nirvana-ish stage consist of people who are comfortable both with themselves and with each other. And I’m not saying that they are complacent. I am not saying that they always agree and that there are no conflicts. Because there are always conflicts and that is actually a good thing - this would be material for a blog post on Agile and Hegelian dialectics. What I am saying is that the comfort zone has grown to incorporate the entire team.

As of late I have become interested in Jungian psychology and its theories on personality. Now, I might inadvertently prove the Dunning-Kruger effect by posting this, but please bear with me. As a layman, what really caught my eye in my first introduction to Jungian psychology was the concept of the Persona. The persona is essentially a mask we wear in order to be able to function socially. The persona makes sure that we follow social rules and don’t generally misbehave. Anyhow, I believe that in order to function as a collaborative team, the team members need to - at least partially - lay down their personas and instead cultivate their true selves. Why is that? Because this builds honesty and trust. This rids the team of competitiveness and alienation. And a team with honesty and trust is a team where collaboration techniques will work extremely well, very easily!

From my personal experience, this type of team is usually the outcome of a small group of very competent people that have had to work very hard closely together in order to reach a goal. If the group is too large, it is much harder to reach this stage. (This is one of the reasons for my being a proponent of micro teams.) The same thing applies for a team that is not forced to work closely together in order to reach a goal.  

So back to the original question: How do I coach a team in order to help it reach this stage? I believe that I should stop trying to control the team. Instead I should take a step back and hold space. I should open my heart and let go of judgement. I should walk alongside the team and provide support. This will rid the team of fear and build trust. Without fear and full of trust, the team members will start shaving off their personas. And right there, might we not have found a shortcut to Performing?

A passion for Agile

This is my first blog post ever. Not that the concept of blogging hasn’t interested me ever since it became popular in the early noughties. But I always figured that in order for me to spend my precious time and energy on writing blog posts, I would need an audience. And in order to get an audience I would have to write blog posts interesting enough for people to read them. So I quickly gave up on that dream.

But now that has finally changed. 

Since two years, I’m a full time agile coach at Telia Company’s TV & Media department in Gothenburg, Sweden. Even though I seriously have no clue as to what an agile coach is supposed to be doing all day, this position has given me the luxurious opportunity to spend time pondering upon what agile really is, how teams can go from cooperating to collaborating, what factors that drive motivation and what the ideal size of a scrum team is. For example.

Last summer I co-wrote a a blog post on Telia TV’s agile transformation, together with Michael Göthe at Crisp. The response from that post has lead to many interesting discussions and insights, which has in turned made me grow professionally. And it has been great fun.

I want this to continue. I want to spread my thoughts on agile and start a discussion with you, my readers!

So today I start blogging - and may this not be my very last post! :-)