I friend of mine once said; “I want to know what I do wrong so I can improve”. And to be honest, not only one friend and not only once, this is a very common way to seek feedback and it totally makes sense.

The question that has been lingering with me for many years is if knowing what you do wrong really does help you to change your behavior into a “better” one. Is that the best trigger to drive your behavior into a positive spiral?

My experience has told me that if I encourage the behavior I like, then I’ll see more of that. And if I, to some level, avoid giving feedback on areas of improvement then that will not be something in the center of attention and I’ll see less of those.

But, being a Swede I’ve doubted myself. We Swedes are known to avoid conflicts, so I hesitated. Maybe I just wanted to avoid pointing out all the bad stuff people did? Not until sometime 2006 (yeah I know ages ago) some guys in my teams put a poster up on a wall saying something in the lines of;

“Treat people as if they behave the way you want them to behave, then they will behave as you want them to behave”.

It took a while until I grasped the meaning of that and I had issues with the sinister manipulative feeling of it all. But it got me going to look for more input and what I found surprised me a bit, but also confirmed my belief even more so.

It turns out there is good scientific evidence to support the idea that positive encouragement has a stronger impact on changing a person’s behavior than pointing out all the thing they’ve done wrong. However, you should not totally ignore bad behavior, just don’t focus only on those.

Firstly, in Sweden, there is a program called Komet, which is directed to parents with teens that need help communicating with their teenagers. In the program, they teach parents a 9:1 rule. For every comment parent say on how to improve they should say 9 things their kids have done right. Positive encouragement should be the focus of attention!

Secondly, there is a psychologist in the US that study how to bring couples back together when they are about to split up. He says that there will a higher success after sessions where the couple tells each other what they like about the other person compared to if they tell them what they would like to change. Again, positive encouragement in should be focus of attention!

Based on this I want to spread the word of the “5:1 Rule”.

“When you give a colleague feedback, give them five times as much positive encouragement compared to areas of improvement”

This does not suggest that you ignore all negative behavior! And remember that all feedback should be concrete and focused on observations.

Go out there and make sure you have a positive impact on those around you!

You are starting up with a single backlog and a single team. Simple. Then you grow and some point you have to decide how to split your work. Some alternatives start to emerge:

i.) Multiple teams on single backlog

ii.) Split product in components and have teams working on components

iii.) Multiple feature teams on different collection of features but joint code base

iv.) I’ll leave my preferred alternative for a while.

Well each of these has it’s problems. Common problems discussed in agile communities could be:

On i.: Works with few teams, but not scalable. With too many teams you are forced into advanced branch handling and messy merges.

On ii.: Teams do not work with actual business values and you need team deliverables to be integrated with other teams and handover mess in your hands.

On iii.: Feature teams with joint code base do not care about the product life cycle and thus you usually end up with component teams that guard and care for the components. The feature teams also need to hand over and get changes approved by component teams which causes dependencies in delivery flow and is thus slow.

When exploring alternatives it makes sense to find out what is important in your organization. I will assume certain wanted properties:

• We want teams with product life cycle ownership. A single team without handovers that take responsibility for life time of code base. This support speed as well as has automatic incitements for quality.

• We want teams that have few dependencies to other teams or instances when moving requirements to production where the features can be used and explored by customers. This enables speed.

• All deliverables shall carry a customer value. Enables full understanding of how your features are used and you really learn how to build products that customers love.

Let’s try this. We have a company vision. Preferable we also have a company mission or purpose. I will assume you can split your purpose in several business areas that are all important but from a business side separated to a decent extent. Consider the separation that it must make sense to explore values and deliver these values in this business area without the need of a joint delivery from another business area in the most common situations. Teams working with this set of properties can be called full stack teams, application teams, end to end teams and what have you.

As you scale you can start creating separate backlogs for each of these business areas. Each maximizing performance and value in its area. By creating organizations around these areas, not only in IT but entire company, you have rather self running businesses all striving to accomplish the overall company purpose and vision. Remember that independence is never complete in a single area and it shouldn’t. Make sure to establish collaboration points across these areas when applicable and nurture these collaboration points. No one loves a silo!

So far this looks very similar to alternative iii. above. Let’s look at one additional property. Here comes the punchline friends. This require smart adaptation of your architecture. Let’s say that we are early on very conscious that we will grow and take the cost and time to continuously evolve our code base to match these business areas. Or that we at some point realize that we need to refactor our system and then mold our code base to match our business. Alternative iv below would then be a dream scenario, at least my:

iv. Multiple feature teams on different applications working on customer facing features and owning separate code bases.

This enables many fantastic benefits. Teams will be able to work on customer facing features without major dependencies and own product life cycle of the code base. It also scales in most reasonable cases. As you continue to grow also make sure to let the business areas branch out and create subdomains again freely living as its own organism. Keep following this approach in architecture as well as you grow.

Fig2. Gradually evolving your business areas and make sure your architecture follows.

Fig3. Completely new business areas (in this case “E”)can also be supported if the company moves in such direction.

Not an easy task since it requires a simple and small architecture that can be molded to whatever the company steer towards. On the other hand much easier than ignoring the fact that your code must follow your business. The SOA approach with microservices can be a possible solution that is fairly light weight to refactor and reshuffle in the sense of creating clusters of services serving a certain business area. If only we were so lucky! But then again, there is no such thing as luck. “Som man bäddar får man ligga” is a suitable saying in Sweden. (“As you make your bed you will lie”).

Grab the opportunities and steer your architecture to support descaling of your challenges.

Take control of your destiny, friends!

Grab your opportunities while scaling agile was originally published in Agile leadership on Medium, where people are continuing the conversation by highlighting and responding to this story.

Towards team autonomy

How fun is it to work in an environment where you constantly try to do your job, but too often encounter situations where someone else in the organisation overrules your decisions? Most of us have encountered these situations now and then and we all know how demotivating a single experience like this can be. A long series of similar experiences can even be devastating to your effectiveness and feeling of invincibility at work. It is an established fact that an important part of feeling motivated is your level of autonomy to solve your problems and thus enabling you to reach business goals. We want to be proud of what we do and without the authority to act as we see fit we end up in an environment that gradually breaks your self-esteem down. If you don’t have the authority, someone must think that you are not capable of performing these decisions.

In the following description of a workshop I have tried to solve one of the firsts steps towards autonomy, i.e. knowing what you have authority to decide upon and define actions to improve your ownership of decisions step by step in areas where it hurts the most. It is not designed for finding all improvements and change them all at once, instead try to find the most hurtful problem and solve that, then redo the workshop later when time allows and pain is too high.

Defining your surroundings

The first step of the exercise is to define important organisational stakeholders. Start with a prepared box-chart showing the organisational levels.

Figure 1. Organizational view, hierarchy.

Adding roles

With this overall description of the hierarchy at the organization under investigation it is time to start defining roles that have an impact for your teams. You might have a central QA department, head architect, subsystem architect, managers, DevOps, Infrastructure architects, DBAs, CIO, CEO, … Don’t overdo this phase, instead add roles later on if there is a certain decision that requires ok from a certain role you forgot to add in this phase of the workshop. When you are done the view could be something like this.

Figure 2. Including your defined roles important to you in the organization.

I personally like this view since it really reflects the complexity that you have chosen for your organization. And I want to make this clear , it is a choice and not just a mandatory situation you were forced into. If you don’t like it, step up to the responsibility to your own believes and change it.

Defining key decisions that matter to you

What is power? Jurgen Appelo defines 7 levels of authority in his book Management 3.0. You could go deep and define what level you are talking about in this workshop, but I usually just keep it to the level when a team feel empowered to take a decision themselves we are fine. Usually this means informing a certain role or instance in the organization, but that the team is not dependent on their approval.

When you now together define different decisions or responsibility areas make sure you spend just enough time to cover the most painful or important areas. I recommend doing this by splitting up your team in groups three-by-threes and then brainstorm areas and just quickly type them on a sticker. Do this for 10 minutes or until the members of the workshop feels that the most critical items are defined enough. Try to keep a note on what authority you are defining and also preferably what problems you currently see. E.g.

• Heading: Approval to release software.
• Reasoning: The team loses motivation and speed when waiting for formal release approval from CIO. Yeah it’s a silly example, but hey it could happen!

Placing an item in an area of responsibility

Each team should now place their notes to a certain role or organizational level using the rule definition above. This would lead us to place the note on the role where the decision can be taken without any other approval, however some other roles might need to be informed about the decision. Each team place note by note where they think it fits and explain why they chose that place. At this point place the notes where the decision currently is thought to be taken note where you would like it to be.

When doing this exercise it is often very common to realize that ownership for many decisions are unclear. When uncertain move the item to the higher end of the hierarchy and possibly note that it is unclear where authority currently is. Keep in mind that it is a good idea to redo this workshop continuously over time as often as you see fit.

For each note being placed, try to continuously place them in groups or just skip redundant notes. When having a larger group of people there will be much more redundant notes stating the same type of decision. Similar decision can just be grouped.

Figure 3. The look of the board after placing notes.

Note; already now you have reached a part of the goal, awareness of your boundaries. Much less frustration occurs when you know your level of authority. You can choose to end the workshop here and leave, still with added value to your team(s). A greater value comes with next phase which I highly recommend.

Defining the wanted position — Change definition

Even with limited time there are usually much more actionable items than you have the time or energy to act on at the same time. Also, finishing one improvement is for obvious reasons better than starting many that never finish.

Select the key pain points where the motivation is high to finish a change. Never estimate how hard things are to change, just make sure there is a strong will to adjust. There are many methods for voting or selecting from a bunch of alternatives. Use freely among any of those methods. A simple solution is to give each member in the workshop three votes to distribute freely among the items or group of items on the board. Select the items with top three number of votes.

Now you have three areas or items that you would like to change. E.g. a delivery decision might be on central CIO and you wish to move this authority to the team. Illustrate this simply by drawing an arrow from the group of notes or single item to the wanted role or organizational position, see figure below. Since this workshop is about autonomy and how to move into more autonomous solutions and by this improve motivation and performance the arrows should preferably point inwards towards the team or individual.

Figure 4. Moving power is as easy as drawing an arrow.

Some changes can result in several levels of authority moves. I.e. from CEO to team through entire org. This might require breakdown and start with actions to move the decision closer to team, even this empowers the team since the team will most likely have an easier interface to a closer role or entity in the organization and more power to influence the decisions.

Defining actions

Moving an authority for a decision will require some action and depending on numbers of participants on the workshop you can choose how to proceed. With a smaller set of people you can just have a broad discussion with all involved to define these actions. Simple checklist to cover when defining actions:

1. Define the definition of done for the change. When are we done? What has then happened? How do we know we are done?
2. Define what actors there are for a certain change.
3. Define what change you expect from each actor.
4. Define what final steps you need to do to make the change official and done.
5. Define who drives what action!

So we are all fine. We have defined the change we wish to see, we have defined actions to reach them and who should drive each action.

Some adjustments suggested as an outcome of this workshop might be painful for people in the organization. Some roles are all about taking decisions for others and by moving these decisions inwards to the teams these persons situation at work might be heavily impacted. This should not stop us from improving, but it is good to keep in mind when expressing the wanted changes.

Reflections

It doesn’t take a genius to realize that a complex chart with many roles and organizational level is hard to understand and slow in making decisions. In an age when scaling agile is a key word in your cv, roles pop-up faster than mushrooms a rainy summer. Be aware what organizations you build.

Usually a complex picture also leads to less clarity on who actually needs to take a decision and how to get the approvals you need to deliver the business values you are trying to accomplish. How motivating is this? It can be well spent time just to draw the chart with roles and levels which really visualizes your organizational dependencies and will in many cases generate aha moments.

Looking just at the team level it is clear that teams with many defined strict roles, such as PO, Tech leads, QA, DevOps within a single team, are less dynamic and slower. So much for team dynamics. Too many roles leads to a rigid, slow and unmotivated team in the long run, but that is another topic that interest me a lot. Self-organizing teams…

Enjoy life guys!

First steps towards team autonomy was originally published in Agile leadership on Medium, where people are continuing the conversation by highlighting and responding to this story.