Be a leader

 

 

Already 55 years ago, Melvin E. Conway came along with the insight "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

 

Since then, the software product world has changed dramatically while most of the software companies have been created within that time. Around 20 years ago, the Agile Manifesto was released and is spread since that through the world and a lot of companies jumped on the Agile topic - jumped on and not dived into. And while more and more jumped on, the questions need to be raised why a company wants to go Agile.

 

-Why Agile?

The higher in the hierarchy you address this question, the more it will spread through the company. A good place is to be addressed within a company plan or vision. If you do it just in your development teams as it is fancy to have Agile teams, then you will get this structure sooner or later into your product and it will not be good. Keep the law in mind.

Changing an organization is probably the most difficult part in an organization because it results in gaining and losing influence and power. Thinking e.g., on Scrum, there is no line manager needed and of course this causes social fear in these people. Also, the team members who gain power and responsibility need guidance.

The lower in the hierarchy Agile will "deployed" the more methodical cutlines you will face. Then you have people within and outside of Agile.

 

-Face the uncertainty

Uncertainty is always present in software development. The question is how to handle this. When the team is stable, uncertainty can be reduced by addressing learning session to reduce knowledge gaps and for project management to use forecasting on existing data instead of forecasting on estimating.

Keep the iron triangle in mind. If you try to fix all edges you are lost. You can deal with uncertainty but not get rid of it.

Now what?

Even if you face a similar story as described in the past posting, nothing is lost. As plants will grow after a firestorm, Agile can grow after chaos. In the next posts I will come along with improvements to use then the momentum to an Agile acceleration. 

Scrum does not work!

 

Frederik was the chosen. He got the job to coordinate the introduction of Scrum in the company as a lot of companies started with Scrum recently and applicants ask for Agile development. Frederik invited a big consulting company to support him. They did some basic trainings with all employees, and some were asked to do the Scrum Master certification. Department teams have been regrouped into Scrum team with a previous project manager as new Product owner.

The setup was complete, Frederik was promoted to the Agile coach as he was involved in most of the Agile changes.

Anna, Steve and Martin became Scrum Master and they really dig into the topic. They cared that the Scrum events are held, did a great job with facilitating the meetings. The new product owners got their input from their stake holders within the company, mostly salespersons and other project manager. It was important that the Scrum team deliver faster to increase revenue. The company grew in the past years always more than 10%, with Scrum it should be even more.

The initial retros were filled with a lot of topics and the workflow within the team was improved. Scrum seems to be shining after some sprints: daily’s are timeboxed to 15 minutes, sprint planning and retro is working fine. For the review, stake holders do not attend now as they expect that the team just deliver in time.

After some month, developer mentioned they have so much to do now as the team should be self-organized. This slows down the team. At the same time more and more must have requirements came via the PO to the team.

Then a major release came, and a lot of customers updated and reported several issues. The product teams had a lot to fix and the feature pipeline was delayed. Project manager started to have the opinion that Scrum does not work, they do not get their needed software in time even if they have a deadline with the customer.

In addition to that the team wants to improve usability and do some refactoring’s in the software. As this is not related to a certain revenue, these requests are postponed and the team reduced their job in deliver requested features.

 

Scrum does not work ... if you just install Scrum teams within a Waterfall oriented organization. It needs an Agile environment to get the full potential otherwise there are always some methodic divides. These break lines are poison for the company and needs to be addressed. Then Agile can spread  and on that any Agile Framework can grow.

Compared to a digital break line in a workflow where you have first a paper and then a digital workflow, you see this immediately on introducing the digital workflow. When you change a method, the break lines are invisible and pop up one after another. Within the team, the retro catches up a lot of them. But within the organization it gets difficult as a change in process often comes along with a change of power.

 

And believe, Agile (and Scrum) works!

Values

 

It is travelling time

 

 

Photo by Egor Litvinov on Unsplash
  

One of the benefits of Agile development is to get value earlier to the customer. This gets this benefit, companies started to introduce framework like Scrum. This is journey starting point, it is not an event! Depending on the structure of the organization and the teams, be prepared for a longer journey and keep on going. You are not finished when Jira is installed the board is configured.

Today I set the focus on the team’s responsibility of getting things done. Even that is still a big topic, lets further zoom what a team needs to get issues done and reaches the Sprint goal. Let's zoom in even more to set the spot on the resource allocation within the team. At the beginning of an Agile journey all teams will face the issue that knowledge is hidden in silos. Spreading knowledge is the key to success as a team. This does not mean getting everybody everywhere on the same level. Beware of that as you will lower the experts’ skills while and you will lose technical excellence and you get for that medium technical awareness.

Have you ever heard about the bus factor? What if somebody is hit by a bus? Can you still deliver value and reach sprint goals? Last one probably if you are not in a feature factory. The bus factor indicates a risk of missing shared information and capabilities. Draw your needed team skills like Javascript, Java, SQL, Testing and check how many members have these skills. Skills with only one person are very risky as even holidays will block your team in getting it done.

To do this more in detail, you can use stars how familiar you are with a topic like 1 star for basic knowledge up to 3 stars for deep knowledge. As a team goal, reduce highly risky areas by knowledge transfer or define how many stars you want to have on a skill.

In my experience I saw teams where Waterfall within the team was quite common, where developing starts after finished requirement and testing starts after finished developing (and finished code review). If you are trapped in that situation look for pair sessions or engage to start with testing earlier and gets developers to the tests.

Team members needs to jump out of the silo mindset and management needs to stick on that the minimum time effort is not the primary goal as the getting it earlier is more important.

Remember getting it earlier does not mean that the issue is faster coded or faster tested. The team members did also before the great job what they do it within Agile development. With the bus factor greater than one you are on a safer side to get something at all.

Happy travelling in summer!

Agile, Scrum & Running

 

Photo by sporlab on Unsplash

Yesterday when I ran home from work, it had around 25 degrees. I already felt a small fatigue from the run to the office and thought about my planned running time.

I do not plan a concrete time as it is nearly impossible to reach this exact time as I need to cross several roads and might wait on a lot of crossings. It reminds me on the Scrum planning meetings

where the Sprint is planned. It is always a best guess for the next 14 days. We can consider some uncertainties like incomings bugs or sick leaves, but it is not possible to plan everything.

As different to my run where the distance is fixed and the time is flexible, in the Sprint the time is fixed and the scope is flexible. In both cases the resource is also fixed for the planning.

 

Pace is the key for a constant run. Running too fast will drain your power too much and you will either miss your goal or you will suffer from that run some days and you need a break because of an ancle.

When you work in the office on a complex problem, you will not get an ancle in the muscles, maybe your neck or back will gives you a sign of being overworked. The core topic is here the mental health.

If you will then need a break, this can take weeks or even month to get back. Get your pace is the key, is does not matter if this is for sports or in your office.

 

But what is the pace in detail? On my yesterday’s run, I had an average pace of 5:38. Looking into the details, I never run a kilometer that pace. Sometimes faster sometimes slower. When I look on my watch, I try to stay in a pace range and adjust my speed. Running faster is nice but I know that I will not be able to do that on a longer distance. When I run slower, I inspect the circumstances: Are my legs tired? How are my arms and legs technique? Is my breathing in an acceptable range? Is there a slope? Or is my brain getting tired? On base of these inspection I

can do an adaption. - INSPECT and ADAPT.

Is there any difference to your daily work? If something in the Sprint decreases the performances and the sprint goal is in danger, inspect and adapt. The sooner you can adapt, the sooner you are back

on your pace.

 

After a successful run, my satisfaction is high and there is motivation to run again, maybe even faster. To be faster, I can do that just by running the same again and again until I stuck on a level of pace. Simplified said, there are two limiting factors - on the one hand it is my available running time and on the other hand it is a missing training plan.

To run faster, a training plan is needed with different running styles to improve the ability to run faster.

Compared to business, working on a continuous pace will make you faster until a certain level because all recurring tasks needs less time, and you have time for some new tasks. But that is also limited as my same running’s again and again. Getting better in your job needs a learning plan and that highly depends on you what you need. This makes you stronger and better.

The key for getting better is motivation. Without motivation, you will stay on a certain level and that is the key for all leaders to keep the motivation high. Then the great success is a no-brainer.

Willpower

[Imagine the picture here]  

Gamer probably know about stats of characters in a game. In some games the stat helps to resist, some games are completely about and around willpower. I do not want to talk about the stat in the game. I want to have a look how this affects the gamer. In most of the games you can adjust the difficulty setting, this is quite common for a long time. Play a game again using and increase the difficulty setting mostly is more challenging and focus more on your motivation for achieve the new difficulty setting than your willpower.

A great game about willpower is The Darkest Dungeon. It is about heroes wants to escape a dungeon and are afflicted by a stress level. If a certain level is reached a stress test resolves with a chance of 75% of any affliction. The other 25% results in virtuousity and they can go then far beyond because of their willpower.

Of course, this gaming setup also inflicts the player himself. I cannot say how many "oh no" and "..not again.." I had in this game. To finish the game, you need some extra portions of motivation.

 Have you ever thought about willpower in your daily life? The ego deplention theory refers to the idea that self-control or willpower draws upon a limited pool of mental resources that can be used up[1]. 

I do not think, that there is a counter in you brain like today 20 and tomorrow 24 and after that counter you start to fail. There are a lot of dependencies which affects this effect of the theory and I do not want to talk about all influences. 

If you keep on focus on the theroy, it is about making errors. Working 12 hours a day in software development will probably decrease the overall performance in the long time. Team members get ill and are not available and Bugs are added to the code which results in technical depts.

This is not what you want in the company, or like in Darkest Dungeon on the way out. Keep the stress level on a manageable level, avoid and mitigate bad stress.

[1] https://en.wikipedia.org/wiki/Ego_depletion

On blaming

[photo by pixabay]

 

 During my readings of "The Art of Doing Twice the Work in Half the Time" from Jeff Sutherland, I came over the Milgram experiment and the blaming topic. 

The experiment was about Authority and also about the question if the Holocaust was caused by just following orders.

As mentioned on Wikipedia[1], three individuals took part in each session of the experiment:

• The "experimenter", who was in charge of the session.
• The "teacher", a volunteer for a single session. The "teachers" were led to believe that they were merely assisting, whereas they were actually the subjects of the experiment.
• The "learner", an actor and confederate of the experimenter, who pretended to be a volunteer.

The teacher was asking the learning word pairs and for wrong answers the learner gets an electric shock with increasing voltage from wrong answer to answer. If the teacher wanted to stop the experiment, the experimenter used words to force the teacher to continue [2]

 

1. Please continue or Please go on.
2. The experiment requires that you continue.
3. It is absolutely essential that you continue.
4. You have no other choice; you must go on.

 The majority of the teacher got to the maximum voltage. 

Now, many years later, this experiment is a great source to analyse and a great sample for asking questions. It got quite common in the past decade on the court yards and also off them to always look for a guilty person. But does this mean, everybody just has to follow orders? Asking about the experiment, who did it wrong leads to a wrong mindset. Is is none of the participants it is the experiment itself. The teachers and the experimenter did simply said just their job. Blaming the teachers as they were the persons who did the electric shocks might be the easy "solution", but is it? Many of the teachers were heavily stressed and if started to doubt the experimenter tried to push them to continue.

As a conclusion and takeaway, recognize stress in the teams to prevent errors is at least important as avoiding to blame persons. Remember from the previous post, a decision of a person to a specific time is always correct, it depends on the system around. 

Also in case of something wents wrong and you know the external cause, you probably can react with an answer like "it is not my fault, it is because...". Take a moment before answering that way. What does this answer helps to solve the problem? What can you do to prevent this next time. Do not blame, improve the system!

[1] https://en.wikipedia.org/wiki/Milgram_experiment 

[2] http://library.nhsggc.org.uk/mediaAssets/Mental%20Health%20Partnership/Peper%202%2027th%20Nov%20Milgram_Study%20KT.pdf

[photo] https://pixabay.com/de/photos/schuldig-fingerzeig-deuten-3096217/

Choices and decisions

 

The life is full of choices and they can be categorized in many ways. Starting as a baby until the first years a lot of decisions are intrinsic. Although most of them are also unconscious, depending on the external reactions, decisions can became very soon conscious.

Later on through social learning, there are a lot of unconscious decisions probably even more as you think of. In time of big data of customer behaviour, predicting customer decisions make them way more conscious even if the affected person might not realize this.

Self-reflection is a great way to clarify unconscious decisions. Why did you decide for on choice? What did you support? Who influenced me? When was the decision clear? Where is the place for the decision, is it outside during a walk? Which facts helped to decide? How did the decision affected me? 

Use this to prepare yourself for the next decision, making it easier and it strengthen you. No matter of that, everybody faces from time to time difficult decision. Having two or more choices and the decisions affects you to a larger extend, the most importent thing is to decide.

No decision is no solution. In my jobs I often faced that the result was no decision or a postponed decision. Both leads to delays and ends in a task shift. For sure, getting completely rid off that problem is nearly especially the larger a company is the more persons are affected and/or involved in decisions. Using retrospectives are a powerful instrument to identify and address these impediments.

Decisions are always correct. 

If somebody decide, it is always correct otherwise the person would haved decided for an other choice. This is essential to understand decisions which seems to be crazy, stupid, awful or whatever. Some decisions have been wrong in hindsight because you get additional information or have more or a different context. To understand somebodies decision, it is necessary to understand the person in the moment of the decision. 

Understanding other people is an essential part of working together on the job, especially in terms of motivation when making decisions. It helps to prepare the selection of options in such a way that there is little or no waste.

 

 

 

Pillars

 

Pillars are used in human kind since thousansds of years. If you go to Italy, Greece or Egypt you will find a lot of them. For me, every time I see these architectures, it is impressive. They did not build a wall for these buildings, they used the pillars to get someting really great. Imagine they would have build the temples with walls - they would look more like a castle or cuboid than a temple.

Pillar styles changed through the time but the core functionaliy staid the same - being a essential part of something big.

Pictures for any informatoin reuse the symbol of pillars to easy show essential parts and reduce the amount but not the value of information. You can find pillars of health, pillars of finance, pillars of selling on amazon and many others. All these samples you can find transports the core information with a word or a short phrase. The value of it is, you can easy remember it and you can embed these values in your life.

In the Agile manifesto there are also pillars, phrases you think they are simple to understand but hard to master. 

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

But why? In the picture above you see, that just the pillars are still here. The Agile pillars also are just a base of something great. You need to think also of many other aspects to build, rebuild or change your organization so that the next earth quake or storm is handled easily.