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?

I have been watching Cory Foy’s presentation yesterday. The presentation was about ‘Growing and Fostering Software Craftsmanship‘ but for me the most striking part was when Cory was talking about knowledge sharing and about Bus Number. Bus Number Wikipedia defines in a following way:

Bus Number is the number of developers on a project who could be removed before understanding of a particular part, or all of the codebase would suffer severely. The term refers to the fact that if these developers were unable to work on, or consult for, a project it would be difficult (or impossible) for new developers to pick up where they left off. In other words, if the developers were hit by the proverbial bus, the project would be in jeopardy.

So it’s pretty much clear that we want Bus Number to be as high as possible. We don’t want to see our projects to be so vulnerable. With low Bus Factor one unexpected event can lead to serious problems.

And here comes the most interesting part, Cory claims that in most organisations this factor equals exactly one! Think about it for a second … it means that entire project is in trouble with one person taking a new job, having a health problems or being hit by a bus. How bad is that?

Another point made by Cory – most organisations are not promoting knowledge sharing. Rewards and fame go to the people who know how to rescue projects, who are able to deal with complex projects, difficult clients. Knowledge sharing is not that high on the list, as a side-effect people don’t pay much attention to it.

I think usually people will agree that knowledge sharing is an important thing, but in the same time people tend to focus more on urgent things rather than important. As a consequence typical ways to share knowledge like code reviews, pair programming don’t happen very often.

What is the Bus Number in your organisation? How do you ensure knowledge sharing? Who should be the most interested in increasing Bus Number within a team? (PM? Tech Lead? or maybe someone else?)

Yesterday I was on an interesting call with a client. Project for this client is on hold for a while now. At the beginning it was a project like any other, but after one or two sprints a list of blocked user stories started to grow really fast. After the second sprint it was already clear for us that decent cooperation of both sides is a must if we want to have a chance to meet the deadlines. We were very clear about that with the client. Unfortunately client didn’t have time to work with us so we decided to stop entire project, people were moved to the other projects and basically we were waiting for the client to come back to us and unblock further development.

That was the situation until yesterdays call when the client promised to remove all blockers and asked us to immediately restart the project. Our answer was that of course we are happy to restart the project but we need x weeks to get developers back from other projects. Therefore immediate restart is not possible.

The point which I want to make here is that this example illustrates well healthy balance of powers between the development team and the client. At the beginning of the project we have committed to deliver before the certain deadline but it doesn’t mean that entire responsibility is on our side. We have an obligation to finish our work within agreed timeframe but in the same time client has an obligation to support development team and find time to answer questions. When client is neglecting his/her part of the deal then we have a right to stop the project.

On the other hand when client is asking for project restart (s)he can’t expect that it will happen immediately. We are partners therefore client has to accept that it’s not our fault that project is on hold and we need time to assemble the team back.

It might be obvious for many people but I have also met number of people who have only one answer to client’s requests: “sure, no problem”. Answering always like this is risky because it goes against the balance and suggests to the client that we are not partners.

Adopting agile methodologies doesn’t guarantee success of each and every project. Sometimes you can have absolutely great team, skilled and well motivated people, flawless development process and yet project can be a total disaster.

How can that be? Prerequisite for all projects is a product backlog (requirements specification). If user stories (requirements) are vague and scope is blurry then probably this is classic garbage in, garbage out scenario. In such scenario a single team with no external dependencies and good cooperation with a client has a slim chance to succeed. But in projects, with number of different teams involved, there is absolutely no way to produce something else then garbage.

How to avoid garbage in, garbage out scenario? Before giving a green light for a project ask yourself a few questions:

1. Are requirements documented? – you don’t need each and every small detail, but high-level user stories are a must.
2. Are requirements clear and explicit? – requirements should be put in simple words without any ‘marketing talk’ but also without technical details.
3. Is scope for your team well defined? – this is about clear responsibility boundaries. You want to know what your team is supposed to do; also you want to know which team should help you with your external dependencies.
4. Do you understand goals for a project? – what is a business justification for this project? What client wants to achieve?
5. Do you understand the most fundamental user stories (use cases) of a system? – do you understand how system should work? How complex the features are? How many internal/external systems will be involved in building each feature? For each feature – what are the responsibilities for your team?
6. Do you have access to the product owner/client/stakeholders to be able to ask questions? – For sure you will have some questions, you will find some edge cases therefore you want to have access to someone who can make some decisions and conclusively answer questions.

If answer to at least one of the above questions is ‘no’ then you have to be careful because quality of project’s specification is substandard. Of course you still may want to take a chance but be aware – it’s a risky game.

There are scenarios where story points can be very handy and using them is beneficial. But before I move to that, one thing has to be clear:

Like it was stated in my previous post “all that business care are man-days and how many is needed to get things done”.

So it’s essential to establish mapping between story points and time, something like this:

1 SP = less then 4h
2 SP = 4 hours to 1 day
3 SP = 1 to 2 days
5 SP = 2 to 4 days
8 SP = 4 to 8 days

It’s important to remember that points are estimates so mapping story point to a single integer is like chasing rainbows. Estimates should be represented by ranges and the same goes for story points.

As a result of this approach engineering team should be able to say for instance that they need 10 to 20 weeks to deliver a project.

Of course at this point range is quite wide. There are a few options to do something about it:

• use historical data for similar projects to compare estimates and the actual time which was needed.
• ask experienced members for an opinion – they might tell you straight away that there is no chance to deliver in 10 weeks.
• simply assume that optimistic scenario (10 weeks) is not very likely

The best part is that after each sprint you will be able to predict more accurately how much more time your team needs to deliver. Even after first 2-3 sprints you should be able to say if you are close to optimistic scenario (10 weeks) or pessimistic (20 weeks).

Story points are about relative size of work

In one of the comments under Mike Cohn’s post I have found great example for usefulness of story points:

One of the most compelling reasons to prefer story points even though it is another way of estimating effort is because it allows individuals of different skills to discuss the relative size of work. My favorite example is of two runners at the start of a trail–one says it will take 5 minutes to run, the other says 10 minutes. Both are right. Those are the amounts of time it will take each to run. There is no time-based argument they can have to settle on the “right number.” However, both can agree that some other trail is twice as long—one runner will be thinking “Yep, 20 minutes” and the other will be thinking “Yep, 10 minutes.” But both can agree “twice as long.”

Using story points to estimate enforces team members to focus on discussing relative size of stories. They just need to define some reference story (for instance worth 2 story points) and other stories compare to it. This way team members don’t wast time arguing about exact number of hours. Story points are not so fain-grained. For mature teams this approach should be much more efficient then estimating directly in hours/days.

One final thought … it’s probably good idea to use story points to estimate user stories but be aware that people might have very different view on what story points represent. Make sure that all members of your team understand story points in the same way.

Concept of story points was always slightly confusing for me so I wasn’t that surprised after reading Mike Cohn’s blog post and comments that definition of story points can vary widely between different people, here a few examples:

• SP should be based on the complexity
• SP is a measure of complexity, effort, and doubt
• SP is a way to measure the size of the requirement, not the time it takes to implement the requirement
• SP are not about the complexity of developing a feature; they are about the effort required to develop a feature
• SP are “size points” and map to time retroactively
• SP do not *equal* hours because points are an estimate
• SP are an estimate of effort (“how much time will this story take?”)

It’s strange that concept which is part of agile planning and estimating for so long can be so confusing and can be understood in so many (sometimes even contradictory) ways.

Maybe definition of story points should be agreed within each team separately? In a similar way as it should be done with definition of ‘Done’ for user stories? Then for one team story point means X and for other team Y?

Personally I don’t think it’s a way to go. Ultimately after planning session we, as a engineering team, are suppose to answer one fundamental question: how much time we need to deliver the project. Therefore it doesn’t matter if you estimate in story points, ideal days, ideal hours or something else. Final outcome has to be in man-days.

If all that business care are man-days and how many is needed to get things done than maybe there is absolutely no point in using story points? Story points are confusing. Maybe we should estimate in man-days and get rid of this additional level of abstraction? I will try to answer that in my next post …