When organisations decide to adopt agile practices the very first point of failure is a clear understanding of language from the top down. When language and intent of language is understood, "yeabuts and whatifs" are minimized.
A Scrum Masters Perspective of Adoption Aversion
Here is a list of Agile Adoption Best Practices to consider;
- Agile is not a method, framework or life cycle - AGILE is a way of "BEING"
- Manifesto - Declaration of intent - the Manifesto consists of 2 elements - VALUES and PRINCIPLES
- Values - a set of long lasting beliefs
- Principles - "the rules"
- Method - "a structured, tried tested and true set of instructions to accomplish a set of tasks.
Thinking about Scrum consider this - there are 3 pillars upon which this light weigh project management METHOD rests.
Scrum Principles - "The rules"
Scrum Aspects - "elements of Scrum to consider"
Scrum Phases & Processes - "The Method"
Principles are non-negotiable and must not be considered as constraints. Every decision we make should be leaned up against the principles and if the principles are to bend or break we must ask ourselves "Are we truly being agile?"
Principles are the disciple of scrum. Consider Empirical Process Control and its elements of transparency, inspection and adaptation. When combined with Time-boxing - what we are asking of the team is at regular time-boxed intervals the elements of transparency, inspection and adaptation, must be achieved.
The second tenant of the Scrum Light Weight Project Management method are the aspects. Aspects are NOT iron clad! You and your teams are free to do with them what you want - provided they do not impose upon the principles.
Perhaps the most popular questions I get when I introduce teams to the Aspects are;
Where is the BA, where is the PM?
Should a BA be a product owner?
How can my PM be the Scrum Master?
Can we combine the role of BA and PM?
The answer hands down is "Absolutely why not" followed by my question;
Will your decision contradict any of the principles?
For example: "Will appointing a project manager prevent teams from being self organizing?"
Another Example - "will implementing your own quality control practices inhibit Iterative Development?"
The final tenant of SCRUM are Phases and Processes, again you are free to do with them what you want, shrink em' or expand em' - I promise there are no scrum police that will arrest you for doing otherwise. Before you go changing the processes and phases, once again ask yourself - will our changes contradict the Scrum Principles?
Scrum Phases & Processes
You may be surprised to know that where phases and processes are concerned there are the fewest "Yeahbuts and Whatifs". Perhaps customers are looking for the structure, the tick boxes and and step by step approach to working better. This concerns me.
Not unlike the aspects Phases and Process to can be massaged in a manner that best reflects an organizations practice. If this is the case - once again I'm going to remind you I'm cool with this, provided you don't bend the principles.
Scrum is a light weight project management method, it was designed specifically to be light weight, to do just enough to get high quality, high value products and services to our stakeholders.
Asking "yeahbut" and "whatif" should be asked not about aspects, phases and processes, but about how you can work more pragmatically...
"Whatif "we found a more efficient way to engage stakeholders..."yeahbut" would it affect our principles?