A Scrum Master is an ideal facilitator – she is neutral, has no “position” of her own and is there to help the team reach their goals. Unfortunately, tools and techniques of facilitation are not taught in any Scrum Master course.
Some Scrum Masters asked for some tips, so I thought I would put together a very small, but concise list of resources to help them. I thought I would share them here to help others too.
Please note that all the resources are what I found useful, free and I have no special stake in them.
1. Facilitation Toolkit – University of Wisconsin-Madison: The PDF has all the information and techniques that you need. However, without internalizing and practicing them often, you will not be able to facilitate effectively
2. Role of a Facilitator by mindtools.com: The article has links to other useful techniques in facilitation. All are generally well-written and informative. I learned how to recognize and stop “Groupthink”, especially when you have a strong personality or an expert in the Group, who influences the team to move in a certain direction.
3. Quick Reference guide for Facilitators by Ontario Ministry of Food and Agriculture (gasp!): Examples are cheesy, but the discussion/techniques are useful. Learned about ORID and have been using it as an effective tool in Agile Retrospectives
4. Crucial Conversations book by 4 authors (Book link on Amazon – not an affiliate link): One of the better books out there on becoming an effective communicator. The techniques can be used in facilitation/influencing the tone of the conversations
As I said, the list is very small, but contains enough information for a Scrum Master to use in Agile teams.
Here is a quick tip that I introduced in a Scrum team and found it useful – be careful not to use it on all Scrum teams though!
In Scrum teams that are transitioning to agile after a long history of waterfall, you will team members looking at the Scrum Master or a manager during the standup. This is especially true when you have people from cultures that have an “authority figure” taking reports.
One useful tool for the Scrum Master’s toolbox is to use imagery in the form of a Totem Pole. Designate a place on the wall where you have the standup as the Totem Pole – it can be your whiteboard or a team mascot or even a series of doodles. Team members can then talk about their work (3 questions) and blocking items to “it.”
[Image Credit: Nicholas T]
- Try all possible facilitation techniques for a couple of Sprints before using this, since this only substitutes one authority figure for another
- Add other techniques to help team talk about problems and issues
- Take away the Totem Pole after a couple of Sprints so that it does not become a crutch. However, there is one condition where you can leave it – when it is fun for the team!
This post is a long one, so grab a cup of coffee (or whatever you drink) and make yourself comfortable.
I explore two concepts in this post – how I think Ideas go mainstream with an “inflection point” and my opinion that #NoEstimates is still not at the Inflection Point (and why).
First, let me talk about the Idea Lifecycle. If you look at the sketch below, you will notice that there is an inflection point – a point at which a new idea takes off from being a “fad” to an accepted way of working across applicable industries. Agile, for example, came to an inflection point approximately in 2001-02 and in the last decade has become a stable, accepted framework. A tongue-in-cheek way of determining if the inflection point is reached is to see if a certification is being offered
Of course, there will be improvements and refinements, but the core idea remains the same throughout the life cycle. Also notable are the two points, where the idea dies a natural death (i.e., remains a fad). An interesting observation is that some ideas don’t go mainstream due to limited applicability, but may live on in a limited fan community.
The second, and the main point of this post, is that #NoEstimates is still not at the inflection point, but in the “Discussion” phase. Why? Here are my observations:
1. The majority of IT development is in non-IT industries – industries that use IT as enabler and support, but don’t produce IT products as their business model [Finance, Retail, healthcare etc]
2. Projects in these companies are driven by a cost-oriented Business case – while the Business benefits are imperative, there are 2 questions the Business case has to answer:
a. Will this project make us more money or will it help save money (either top-line or bottom-line has to move)
b. How much will this cost us initially? Regardless of the final cost, an initial costing is needed to gain approval. This initial costing may or may not reflect final cost, but it may cause management to drop the project (Returns are lesser than investment)
c. Sometimes, there is no choice, except to do the project, but in many cases, an estimate is still needed for build vs buy decisions or delaying till the next financial year or doing the bare minimum
3. Assigning a random budget will not work either, since work will always expand to fill and exceed the money allotted (Sridhar’s corollary!)
4. Once the project is authorized and before work starts, managers need to determine how many resources are needed, what type of resources are needed and for how long. With multiple projects in the pipeline, demand vs capacity needs to be tightly managed.
5. Business users expect some idea of when the project will be delivered – a range such as June 2014 or Q3 2014. Note that the final scope may keep changing, but high-level capabilities are known. For example, a CRM system to manage contacts and leads or a fraud management system to detect fraudulent transaction attempts are high-level capabilities
6. With a due date range and high level scope fixed, managers need to know if the features in the roadmap are progressing fast enough or if corrective actions are needed. For example, add some more specialist resources or change expectations of the end users
Unless folks on the #NoEstimates side can address these questions, I think the inflection point cannot be reached. Due to the nature of business in the modern world, expecting management to change and not ask these questions may not be realistic. As I mentioned in an earlier post, developers are accountable not only for the quality of the software delivered but also cost and time (in a reasonable, balanced way). Management dysfunctions such as using inappropriate metrics or unreasonable demands don’t preclude these questions.
Standardization is a word that can evoke different feelings in people, depending on the context used. Here are 2 quotes that seemingly contradict each other:
Civilizations in decline are consistently characterized by a tendency towards standardization and uniformity.” – Arnold Toynbee
International Standards give state of the art specifications for products, services and good practice, helping to make industry more efficient and effective – ISO Charter
A study of literature around this reveals that processes that govern thinking and people’s actions should not be standardized. However, most organizations aim to standardize processes to reduce errors, provide a uniform experience and level the playing field for its employees.
The Drive for standardization occupies a central position in the unstated culture and strategy of an organization. In other words, organizations exist to make itself more efficient by repeatability, thereby aiming to improve certainty.
When Enterprises transition to Agile, they initially aim to deliver fast by cutting through “heavy process frameworks.” But as the number of teams using Agile increases, management finds the differences between teams disconcerting. Self-organization goes against the very culture and this point, a formal team to guide the Organization in its Agile journey takes shape.
Agile Coaches and Scrum Masters start to “define” a standard Agile methodology for all teams, to make sure that consistent principles and techniques are followed. This is the danger zone for the organization.If compliance to defined Agile processes takes precedence over “being agile”, the organization ends up with another “process” replacing the current one. You lose the benefits of moving to Agile in the first place!
No two Agile teams are the same, so comparing velocities and other “metrics” don’t make sense, but the same old red goggles make management fall into the trap of “standardization” when it stifles improvement.
In Enterprise organizations transitioning to Scrum, there are many occasions where people make statements like “We don’t need no stinking Daily Standups. Spirit of Scrum is about being agile, communicating frequently etc”
All good and agreed. It is the next stage in becoming agile. However, for many teams starting out, it important to understand and get into the habit of the mechanics that Scrum provides. After all, they exist for a reason.
If those practices aren’t working for you, look inwards (Golden word: Retrospectives) to determine why and try making changes before throwing the book out of the window. If you wish to substitute an alternate practice, go ahead, but make sure the intent is being met.
In short, don’t fall into the trap of going too fast, especially in a culture-changing systemic process like Agile.