7 tips to hire and manage Agile coaches

Large organizations transitioning towards Agile take the first step of hiring Agile coaches.  Many business leaders would be under pressure to hire one as quickly as possible to speed up the process of Agile transformation. Many a times, due to this pressure, they end up making a mistake, hiring a wrong one. 

Based on my past experience working with large organizations and different coaches, I have put together the following 7 points to help business in making good decisions.

1. Try working with 2 or 3 coaches before finalizing one.
2. If you are planning a short term consulting role from a coach, then hire some one who has already built a good credibility as a coach. You may not have enough time to experiment.
3. Ensure to have only one Agile coach on a project.  Having 2 or more could end up wasting time/resources, as two Agile coaches rarely agree, especially if they are from different companies.
4. Ensure, coaches have skin in the game.
5. Ensure that Agile coaches know how to use available tools/technologies rather than just hung up on using Post-It notes.  Let me share my own experience working with one of the best Agile coaches Craig Larman.   While working with Craig, I noticed that, he not only used  Post-it efficiently,   Craig encouraged us to use different tools like  Cling-on sheets, White boards, Flip-charts, Projectors,etc.  Many Agile coaches nowadays don’t think beyond post-it notes.
6. I have observed that newbie-coaches who are on contracting roles tend to buckle up under organizational pressure. They may not push for changes to happen. An Agile coach who fearlessly pushes for transformation is better.
7. If you have hired an Agile coach, then observe the coach during their assignment for few days to understand their areas of strength.
   
   

Top 3 Myths of Agile Development

 

Agile development is an umbrella term for a number of iterative and incremental software development methodologies such as Scrum, Extreme Programming (XP), Lean and Kanban. With agile, all aspects of software development – planning, designing, coding, integrating and testing – are combined in short, frequent iterations.

Agile software development is not a silver bullet, but it has forced many to rethink traditional approaches to software development and apply new ideas and techniques in an effort to build better software faster. As with any significant industry shift, a tremendous amount of fear, uncertainty and doubt generally accompany the transition.

Myth 1: Agile development is undisciplined, cowboy coding.

Fact: Continuous delivery of running, tested software every few weeks could be characterized as the ultimate software industry discipline.

Myth 2: Agile development isn’t predictable.

Fact: Agile teams are constantly planning, prioritizing and delivering against the plan and have a much better sense of where the project actually is and what can be accomplished.

Myth 3: Agile development is just another fad.

Fact: Many industry leaders have embraced and promoted agile. Agile adoption has moved from small co-located teams to large divisions and software organizations of enterprise IT.

What’s Hot: Agile Development

· Teams constantly delivering benefit to the organization every quarter, month, week or even day

· Small, cross-functional teams that communicate and collaborate on an on-going basis

· Planning projects upfront at a high level with detailed planning happening throughout the project to efficiently adapt to change

· Using historical information to plan work incrementally and predict progress

· Quality software is always ready to be delivered

What’s Not: Traditional Software Development

· Teams delivering new features once or twice a year and often missing release dates

· Large teams that meet infrequently and are too big to have meaningful collaboration

· Extensive, up-front planning crammed into the beginning of a project that doesn’t account for inevitable change

· Using speculation to plan all work upfront and “predict” progress

· Passable software is delivered late

Learn about more myths of agile development.

Does a Scrum Master need technical or functional background ?

 

Do you expect your Scrum Master to understand  Java coding standards ?  Should the Scrum Master have a deep understanding of  differences between the four products the customer is building ?

There are people supporting the idea of Scrum Masters with strong knowledge in technology/programming skills. I feel that, knowing a specific subject whether it is technical or functional is never going to hurt. However, in the context of being a Scrum Master, I strongly believe that it is not a mandatory skill.

As long as the Scrum Master appreciates the value of technical practices, and importance of having a good technical debt in the project, one can always take help from a technical/functional coach or expert to implement the practices.  

Fundamentally, I see that following skills are essential to succeed as a Scrum Master

1. Ability to identify the technical or functional experts within the team (or the lack of)
2. Finding ways to get the help for the team
3. Skill to remove the impediments/blockers
4. Appreciate the value of good technical practices
5. Asking the right set of questions to get the answers
6. Empowering the teams to succeed and build self organizing teams

Let us take a look at an example. Consider a scenario where in a developer shares a blocker saying
                                               The message to TIBCO server is failing.

The Scrum Master(SM) need not know how to fix TIBCO server issue. As long as SM asks the right questions, the impediments could be removed and one could succeed in any project.

A SM could ask following questions in the context of above TIBCO server issue (not in any specific order)
1. Is this a new one or the one occurred in the past ?
2. Who are the TIBCO skilled experts in the team to be invited to investigate this issue ?
3. Do you really think it is TIBCO server issue or something else ?
4. What is the criticality of the issue and who should be informed ?
5. What is the fall back plan ?
6. What is the impact of this issue on delivery timelines ?
and few more questions…

In the end, the SM could do a retro (if it is major issue), and apply 5 Whys to identify the root cause.