Marek Blotny's Blog

There are three simple ways to check if a team is really self-organizing:

1. There are always daily scrums, it doesn’t matter if scrummaster is present or on sick leave, self-organizing teams understand that daily scrums are for them, not for scrummaster
2. Team members voluntarily take tasks and work on them until they are finished. They don’t wait for scrummaster to come and assign something to them. Team knows what are the strong sides of all members, they know who should work on what to be efficient
3. Team members help each other to finish all stories. If each member is working on their own and don’t really care if others are blocked by something, this is not exactly the team work which self-organizing teams should have

Do you know any other quick tests showing if team is self-organizing or not?

Conventionally role of developers in a project was fairly narrow. Project Manager was assigning tasks to developers; they were working on it and when done whole process was repeated for another task. Usually developers where left alone with their task, not bothered by the outer world.

Now, consider how different expectations are for developers in agile teams. Agile methodologies are tailored for cross-functional and self-organizing teams. That means a set of completely new responsibilities:

• Requirements are usually not very detailed so it’s up to a developer to refine them by asking questions and talking with business people.
• There is no PM who is assigning tasks, team should self-organize and take tasks which are available on their own.
• There is no PM who is estimating everything and committing on behalf of team. Developers are involved in estimation process and are asked to make a commitment.
• In cross-functional teams there are no specializations in some narrow aspects of software development or one specific technology. Everyone can pick up any task.
• Developers are not only responsible for coding … they are responsible for getting story/task done.
• Team should be able to reflect and adapt to the situation they are in. Finding the most effective techniques/processes is part of being agile.

That list can be much longer but I think you already see my point here. Developers in agile teams have to take much more responsibility on their shoulders. They are not only focused on coding, focus has been shifted towards communication, interactions with clients and other team members. Developers have to be now effective communicators. Understanding and using business terms is a must. Remaining with technical jargon is simply not an option.

Transition to agile developer can be shocking. Not everyone will be able to cope with this challenge. Some developers simply may lack interpersonal skills necessary for it. Others may not be keen to change their focus and attitude. So what’s the reward for the efforts?

I think agile methodologies give developers a chance to influence the development process, change it into more effective and this way improve quality of their own work. Their ideas matter, their actions can make a difference. Agile make developers empowered to change things and self-organize. I think many people will find such environment stimulating and motivating.

Generally speaking there are known problems and unknown problems. Some people say that unknown problems can be also divided into known-unknown problems (the one which we know that exist but we don’t know anything about them yet) and unknown-unknown problems (we don’t know anything about them and we don’t even expect that they exist)

Good thing about known problems is that you can solve them, workaround them or at least minimize impact which they have. In short – visible problem is a killable problem. Unknown problems on the other hand are hard to predict (especially unknown-unknown category is nasty) and you can be sure of one thing … Murphy’s law will work … they will show up and kick your ass in the worst possible moment.

So whatever you do, you want to expose as many problems as quickly as you can. Agile methodologies place emphasis on interactions and frequent communication with a client. Check how that can help you with uncovering problems …

1. Daily Scrums – prevent people from going dark. Everyday all team members are reporting what they are working on. It’s easily noticeable if someone has stuck with something. Daily scrums make hiding and struggling secretly with a problem very hard.
2. Short iterations and close cooperation with client – if for some reason you are building something different than client wants it’s better to know about it after a first few iterations than after entire development phase. At the beginning of a project you still have time to do something about it. But when you are after development phase, somewhere in the middle of UAT then your options are significantly limited.
3. Retrospective meetings – team is not as efficient as it can be? There are some bottlenecks? There are tools which are slowing team down? Or maybe you are experiencing communication problems? Retrospective meetings is a chance for entire team to meet and for half an hour stop thinking about deadlines, it’s time to focus on what went well and what went not so well and think what team members can do to make following iterations better.
4. Burndown chart and story board – visual representation of progress makes it easier to identify certain problems. For instance if you see that all of user stories are in ‘QA’ state (check attached picture) then you instantly known that something is wrong – there are not enough testers in the team. And finally burndowns … here you can see if your progress is good enough to meet the deadlines. From the very first iteration you can verify if your estimates where more or less correct. If not you still have a time to manage the situation.

I see daily stand-up meetings (“daily scrums”) as a one of the most beneficial practices in SCRUM’s repertory. Theory says that during the daily scrum each team member should answer three well-known questions:

• What did you do yesterday?
• What will you do today?
• Are there any impediments in your way?

Daily scrum is a great example of small things which make great difference. Three simple answers from each team member ensure that entire team is on the same page. It’s clear who is working on what, what will be achieved by the end of day, what problems we have etc.

What I find strange is that theory doesn’t leave much room for any discussion during the daily scrums. Discussions should take place during the follow-up meetings, immediately after the daily scrum. In general I agree with this rule. Bigger issues which don’t require entire team can be talked through later.

But I think it’s much more beneficial for a team if all members are allowed to jump in anytime during the daily scrum to add anything they find helpful. I have seen many scenarios where such impulsive hints work very well. Although scrummaster has a tough task with keeping the discussion under control. On the other hand the worst thing which can happen is when team members are in ‘on hold’ state until it’s their time to speak. That kills spontaneous knowledge sharing and potentially turns daily scrum into a progress report with limited profit for a team.

It’s vital however to keep the meeting under 15 minutes and stay high level. There is not enough time for the team to go into each and every detail. That should happen during the follow-up meetings. Scrummaster responsibility is to ensure that discussions are on reasonable level.

So if you ask me if enforcing so rigid structure of daily scrum make sense. I will answer … definitely not! On one hand you have effective and useful daily scrums which encourage teamwork and on the other quite rigid structure and doing everything by the book. I’m far from saying that traditional approach doesn’t work, but it can be improved, so for me it’s a simple choice.

What’s your view on this? Do you think it makes more sense to follow traditional rigid structure of daily scrums?