No matter what process you try to implement there is always one constant... "Naysayers"... What is a naysayer?
One who frequently engages in excessive complaining, negative banter and/or a genuinely poor and downbeat attitude. ... They have the capacity to rant and whine for hours on end about the most insignificant inconveniences.
- Urban Dictionary (http://www.urbandictionary.com/define.php?term=naysayer)
We've all heard the complaints and they generally follow a common theme:
This process won't work for "our" kind of work.
This is a common misunderstanding. Aside from Scrum largely being a development process it is not prescriptive with respect to the type of work being undertaken. This process can be applied to graphic design work, engineering work, testing, product releases, defect resolution, etc. The process makes no mention of any one technology stack, operating system, application type, style of development (e.g. peer-programming or individual developer), etc...
This kind of task can't be estimated.
This is another common misunderstanding. Scrum does not require an "estimate", but it does require you project a time-box around everything you are setting out to accomplish (e.g. the commitment). This helps manage momentum and prevent failures from spinning out of control. More importantly, this helps prevent things from going unseen by those that have to manage the project and manage customer expectations. Essentially, you set out to accomplish something over a given period of time, then come back together at the end and reassess. Scrum is an iterative process and repeats as many times as needed to deliver the required results.
There is too much paperwork. I'm a developer, not a tech writer.
There are two problems with this... First, Scrum is a very lightweight process with respect to artifacts and has no specific requirements surrounding the fidelity of artifacts. If you have really complicated or overly detailed artifacts you can't blame the process, blame yourselves or your company. I have witnessed many shops managing their work with a wall of sticky notes and that's as simple as documentation gets. Second, developers who think they never have to write anything down are kidding themselves. Putting the obvious design and requirements artifacts aside, in the real world businesses need to be able to capture certain aspects of product development in writing to protect and maintain their investments.
This process slows us down. We could work faster without it.
I love this one. This is the notion that if the management teams would just leave the developers alone, developers would be more efficient. Truth is, working in total isolation seldom leads to any real success. Putting that aside, the Scrum process demands very little from its participants in terms of time. Besides the daily stand-up meeting; which is only 15 minutes long; the only required meetings are the Planning Session, Demo/Review, and Retrospective, and these only occur about once a month. I can't think of too many professions that can really claim so few meetings. Heck, I had more meetings in a week working as a kitchen slave in France.
There are plenty of others, but you get the point. So when this happens what can you do? Unfortunately, there is no "one" answer but there are a number of patterns that can go a long ways to helping:
- Be consistent
- Once the team has decided on how it will implement its process, do not allow deviation. Do not sacrifice schedules or milestones. The team will need time to settle in and see the forest through the trees. In the mean time, you need to keep them on track... even if it hurts. Use the retrospectives at the end of each Sprint to introduce changes over time
- Be pedantic
- Don't sacrifice the details. This may not make you any friends but you have to be the details police. Avoiding this creates a slippery slope and before you know it, no one will be following the process
- Get unequivocal support from the management team
- Although this can be tough for some, you can only be successful if your management team is totally committed. They need to be stead-fast in their commitment to those charged with implementing the process. If there are concerns, take it offline, and do not argue in front of the team
- Let them make the process their own, but don't compromise on the tenets
- Every team has their own quirks, and may have ideas that will work very well for them. Assuming these ideas do not sacrifice the basic process tenets, let them choose their own details. If they feel a sense of ownership, adoption will be much easier. With that said, they need to understand that these ideas will be subject to all the aforementioned points
Well, thats it... Hope this helps.