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.