Agile Zone is brought to you in partnership with:

I'm a software developer working as a senior consultant at Kentor in Stockholm, Sweden. My core competence is as a technical specialist within development and system architecture. In my heart I am, and probably will remain, a programmer. I still think programming is tremendously fun, more than 20 years after I first tried it. That's why my blog is named Passion for Coding.  Anders is a DZone MVB and is not an employee of DZone and has posted 86 posts at DZone. You can read more from them at their website. View Full User Profile

Scrum – Nowhere to Hide

  • submit to reddit
Scrum as a methodology is very transparent, everything is done in open sunlight where everyone can view. Following the spirit of scrum, everything is open for all stake holders to watch.

  • The requirements must be detailed before the sprint planning, the team can reject a product backlog item that is not complete.
  • The developers have to give an official time estimate on each work item.
  • The sprint burndown chart that shows the progress of the current sprint should be on the wall, next to the developers’ work space.
  • The daily standup should be open to any stake holder that wants to join and listen.
  • The result of the sprint is shown in public, by the developers themselves.

The high degree of transparency effectively means that nobody in a Scrum project can hide. Successes are shown, but also failures. I think that it is good with the transparency. It ensures that problems are found and handled early.

Product Owner on Display

The product owner is in charge of the product backlog. The product backlog is the foundation of the sprint planning meeting. If the product owner hasn’t done the preparations right, it is glaringly obvious at the sprint planning meeting when the developers start asking questions about the tasks at hand. In the consultancy business where I work, one or more representatives for the customer take the role of product owner.

The customer representatives often try to push the team to keep a tight dead line for the release. Unfortunately the dead line date is sometimes just about the only thing that is clear to the customer. The objectives of the projects, user stories and detailed requirements can be quite vague. Guess if it is possible to develop anything at all if the customer can’t tell what should be done?

This is where the transparency of scrum can help identify the problem. Without scrum, low quality requirements results in a mess in the development phase. With scrum, the product owner has to clearly show what should be done before the sprint, otherwise that particular task is postponed to the next sprint. There is no “almost finished detailing requirements” accepted. Either the product backlog item is properly described at the sprint planning meeting or it isn’t. If it isn’t it can’t be included in the sprint.

This is one of the reasons that I, as a developer, love scrum. It gives the developers the possibility to reject unclear requirements. Without that possibility the unclear requirements are used for development anyway and when the useless result is presented the developers are blamed.

Developers’ Time Estimation on Display

The worst question for most software developers is to be required to Estimating Times. When being new to Scrum that is probably the most scary part; to have to officially estimate time.

There is one highly mitigating factor though for time estimation in scrum projects. The developers that will do the work are the ones estimating the time. There is no manager with an unrealistic schedule pushing an estimate onto the team. The team has the freedom to make an estimation they believe in. With freedom follows responsibility. The team is held responsible for their estimates.

Developers’ Progress on Display

During the sprint, the progress is tracked by a sprint burndown chart. There are also daily standup meetings where each developer describes what was done yesterday, what is today’s agenda and if there are any impediments. The visible burndown makes it impossible to hide lost momentum. It is immediately visible to anyone watching.

That’s great, because one of the worst and also most common pitfalls for projects is when people start sliding on the truth in progress reports to make it look like the plan is followed. When the lies are revealed it is often to late to get back to the plan. With scrum, any delay is immediately visible and actions can be taken.

Developers’ Results on Display

At the end of the sprint, the developers get to show what they have accomplished. In person. In front of the customer. In my experience this is one of the most important parts of scrum. It establishes a relation and understanding between the developers and the customer. As humans, we tend to only make an extra effort if it is for someone we know. With a direct relation to the customer, the developers make that extra effort. Believe me, that extra effort can make the whole difference between a failed and greatly successful project.

Nowhere to Hide

Scrum is not for those who want to keep what they do to themselves. To the contrary, many of the habits of scrum aim to increase transparency. Thanks to the transparency everyone involved knows what’s happening. When everyone knows, everyone can help out if there is a problem in any part of the project.

Published at DZone with permission of Anders Abel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Bob Rukket replied on Thu, 2013/02/21 - 3:02pm

"Scrum as a methodology is very transparent, everything is done in open sunlight where everyone can view. Following the spirit of scrum, everything is open for all stake holders to watch."

Pray, Pray, Pray!!

But what the hell is scrum really? A methodology. Ok. But for what. Project Management? A little. Developement? A little? What is the scope, exactly the purpose? Is it the hammer for everything? What is in, what is not in?

I am a rather dissappointed of scrum. When all people are perfect an pray, scrum is perfect, otherwise the people are not. Projects, people and IT are complex. Scrum is simple. A contradiction?

After years in IT projects and seeing rather good people applying this "transparent, open, ... methodolgy" in the real world, I must say, that scrum is no better. Scrum says little about architecture, planning, risk management, quality management, test management (e.g. stages, roles, responsibilities), etc. But of course, you can put everything you need in your definition of done. Wow.

Finally a few things I like about Scrum: Scrum is good for the communication within the developer team and it's also best when the team itself makes a few thoughts about quality aspects and its definition of done.

But it's really annoying to confuse attitude with knowledge and facts.

Anders Abel replied on Fri, 2013/02/22 - 2:45am in response to: Bob Rukket


I mostly agree with your comments. While I do like scrum, it is no silver bullet. As you say, scrum is a great methodology for the team, but it lacks processes for almost everything beyond the team. Those issues, like planning, risk management etc. can't be ignored.

As scrum doesn't address those issues, something else is needed. I advocate that scrum is combined with a project governance model to address those other issues. I actually wrote a post in the same series as this one about governance: Scrum and Project Governance.

Lund Wolfe replied on Sat, 2013/02/23 - 8:12pm

Scrum is a management process or methodology.  It doesn't guarantee anything.  It forces transparency and communication so it becomes glaringly obvious to all when the project is failing or not going as well as expected.

Once it has been determined that the project has technical issues, those issues will have to be identified and addressed before the project resumes its steady pace.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.