ScrumMaster's Corner

A state of mind of a Scrum Master is pretty simple. It consists of just 5 states: Observing as the default one, and based on the observation, one of the following can be activated: teaching, facilitation, coaching and removing impediments. It seems to be obvious that the last one is the easiest one. For example the team needs a license for any software so you go to get an approval and buy it. Simple. Before I get to the tricky part I want to emphasise that as an SM you should remove only those that the team cannot remove by itself. It is not unusual that the Scrum Master doesn't understand his own role and in an effort trying to be useful every day he becomes a mother of the team which kills the ability to self-organize.  How the Beast Got Unleashed When I took the challenge to build a scrum team as a dedicated scrum master I was truly convinced that the goal is to deliver a beautiful shiny high performing team with no scratches. That was my definition of success on this missi...

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...

Team development stages were described by Tuckman and his theory is already a classic. I want to have a look on how this theory applies to agile environment. Another theory describes team dysfunctions as a pyramid or layers and finally team toxins are a kind of behavior patterns that can be flying in the air as viruses - harmless to some extend but capable to poison the whole team or organization when the concentration exceeds certain limits. I want to compile these things into something short and understandable.  Stage #1 - Forming  Every team starts as a group of individuals. People are working according to their habits and maintain silos. They're focusing on their speciality and they don't care of others too much. ScrumMaster's main job at this stage is to teach scrum principles, help to see benefits and understand expectations. Stage #2 - Storming As people start working together the artificial harmony of the previous stage disappears. Tension grows and soon or...

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...

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 ...

There are three main things that you need to do in order to make scrum working. You have to create backlog, build a fully cross-functional team and deliver tested software. But this all is still not enough if you don't have a good user story. And from the other end, good user story will bring these values naturally. How do we know that the story is good? Good user stories follow the INVEST model or something similar. Independent Stories have to be as independent as possible. The simple reason is that dependent stories cannot be prioritized. The customers (via the PO) should be always able to say what is more important and what is less. Dependent stories are also smuggling waterfall into scrum as I already mentioned in  Agile Killers .  Negotiable The story describes what the user wants. What is the value to the user. There have to be a space for collaborative discussion between the PO (customer's proxy) and the dev team. Valuable Each story should bring a business...

One of the key aspects of agile is responsibility. This is what you are going to hear on every agile training and read in every article about scrum. And it is true because responsibility is a key to self organization. Despite it sounds like something obvious let's take a look at responsibility process based on how a human brain works as it was  described by Christopher Avery . Human brain has a great ability to make quick decisions and whenever you face any trouble it brings options how to approach it. I'll borrow an example from  Zuzi's book  and I'll try to complete it with my experience. Let's say that you tried to park a car and you scratched the car in a parking lot next to you.  Denial: "Nothing happened" The first and the easiest solution that your brain is going to offer. You are going to be like "The sound was just my imagination and the car was scratched already. It was not me." In a scrum team this can be the famous "It wor...

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 us...

It is quite difficult to identify a portion of work for one day. On the other hand it incredibly and surprisingly simplifies basically everything in the scrum. Let me try to explain... Traditional tasks All of us know them very well. You've got a story to show some data on the screen. It is quite natural to split it into back-end part and front-end part. So far so good. Naturally, you're going to start with back-end. It will need need any DAO, some service, couple of unit tests... The easiest thing that you can do is to create a task with description of "Implement back-end functionality" and estimate it by 3 days. Wait, 4 days would be more reasonable. As a bonus, you have now at least 3 days for saying "I' worked on my task yesterday and I'll continue working on it today" on stand-ups. Life is easy. Even the burn-down chart looks great as long as you log hours. All other members of the dev-team do the same and the ScrumMaster sees a nice chart ...

Are you surprised? Let's take a look at particular scrum meetings... Daily Scrum (Standup Meeting) Everybody knows this guy, right? That's the easiest one where the ScrumMaster asks people one by one what they did yesterday and what they're going to do today. Perhaps because he wants to inspect their work... What if I told you that this is an agile anti-pattern?  The real purpose of the daily scrum is to take a short break and make sure that we're still moving toward the sprint goal and we still believe that we can deliver the sprint goal before the sprint ends. Thus we're not interested in how are people spending their time. Instead we focus on what has been completed and how we're going to collaborate in order to get done what needs to be done.  Sprint Review The next is sprint review meeting where the anti-pattern is to present which particular user story has been finished and which has not. Some teams brought this status to perfection and they had...

Not sure what that means? Self-organized teams are all around. Let's take a look at some examples. Craftsmen Have you ever had a band of craftsmen to do something for you? Let's say you need to build a fence around your property. You got some recommendation from friend and now the guys are here. You will probably give them a kind of user story like "I as the owner of this house want to have a fence all around so that I can keep my dogs on my garden and have better safety".  You will also have some conditions of satisfaction like "I want the fence to be green and about 60 inches high. The fence will keep my dogs inside and foreign people outside". Then you negotiate the price and date when you expect your fence to be done. And that's it. You don't want to tell them that pillars have to be straight, what is the distance between them to make it stable, what kind of concrete they need to use so that first frosts will not destroy it... You don't ...

Shu Ha Ri is a concept of mastering that the Agile community took from Japanese martial arts. The idea is that there are three stages on the way from the beginner to the master and none of them can be skipped. Shu is the initial stage where we learn basics by following instructions of a teacher. It is a drill stage and you are not done until all the practices are a second nature for you. Ha is the second level of mastering. All the techniques are in your muscle memory and you can focus on deep aspects of the fight. In the Ri stage, you're the master. You don't have to learn from others and you are able to create your own rules and concepts. How does this apply to our teams and our goal of successful agile transformation? We just have to go thru all the stages no matter how experienced particular team members are. We are starting from beginning as a team and our stage Shu means to follow scrum principles 'by the book'. We will need written Rules of Engagement and Defi...