Agile Killers

Once I've read somewhere that "what killed waterfall can kill agile too". Well, if you have disguised waterfall that you call agile then it definitely can. The problem is that agile or scrum is about mind set. It defines just few artifacts and roles and it's easy to understand. But it's quite hard to implement because it's not that easy to change the way of thinking. Setting up few scrum meetings doesn't mean that you have the scrum. I'll try to explain based on my personal experience what are the bad guys pulling you back toward waterfall in my opinion.
Acceptance criteria
Now you probably think that I'm crazy. How can we write a software without clear AC's? Acceptance criteria is a relict from the old world where it was called user requirements. The almighty buzz word whose main purpose always was, at least in my opinion, to allow somebody to say "We are sorry that you don't like the software but it was done according to your user requirements. You can define other requirements if you still have a budget..." The best buddy of a user requirement is a change request. As a developer, have you ever been in a situation where you thought that something should be little bit different but you were told "do it by the requirements"? Lot of developers have been working in such environment for years and as a result they became coding monkeys. Acceptance criteria in agile environment can be very destructive thing because it kills creativity, discussion and understanding of the product value. And on the other hand it allows people to hide behind their tasks and to blame PO when the result is not so good. They bring false feeling that things are under control and we can use them as a checklist. But this is not very agile, is it?
When the whole team understands what is the value that we're trying to bring it doesn't need precise instructions. They are professionals and definitely very smart people so why not to let them do their best. Instead of acceptance criteria that says what needs to be done it is better to define conditions of satisfaction that say what we expect to happen after something has been implemented. What is the thing that makes the software better and more useful. Every detail can be discussed in the team or with PO anytime. On the sprint review we present what we have to the customer (it doesn't matter if it's an internal one) and we get a feedback which can result in a new story in the backlog... 
Mini waterfall
Mini waterfall can happen at the sprint level or at the user story level. At the sprint level it is usually a result of horizontally sliced stories. The user story should be like a piece of cake. It can be very small but it should have all the layers. If you sliced a cake horizontally, somebody would get the base, somebody the cream and somebody else the fruit. Horizontal slicing of stories brings dependency. For example if you break down a story to smaller stories like backend story - front end story - test story you have three dependent stories that cannot be prioritized, you have nothing until you didn't complete all of them and you have to implement them one by one. 
Mini waterfall at the user story level is quite similar and one of the warning signs that you're doing it is that you have one team member assigned on all tasks of particular user story. Or maybe two where the second is a tester. First the developer is trying to implement all the development work and then the tester is supposed to test it. The result is usually that testers have not much to do in the first half of the sprint and then they're crazy busy. In the better case developers are trying to help them but nobody is really happy and a sprint fail is more likely to happen then success. This leads us to a question what is actually the role of a tester in the dev team? The tester is supposed to be an equal partner of the developer. Actually an another developer that sees the same things but from different angles. They need to collaborate from the whole beginning and his job is to help the developer to write a code which doesn't have bugs and write tests that can prove it. Not to try to find bugs later. If you have an environment where testers are less valuable team members whose job is just to clic screens or break things that 'better' developers created then you'll have waterfall forever and a group of individuals instead of team. 
Metrics and micromanagemet
The worst for last. There is such an old saying in Czech that the fire is a good slave but very bad master. The same applies to metrics. Metrics is something that old school managers love because any guru of management theory once said something like "What can be measured can be controlled". This was probably the beginning of the KPI fetish. What happens when a scrum team is given hard metrics from above? After quite short time the team is focused on these metrics instead of focused on whether we still do a good software. Quite a good example can be the burn-down chart. When I started working as a scrum master I was totally convinced that it is the most important chart in my life. The most important metric in the whole scrum process. And when they put a big screen on the wall and started projecting burn-down charts of particular teams one by one in an infinite loop I was like "Nice!". Now everybody walking by could immediately see which team is doing well and which is not. Perfect idea. But after some time I was wondering how come that despite beautiful b-d chart we had a hard time to deliver the sprint backlog at the end of basically every sprint. The reason was that these charts were burning down hours and people in pursuit of having good looking chart were logging their hours very fairly but they were not encouraged to update the remaining hours that fairly as well. 
Micromanagement comes to play when previously defined hard metrics start failing and the company has managers that changed processes but didn't change their mind set. They are not satisfied by metrics and they start micromanaging them by enforcing funny ideas that are mostly healing the symptoms instead of root causes. For example mandatory set of tasks on stories, mandatory daily reports etc. The whole agile is ruined forever.
1/12/2017

Komentáře

Okomentovat

Populární příspěvky z tohoto blogu

Yesterday's Weather Rule

A legend says that there was a government that spent millions of dollars on a weather prediction satellite. After a big effort and long time they developed a thing that was able to accurately predict the weather with 70% success rate. It was quite good until somebody realized that if they simply said that today's weather will be the same as yesterday's weather they'd also have the accuracy of 70%. The idea is that you can predict what's gonna happen from what already happened. In the scrum process, this principle helps us to avoid overcommitting. The rule says "Don't take more to the next sprint than you delivered in the previous sprint". It can perfectly happen that the team cannot deliver the whole sprint commitment. But it is very important to take appropriate steps in order to keep this problem under control. And applying the yesterday's weather rule is the basic thing that you can do. Just reduce the sprint commitment of the next sprint to the ...
Další informace

Three Levels of ScrumMaster

Scrum defines three roles. ScrumMaster, Product Owner and Development team. While it is easy to understand the PO and dev team role, to understand the ScrumMaster role can be challenging even for ScrumMasters. ScrumMaters are building self-organized teams. But what ScrumMaster does when the team is already self-organized? Let's take a look at a concept of three levels of the ScrumMaster as it it described in the Great ScrumMater: #ScrumMaster Way book. Level #1 - My Team ScrumMaster at this level feels responsibility for his team. The goal is to build self-organized team and to let people embrace the agile mind set. It sounds easier than it is. As a beginner the ScrumMaster can be even struggling with questions like "How can I make myself useful everyday?". But the goal is a long-term activity and the SM should actually suppress the urge to do something, i.e. give advice, propose a solution etc... The first step for SM should be to make himself comfortable in observi...
Další informace

Tribal Culture and Leadership in Agile Environment

The concept of tribal culture in an organization was introduced in the book  Tribal Leadership . It is quite interesting theory and from the agile environment perspective it has a new and important dimension. Let's have a look and put things together.  A tribe is a group of people that have something in common. In an organization trying to set up agile environment, we can easily imagine a scrum team. But we also have the community - a team of teams. Then there are virtual teams like a team of scrum masters, product owners or managers. The whole business groups... We can identify tribes at basically every scale.  A tribal culture is the dominant culture that can be observed in a group of tribes. Or in an organization. The culture can be described as 5 stages. Let's explore these stages and then we will have a look at what it means for us. Stage #1 - Life Sucks A culture of individuals with no hope. Everybody is alone in such culture. This is a culture of prisons a...
Další informace