Agile or Not – Retrospectives is key!

As human beings, it is our nature to learn. We start learning when we are small, we learn as we grow up, and even as adults. We learn about life – to make decisions. We learn more – to make better decisions than previously. We do it all the time. It’s our nature. We are hardwired with this skill.

Regardless how natural this come to us when it’s about daily life, and only ourselves involved, it becomes something extremely difficult, for many many people when we put ourselves in a workplace together with other people.

This could be the result of “management” – The command and control kind of management, that manages and control people. It kills initiative from individuals and it kills creativity.  Which again will result in poor performance, for the individual, the team, the department and the company.

If you have been studying “agile”, whether it’s Scrum, Kanban, SAFe or any other agile framework, you will notice that when you cut it to the bone, it’s all about creating environment for – you guessed it – learning. It is about learning as an individual, a team, a department or an entire organisation, learning about  your product, learning about your work processes. Learning, so you can make better decisions in the future.

Implementing an agile framework prove to be “not as easy as it sounds”. Not because it is of no value, but because it requires change. Change in behavior, change in mindset, organisational changes and more.

Maybe you have tried agile methods and found “it wasn’t for you”, maybe you are already in the process of implementing agile methods, or maybe you just don’t see the point. Nevertheless I believe you would like, your team would like and/or your organisation would like learning to make better decisions in the future. Luckily there is a very powerful tool, which you can implement regardless of which agile framework you are using or not using.

It is called “Retrospective”.

It is a powerful tool which is about gathering people, for a fixed period of time and have them reflect upon and learn about “they way we work”, and based on that decide small things that can be done differently next time. And then keep doing it.

If will foster individual initiative. It will boost creativity. Empowering people through well conducted retrospectives will eventually make you team, department, product, projects and/or organisations better. Nice!

To get started you need:

Doing retrospectives does not solve your problems by it self. But it will help you uncover known and unknown circumstances that have impact on whether you perform good or bad. Based on your findings (learning), you can decide on what to do differently.

Visualisation of “Very very important tasks”

“I have this very important task that needs to get done. Who will do it?”
This is a phrase often heard, and every ScrumMaster eventually will have to deal with. A mature agile team will have it’s work agreements and processes to deal with this type of request in an efficient manner. However, not so mature agile teams, and teams in a early state of their agile journey, should be very alert when hearing this sentence, as it maybe a symptom of an underlying and more serious problems.

But why should we be alert? It’s just <someone> who wants to get this task done, what is wrong with that?

There is nothing wrong with the desire to get things done. After all, this is what companies live from. But there are many underlying problems that this particular sentence can be a symptom of.

In a software development team of mine, we faced failed sprints. Every 2 weeks. Mostly due to this type of requests. Ever changing priorities was one reason for not meeting sprint goals. The solution to this, according to the “Scrumbook”, is obviously to lock scope of work for a sprint, and move the incoming requests to succeeding sprints. This just didn’t work for us. Developers felt this was the same as saying “No, your tasks is not important”, and product management did not like to hear that. It worked for nobody. We did not have a full time product owner, which was also a part of the problem. I have written about this subject in another blog post https://agilereflections.dk/2016/10/12/lack-of-product-owner-what-to-do/

All tasks are important, otherwise it won’t be a task in the first place. Therefore the argument “I have this very important task” is not an argument for getting the task first in line. Believe it or not, adding another “very” or even “very very very” doesn’t make the argument better. So let’s stop discussing if a task is important, let’s discuss how important is it compared to the other task we have, seen from a company perspective. This may sound simple, and result in what we know as a “prioritised backlog”, but it can prove to be difficult to understand for some – even people with agile training.

It was a big issue being part of a team who got “slammed in the face” every other week with “The sprint failed – Again”. So to keep our motivation up, we decided to kill “sprints”. With that decision our board turned into a plain kanban board, where the highest priority was on top. This gave instant advantages such as:

  • As developers we could say, “We can do the task, it will be placed on our board”
  • Product management no longer felt their tasks was not taken seriously.
  • Priorities became very visible, and a constructive dialogue instantly began.

Even though the amount of task on the board exploded, it was a relief for the team, because, we were able to focus on the task on the top of the board, and we could be flexible. As product Management experienced that the tasks on the top of the board got done quicker that the others, they began discussing priorities from a company perspective rather than a personal perspective.

The visualisation of work was the first step towards managing the flow of work, rather than managing people to do the work.

 

 

 

 

 

 

Doing Scrum – Leading the way – Learning agile

“I have heard Scrum is ‘the thing’, please google it and implement accordingly!”. This was the exact words from a previous boss of mine, when he wanted me to make our team deliver on time and with the desired quality. This was the beginning of my career in “doing Scrum”.

I have learned quite a few lessons since. In this blogpost I will deal with a few of the hardest challenges I have faced. You will most likely not learn from my mistakes, but being aware of them, may help you overcome them faster when you face them. Continue reading “Doing Scrum – Leading the way – Learning agile”

Need more details!?

Product Owner: “Please code this feature”.
Developer: “I can’t code this, until I receive a better spec”.
PO: “Just go ahead, I want your input to this as well”
Dev: “Alright”
— Developer codes it like he believes is the best, and show it to the Product Owner —
PO: “Why wasn’t _this_ included?”
Dev: “It wasn’t a part of the spec”
PO: “Well, I think it is kind of obvious, and I wanted your input as well”

Continue reading “Need more details!?”

Let’s call off Scrum!

A software development team, had been “doing Scrum” for years, since it was decided that Scrum was the “way to go”. A classic. All meetings were conducted, but gave no or little value. It was just accepted like “that’s what happens when Scrum meets reality”. Failed sprints were the standard, frustrations were building and unfortunate leadership mecanisms were “needed” to get things done.

When I was appointed as the ScrumMaster, I quickly realised that I had to do something drastically to gain the team’s trust to Scrum, and to build the team’s trust in me, as a ScrumMaster. Especially because I do not have a developer background. I had to relaunch Scrum in a way I had never tried before…

So I said: “Let’s call off Scrum!”

Continue reading “Let’s call off Scrum!”