About Agile

Agile? What does it mean to start working with Agile principles?

 

When you say Agile, most people think Scrum and Kanban, but there are a lot of other Agile disciplines, TDD, XP, Lean, DevOps are just a few of the most known, a more complete list can be found at Wikipedia - Notice that most Agile disciplines can be used together.

 

Let’s look at Scrum:

Let us assume that we create a Scrum team, we have a Scrum Master and a Product Owner, the PO create a backlog with user stories (requirements).

If the team only do the Scrum rituals they will do the following:

 

Before the sprint, they will have a sprint planning, where they pull work from the backlog until they believe they have enough work to keep them busy during the sprint.

 

Each day during the sprint, they will have a daily standup - a short status meeting - where they discuss the progress of the sprint.

 

At the end of the sprint, they will show a demo to the PO and those who are interested in what they achieved during the sprint.

 

After the demo, they will hold a retrospect, where they will identify

  • What went well, i.e. what they want to see more of
  • What should they stop spending time on or avoid
  • What should they do differently

They will agree on the most important topic and create a couple of action points which will help the team to become better.

 

Smart teams will also have backlog refinement frequently to look at the backlog together with the PO.

 

This is what many teams do – but does it work?

If you look at the number of discussions on blogs around the world, the answer is no, if you look at why companies try to adapt frameworks like SAFe, DSDM and LESS, the answer is no, if you look at why companies hire consultants like me, the answer is no.

 

So what is missing? The attentive reader has probably already guessed that there is no easy answer, but I will try to explain why it is not working and what you can do about it.

Agile is not a silver bullet that solves everything in a split second, Agile is not something you implement overnight, Agile is hard work, but Agile help companies to improve, companies will get more motivated and happier employees, companies will increase productivity, companies will increase quality and time to market – SAFe have studied results from many companies, and I believe that the results is general for all companies who successfully adopt Agile.

 

To succeed with Agile, you need to understand and anchor the Agile mindset in the organization:

 

  • Agile is about delegate responsibility and empower teams. When you execute projects, you use delegation, this means that you decide what you want on a high level and then delegate the decision on how to get what you want to the team(s) who do the implementation. You empower the teams and trust that they deliver! [see “delegation”]

 

  • Agile focus on continuously learning, no matter if you are a world champion athlete or a software developer, you need to practice to improve, I am not perfect, you are not perfect, the teams are not perfect, we all need to learn to get better at what we do, and the only way we make real progress is to practice. To practice and learn, we need to create an environment where we can fail. [see “continuously learning”]

 

  • Organizations have been created with traditional waterfall process in mind, but when you start to work with Agile, your organization and your mindset needs to change, you cannot keep an organization where you control everything (or more correct, think you can) and at the same time you delegate and focus on learning, you need to change the culture and the organization – this is the most difficult part in becoming Agile and this is why you need top level management support to succeed with an Agile transformation! [see “organizational change”]

 

I believe the challenges can be grouped:

  • Understanding and anchoring the Agile mindset
  • Experience and knowledge about Agile
  • Scaling Agile
  • Religious interpretation of Agile

Each of these topics is huge, but let us try to scratch the surface a little:

 

Understanding and anchoring the Agile mindset

Experience and knowledge about Agile

 

The basic Agile rituals are simple and the Agile Manifesto is short, yet it does require some experience and knowledge to get the most out of Agile.

 

You will boost your Agile transformation if you have people with knowledge and experience working with your Agile teams, they will see the challenges early, and it is easier for them to challenge the teams and the organization.

 

Our old way of doing things is often our enemy!

 

Very often we see people working with Agile who fall back to the old way of doing things and believe they are still working Agile, the “Daily standup” is an example of this challenge.

 

Example “Daily standup”:

 

I was invited to participate in a Scrum Teams daily meeting. The Scrum Master started their tool to visualize their sprint backlog and then asked the team members about their status, who in turn gave him their status. You were not in the room, but the meeting became a status report to the Scrum Master; the daily standup is supposed to be the team’s status meeting, i.e. they are supposed to talk to each other to secure that everyone knows who are working with what and identify where they are in the execution of their original sprint plan and if they need to do something:

  • If they have identified any impediments, and the SM needs to address this
  • If they are running out of work and need to pull in extra work
  • If they are behind schedule and either need to work a little extra to catch up or remove things from the backlog.

The daily standup meeting is never a place to report status to a SM or anyone else.

 

The impact on the team if we did not change it, would most likely be that the team becomes passive, i.e. the slip back into the old way of working where they are doing the coding and a project manager is responsible for and handling the project planning and status – When you work with Scrum, the team is doing the planning, the team is responsible for their plans and deliveries, the team need to adjust and learn, the team need to take action if things are not working as they planned.

 

The problem here was that the SM was holding a traditional status meeting rather than a daily standup, this was due to lack of experience as I see it.

 

Example “Protect the team”:

 

I was asked to be the Scrum Master for a team with several problems, the very first thing I found was that the team was constantly interrupted, so I talked to the employee’s manager and we agreed to communicate to everyone contacting the team that they had to come to me (the Scrum Master) and I was allowed to say no and put the request on the backlog for the coming sprints (the PO would have to prioritize the requests).

 

I communicated to the team and asked them to send any requests to me, it took 2 days before the team was interrupted again, 2 team members were told to do some work for the manager…. I naturally addressed my concerns with the manager, he did agree that he was violating our agreement, but he needed the work done, and he did not know any other way to get it done – sounds familiar?

 

Our old way of doing things is often our enemy!

 

The manager in the old world is also responsible for creating ideas for the company (innovation), she is responsible for the departments portfolio backlog (future work and improvement initiatives), she probably also feel responsible for the product the team is creating AND there are without any doubt a lot of work the department is responsible outside the PO’s backlog..

 

This is classic, we change things, but forget to think it through – if we had anchored principles and created a learning culture, this would fix itself over time, but the company and employees will benefit if we address known issues upfront. [See “Organization change”]

 

In the current case, the manager position should be split into 2 separate positions:

  • a PO with product "responsibility" and no employee responsibility and
  • an Agile leader with employee responsibility but no product responsibility!

 

If you keep interrupting the team, the team’s commitment at the sprint planning is worthless, the PO is overruled, the delegation and empowering is gone, the team will go back to the old way of working – You can interrupt the team in emergency cases, but the ongoing sprint must be stopped and the team will create a retrospect and a new sprint plan etc. – you do not want this to happen too often, it kills team motivation and is very time consuming.

 

Scaling Agile

 

Scrum teams often have dependencies, either to themselves or to others, the dependencies could theoretically be solved if the teams do backlog refinement looking far ahead, i.e. you could identify that in order to deliver a user story, you will need something from another team, and you could then deal with that – but a much better approach is to use Essential SAFe, the ideas is to frequently plan 4 sprints ahead together with all the other teams you work with. The idea is that everyone gets together and plan their coming 4 sprints (I personally prefer 4+4 sprints, let me get back to that in the example) and address all their dependencies (i.e. they have a plan together with those who they have a dependency to) before they finish the workshop.

 

It is an awesome experience (though I must admit that I was skeptical the first time I heard about it, and the development teams I have been working with have also sometimes had their doubts, but we have all seen the light – I have dedicated my work to Agile, and my development teams have been promoting PI workshops to other Scrum teams!), the teams meet, they plan together, they commit together and they execute together! The commitment is much stronger when they do the plan themselves!

 

The “side effect” of PI planning is that the teams, the PO and management knows what the teams will work on for the coming 4 sprints, the teams have also booked meetings to secure integration with other teams (if there are code dependencies), the teams will have a common goal which they work on together.

 

Example:

 

When I was working with Greenwave Systems, we had 8 Scrum teams working on the same project, I introduced PI planning (calling it 4+4 planning, looking roughly at additional 4 sprints), I was first educating management in what SAFe and Agile is, and how PI planning works, to secure the buy in from our C-level officers 😊

 

Our PO had a long backlog of items we were going to put together to create an amazing product.

 

The 8 teams were located at 4 different sites in 3 time zones, the original idea is to have everyone come together and plan together, it is possible to do it with remote teams, but that requires someone at each site to facilitate the process, and we only had me, so we decided to get 1-2 senior developers from each team to come together at the same site, and then have everyone at the site where we were meeting join us.

 

I start the workshop with an overview of what we plan to do (I will do a more formal education in case it is the first time), the next is the PO who explain the product vision and then he explain the goal for the coming 10 sprints, the teams split up and start to pull user stories from the backlog and plan when to implement them, they also identify dependencies to other teams and agree with the other teams on how to solve them, all teams make sure that they add time for integration and test in each sprint, as we were creating a product together, meaning that after each sprint, we were doing a demo which require that everyone have integrated their software into git.

 

The reason why we use 4+4 sprints and not only 4 sprints (as SAFe 4.5 describe) is that we want to roughly know what is coming in the next 4 sprints, so we can prepare spikes and dependencies, as an example, one of the teams found that they were expected to deliver support for a ZigBee protocol in sprint 8, as that was a new protocol, meaning that the team needed to add spikes to secure that they understood ZigBee and technical stories to modify the architecture to support ZigBee – if we had not looked 4 extra sprints ahead, we would not have been able to secure the ZigBee delivery, we did now!

 

The extra 4 sprints is very rough, the purpose is only to identify if we have work coming which we need to address (spikes or dependency stories) in the first 4 sprints!

 

Below you can see 3 pictures, an overview of the PI planning, pictures from PI planning at Greenwave System and pictures from PI planning at Danfoss.

 

I strongly recommend you to try PI planning, and I strongly advice that you get in touch with someone who have done this at least once – the first workshop usually looks a little chaotic in the beginning, so it is good to have someone who have tried it before and can guide the teams during the workshop!

 

Religious interpretation of Agile

 

I have been working with Agile since 2008 and I met a lot of people and a lot of different opinion about Agile, some have very strong feelings about how to work with Agile - In all we do, we add emotions, if we don’t we become robots.

 

Emotions means that we have feelings, sometimes strong feelings, and I frequently see people going into a subjective discussion about their work, sometimes with different opinions, which makes me think of WWI trench warfare or even religious warfare discussions. This is to take it to the extreme, but I do see it frequently and it is a problem, because we do not get the best solutions when feelings and attitude control the discussion, we need to have objective discussions to have a constructive discussion and find the best solutions, which is exactly what we teach the Scrum teams – but sometimes SM, PO or managers forget that we are on the same team… I will write more about this in another post.

 

Agile Konsulenten ApS - Phone +45 3132 3941