1. Adjusting Scrum to organizations instead of adapting the organization to Scrum
2. Adapting Scrum even before it is applied correctly
3. Blaming Scrum for the issues being surfaced (”Scrum does not work because …“)
4. Changing the Scrum process model
5. Changing or omitting the Scrum roles
6. No cross-functional team
7. No self-organization among the team
8. Team is too big
9. Scrum is scaled too early
10. Missing engineering practices
11. Missing management buy-in

I am interested in hearing your thoughts about why Scrum projects can fail.

I wish you a Merry Christmas and a Happy New Year! Thanks to my buddy Christian Schweizer for this amazing light painting. He made this photo with a digital camera, autotimer, long exposure and a pocket lamp. No image editing at all. Again, thanks Christian!

"Scrum" Light Painting by Christian Schweizer

To read more about light painting, click here: http://www.diyphotography.net/painting_with_light

]]> http://www.scrumwanted.com/2009/12/seasons-greetings-to-the-scrum-community/feed/ 0 http://www.scrumwanted.com/2009/12/oh-we-just-call-it-scrum/ http://www.scrumwanted.com/2009/12/oh-we-just-call-it-scrum/#comments Fri, 18 Dec 2009 10:24:29 +0000 admin http://www.scrumwanted.com/?p=209 There is an interesting discussion going on in the Scrum discussion group on XING: The question is why organizations call projects Scrum projects although they seem to have no intention to use Scrum at all. Some people in the discussion suspect this a trend to make projects sound modern and appealing. I absolutely agree and think this is clear evidence of growing Scrum ignorance.

If you like to learn why up-front planning does not work very well and how agile planning works instead, I highly recommend reading Mike Cohn’s “Agile Estimating and Planning“.

Sleeping sheepdog on flickr by alexvalentine, http://www.flickr.com/photos/41006494@N00/379686989)

During his first days on the project, the Scrum Master silently observed the people and their activities on the project. He roamed the floors and worked the phones to connect with all the people working on the project. He learned that 16 people, most of them distributed across several locations (and time zones), had been working on the project for 6 months. He was told that only very little functionality has been delivered with disputable quality. He asked for a project plan and learned that none existed — everything was just in the head of one senior developer who was assigning tasks to developers on a daily basis. Moreover, the business requirements were unknown as the business analysts were still working on the requirements documents. So the senior developer told the developers to implement what he thought was right. When the Scrum Master talked to the developers, he learned that they were not doing any builds or integration tests as the appropriate infrastructure was not available. Instead, all development efforts were done on the machines of the developers.

Soon the Scrum Master felt he had gathered enough information to address the most important issues. So he met with the project sponsors to discuss a couple of issues:

• People distributed across different locations and time zones
• Dependencies on other projects and people outside the project
• No plans, no planning, no shared approach
• No team, no communication, no organization
• Bad quality results
• No value

The project sponsors were not really surprised to hear this, and the Scrum Master felt that they already knew about these issues.  They asked the Scrum Master to address these issues as soon as possible. So the Scrum Master started to introduce some changes… but he wasn’t prepared for what happened next…

to be continued.

Sleeping sheepdog on flickr by alexvalentine, http://www.flickr.com/photos/41006494@N00/379686989)

Once upon in time, a Scrum Master was asked by a large company to help introduce Scrum in one of their most important and strategic projects. The Scrum Master asked for the company’s motivation to use Scrum and was told that a project which was kicked-off 6 months ago wasn’t showing much progress and that the bosses wanted to see results and that the deadline was already looming. So the project sponsors decided to adapt to a more promising approach about which they have heard good things – Scrum. If Scrum was successful, it was planned to apply it to all projects in the department.

The Scrum Master explained that  Scrum is not a silver bullet but – if applied correctly – a great way to help the team improve by helping it focus on the right things, by creating transparency and by doing so surfacing issues which keep the Scrum team from being more productive. The project sponsors liked what they heard and a few days later, the Scrum Master joined the project.

to be continued… part 2

Photo by Flickr user "johnscotthaydon" http://www.flickr.com/photos/johnhaydon/3252135212/

“Scrum does not work and I won’t even give it a try!”
— anonymous ignorant

This collection of all the ignorant statements I have come across since I have been using Scrum should help you reply to similar statements in case you will ever be confronted with them:

• “Scrum does not work because it is not fault-tolerant”
• “Sprint reviews are a waste of time! Let’s skip them!”
• “Daily Scrums are micro-management! Let’s not do this!”
• “Scrum is waterfall because you are working on stories consecutively!”

Photo by Flickr user "johnscotthaydon" http://www.flickr.com/photos/johnhaydon/3252135212/

“Daily Scrum are micro-management! Let’s skip them!”
– anonymous ignorant

I will comment on this very recent statement soon. Meanwhile, feel free to comment on this statement to share your thoughts with me.

]]> http://www.scrumwanted.com/2009/12/daily-scrums-are-micro-management/feed/ 0