Keep a positive mood in a Agile Transformation

 

When an organisation starts an agile transformation, it ideally pursues a certain goal because it has been recognised that existing ways of working bring too many disadvantages with them. The more people are affected by the transformation -  by the change in the way of working, the more difficult the transformation becomes. 

Change and new ways cause uncertainty. That is why resistance to transformation is pre-programmed. This is not a bad thing per se, it is human behaviour and the task of managers and coaches is to pick up employees accordingly. The best way to achieve this is by explaining the why, as this is the most likely way to get supporters and followers in the company. The more followers that join, the greater a pull effect that draws other, more cautious employees along.

As a leader and coach, this is sometimes a very energy-intensive job, because it is not one issue after another that comes up, but usually a large number of necessary changes lie ahead. It is essential to ideally initiate changes immediately. Step by step, even if they are small steps, lead to the goal. 

Goals that are measurable require more effort to define, but it helps immensely to achieve the goal. A goal of "fewer bugs" is far too soft and has a pale taste. A goal of "x bugs less" is stronger and you can clearly see when you have reached the goal. To have a comparison in running, "run further" would be less meaningful than "run 10 km".

When you reach a goal, you should celebrate it. Small rewards and celebrations can also be an important contribution to the motivation to pursue further goals.

Finally, I think it is important to reflect regularly. What have you achieved? Especially in difficult situations, looking back helps you to gather enough energy to move on.

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.