Apart from a different scale, is it much different than to adopt Scrum in a small sized company? I tend to think the same organizational and systemic dynamics come into play: company culture, senior management support, communication channels, work environment etc.

Is it the scale of everything and how deep the company culture is rooted that might make things a lot tougher?

What do you think? Can Scrum survive in the world of fixed scope and date, top-down management, lengthy weekly email reports with hundreds of recipients in CC, big bang releases with multi-million € Marketing campaigns?

I would love to read your comments on that one!

Update: Point 1 from this comment pretty much nails my thoughts on Agile in the Enterprise. It can’t work if the leaders don’t change.

This time, I guess you got that, we talked about the data teams’ Sprint Burndowns should be based on. Should teams have their Sprint Burndown based on Story Points or on the sum of all remaining estimated tasks in hours?

To answer this question, it’s important to understand what the goal/role of a Sprint Burndown is. The Sprint Burndown is a tool that:

* shows the team’s progress of a running Sprint
* indicates the team’s performance during the Sprint
* should show whether a team is on a good way to meet its commitment or not
* shows where blocks in the development process may happen 

Let’s do a small comparison of 2 approaches…

1. Sprint burndown based on story points

* doesn’t require the team to estimate tasks
* might be considered as less overhead by the team
* may not explicitely show bottlenecks in the development process
* may have the tendency to create burndowns like this

2. Sprint burndown based on time

* requires initial tasks to be created and estimated at Sprint start
* may put negative pressure on the team by introducing another level of estimations (and measuring against these estimates)
* may be considered as too much overhead by the team
* may show bottlenecks/blocks more explicitely than with Story Points
* will have the tendency to create burndowns like this

In summary, the purpose alone of the Burndown should already give a good idea in which direction to go. The team/company’s culture and how deep you are in your implementation of Scrum may be 2 other aspects to take into account when making that decision.

Now Jeff Sutherland recently wrote “The best teams I work with burn down story points. They only burn down when a story is done.” (Source) - Are you there yet?

“For user story X, the team correctly identified that the work was at the database level. But when doing the actual estimation, they stepped back and left the expert database developer do the estimate. When the DB developer spoke out, I got some signals from the rest of the team that the estimation might have been inflated – still none of them said anything.”

I see 2 problems here:

1. Why isn’t the entire team estimating the user story *together*, even though it only involves DB work?
2. Why is the DB developer inflating the estimation?

In my experience, developers – as basic example – are not willing to estimate anything that isn’t related to their code, is a common pattern in teams starting Scrum. “How can I provide an accurate estimate in a field I am no expert in?” How have I solved it? Usually I try to insist on the fact that there are no *right* estimates and that the goal of all this is to generate a discussion that will help everyone to have a better idea of what the deliverables of a user story are. Estimates are not written in stone!

Inflating estimates is a little trickier… In this case, I know that the DB developer is actually part of another team which means he may already be overloaded with work from this other team. Inflating to avoid the burnout? Why not… How would I solve this? First thing that comes to my mind is to try to hire, which may not be solving the root cause. If that is not possible, I would suggest the team to inform themselves on the subject matter to become less dependent. Writing SQL queries is surely no rocket science when you can do .NET!

Questions to other Scrum or Agile practitioners: Did you encounter similar scenarios and how did you handle them? If not, how would you handle them if you did? Share your experience with us!