What: Unconference for Agile Coaches, Scrum Masters, Agile Trainers, Leaders, Change Agents and Mentors. When: 7th-8th June 2013 Where: Hotel Ramada, Bangalore Theme: True Essence of Coaching
Role of a Coach?
Many of us have embraced an agile coach’s role, but do we really understand what coaching is all about? How coaching is different from mentoring?
To help us learn about the true essence of coaching, during this Coach Camp, we’ve dedicated one full day to work with Judy van Zon, who is
Planning Poker is certainly a fun and engaging way to do one of the most boring things on earth (STORY POINT ESTIMATION.)
If I’m not wrong, James Grenning originally came up with this idea. And my understanding is that Planning poker can best be explained by using fundamental premise of Wisdom of Crowd (Why the Many Are Smarter Than the Few). Jack Treynor’s Jelly Bean Jar Experiment is a classic example. The average guess of the group is better than the best guess of any individual.
Can we apply this concept to software estimation? May be. But there are a few small difference. In the case of the jelly bean experiment
Everyone in the group is taking their best guess.There isn’t much prior experience or historical data to look at.
There is zero consequences if they go wrong. They will not be held liable to this number.
Also, everyone, more are less, are equally good at the task at hand (counting.)
Now when we talk about applying the same to highly specialized software development where each skill is quite diverse and the involvement of each person is quite varied. What do we get? A complete mess IMHO!
One way to address this issue is to embrace the generalizing specialist approach. If nothing else, in the long run, these folks would become great assets to the company.
But if you don’t want to go down the generalizing specialist route, and you have people in silos with deep pockets of knowledge/skill, can planning poker work? After trying it for 3-4 years, I did not seen it working. But you should certainly give it an honest try. After all, <sarcasm>its the industry best practice.</sarcasm>
The other argument I often hear in favor of planning poker is that when the teams are doing this, they learn so much from each other. I agree 100% to this observation. Certainly getting a group of people together and asking them to estimate (commit) to something, gets them to talk to each other, share their view points and it leads to knowledge sharing. IMHO knowledge sharing is extremely important. Why not have focused meeting for just knowledge sharing? Brown-bag sessions, show-n-tell sessions, code-walk-thrus, idea-fest, scratch your personal itch days, refactoring-fest and many more. Why morph something so important under the estimation/planning meeting banner, where the priorities are different? People don’t go into a planning session saying “Wow, today all of us are going to learn something new.”
Agile Coach Camp is an Unconference for Agile Coaches, Scrum Masters, Agile Trainers, Leaders, Change Agents and Mentors.
We are pleased to invite you
The art of coaching teams toward excellence and productivity is tricky business. We often don’t have direct control over groups but have responsibilities to motivate team members who don’t report to us. Too often, as coaches, we work in isolation from other expert coaches in the field. This is our opportunity to share stories and practices and to wrestle with the direction in which this discipline is going, or should go.
Growing a Community of Practice
Agile Coach Camp is about creating a network of practitioners who are striving to push the limits in guiding software development teams, while staying true to the values and principles at the core of the Agile movement. We’ve invited practitioners who, like you, are passionate about their work, active in the field and willing to share what they’ve learned. It’s a great chance to form relationships that can last a lifetime (and act as a lifeline).
Do you have a technique or practice worth sharing with your peers? Or an idea you’d like to test out with some leaders in the community? Are you facing challenges and want to get some perspective from other practitioners, or hear how they do things? If you feel you would benefit from connecting with 80-100 like-minded peers to talk, draw, argue and explore ideas, then this unconference is for you.
Identifying the right pilot project is an extremely important first step towards your Agile transformation journey.
While selecting a pilot project, I generally look for the following characteristics:
Importance: We don’t want to start with a project, which could shut down your business if things went wild. Nor do we want to pick a small pet project. Even if we proved Agile works well, it won’t appeal to the organization as it won’t be representative nor credible. A critical project with high-enough stakes is ideal.
Dependencies: Fairly self-contained projects with minimum external dependencies are relatively easier for introducing change. If the team does not have the necessary skill or authority to take decision or if most of the project’s attributes are outside the organization’s control, it would be a very difficult pilot project.
Stakeholder Engagement: Access to all the stakeholders is critical. Their involvement and buy-in is extremely important to make any sustainable change.
Top-Management Support: During the transition, the team will run into many roadblocks and challenges. Having a good management support and backing will motivate the team to creatively solve those problems.
Duration: To effectively capitalize on the learning and excitement, it’s important for the pilot project to be between 4-9 months.
Size: A single collocated team with less than 10 members is an ideal size to coach. Gradually we can grow this team to large multi-site geographically distributed team/s.
Stage: If the project was already in a fire-fighting mode, the team members would be under too much pressure to try anything different. If it’s a laid-back large maintenance project, team members might not have the motivation to change large legacy system. Project in its early stages with most of its team members on-board, seems to be a good stage to introduce Agile and Lean thinking.
Team Composition: Most successful organizations have strong (vocal) leaders or connectors at the grass-root level. If we can influence these folks early on, they can be our internal change-agents. Hence while picking a pilot project, we consider their density in the pilot team.
Identifying a project with all these characteristics would be ideal, but is rarely the case. A good coach knows how to make reasonable trade-offs.
How do you measure or know the effectiveness of a Scrum Master?
IMHO on a given team, in less than 6 months, an effective Scrum Master will make:
themselves redundant
process second-nature for the team
That would be the true test for their effectiveness.
In the mean time, I would look for:
Apart from effectively facilitating (not enforcing) the Scrum ceremonies, is the SM helping the team understand the rationale behind those ceremonies?
Is the SM creating a culture of safe-fail experimentation where the team can experiment, learn and grow beyond the standard Scrum ceremonies? If the team is not evolving their practices and work culture, is the SM really doing their job?
Does the SM encourage System’s Thinking and uses techniques like Value Stream Maps, Five Whys, A3, etc. to identify & highlighting bottlenecks in the team?
Has the SM been successful at creating Self-Organized Empowered Team? Or is the team waiting for directions from the SM?
Is the SM able to emerge as a leaders and be the voice of the team, shielding the team from external interferences, yet creating a healthy collaborative culture?
Is the SM able to motivate the team and steer them towards excellence?
Is the SM recording and surfacing important and relevant data about the team’s performance to the team? Basically feeding the team, food for improvement.
Is the SM proactive (instead of reactive) about resolving issues?
Is the SM approachable? Believes in servant-leadership? Extremely knowledgeable about processes? Keen learner and open-minded?
Often companies undervalue the part-time coaching model.
What do I mean by part-time coaching model?
A coach is onsite, working hands-on with the team for a week and then offsite (accessible via email & phone, but off the project) for a week. Basically, the coach is available on-off either alternative weeks or a some other timeframe.
Personally I’ve experience the following advantages of a part-time coaching model:
From the company & its employees’ point of view:
When I’m not there full time, teams realize they cannot fully depend on me. I’m not the bottleneck for making decisions. The teams start to take ownership and make more decisions on their own (usually by consulting me, but not waiting on me.)
When I steps out for sometime and come back to the team, I bring a slightly fresh perspective and can pay attention to weak signals. Many times we get so engrossed in what we are doing, that we might miss out paying attention to something else.
Coaching can be intense. Having a little time off from coaching helps the teams get a breather. Which makes the overall coaching more sustainable.
As coaches we expect things to change much faster rate than usually they do. If we are there full-time, it might start to bother us. But with the on-off model, the slower rate of change seems more acceptable. Similarly the team does not feel pressurized to accept change at a rate that might not be sustainable or acceptable to them.
The management seems to get more confidence in the whole engagement, because they can see things are not blowing up when the coach is not around.
Last but not the least, it does have a good financial incentive for the company.
From the coach’s point of view:
Having some downtime is good for the coach to build/upgrade their skills.
Can help achieve a better work-life balance.
From a risk management point of view, it allows a coach to take on multiple part-time client.
Hopefully, all of this leads to a more effective coaching engagement.
C3: Coverage, Complexity & Churn – Instead of looking at each of these parameters in isolation, we generate C3 graph using a TreeMap and use the cumulative graph to see red spots in the product. Esp. helpful to quickly raise awareness.
Slack: Every team members gets a 10-20% time every iteration to invest on things that hurt them.
Scratch your Personal Itch day: Every iteration each team members gets 1 day to fix unplanned issues on the project
Visitor from Hell: Every month have one person from other team visit you and give you feedback on various aspect of the team. Its up to the team to address these issues or not. But certainly can be used to pitch to the management for additional time to work on these issue.
Code Walk Throughs: Every time a team member (or pair) implements something important, they give a code walk through or a demo to the rest of the team. This usually ensures team members don’t have crappy things when they give a demo.
Check out the project rescue report, if you would like to see some examples of how we’ve used C3.
Invest today in Innovation to ensure you’ll thrive long-term. Else be prepared to get wiped out!
I’m sick and tired of hearing such lame advice from people.
I don’t know of any company where they were struggling. So they “invested” in “innovation” and suddenly started building great products.
It’s like saying:
30-mins of daily Meditation (alone) will make you more creative!
Sorry you need to practice your art to sharpen your creativity. Meditation can certainly help, but not the essential ingredient for creativity.
Important thing to note is, one cannot treat innovation as a separate thing in which they can “invest” to reap benefit downstream.
Thinking of innovation as an independent entity, separate from the work itself and the culture/context in which the work is done, is fundamentally wrong IMHO.
One has to experiment and try new approaches. You cannot do your work the same old way and set some time aside for innovation. I’ve not seen that work.
In my view of the world, innovation is part of how you think and operate. To some extent its the nature of people and organizations. Its part of your work and the culture of your organization. In fact, innovation is inherent aspect of many businesses. One cannot bring innovation from outside. Hence one cannot invest in innovation.
“Invest in Innovation” is like saying “Invest in Learning.”
If you are not learning while doing your daily job and thinking of investing time outside your job to learn, then you are in trouble. Either develop the attitude to learn on the job or find a job where learning is inherent part of your job, not something you do in the side.
If you are learning on the job and want to invest additional time to pick up new skills that’s great. But learning on the job is a pre-requisite.
Innovative thinking should be an integral part of your job and your company’s culture, not something you invest after the fact.
”How do we know if this process is successful? How do we measure if this process is working for us?”
I don’t think any process by itself can make someone successful. A lot depends on the company, its values, principles, nature of business, its people and so on.
If I wanted to introduce a new process into my company, this is what I would measure or look for:
Is it helping my product/organization? Things like
time to market,
frequency of releases,
perceived quality/stability of the product and so on.
Basically aspects about my product delivery which were good (want to continue doing them) and aspects which needs improvement.
Is the team evolving the process? Are they internalizing the process and reducing the amount of ceremony?
While the process should encourage people to do reflective improvement, it should also encourage some amount of disruptive changes thinking into the teams/company.
Is the process creating growth opportunities for my people?
I would like the process to encourage growth in terms of them becoming Generalizing specialists and not being corned into silos.
I want my people to improve their overall understanding and involvement in the overall product development process rather than just knowing or caring about their little piece.
