Tag Archives: mistakes

9 Common Mistakes in Hiring an Agile Coach

Learn more about transforming people, process and culture with the Real Agility Program

Nearly everyone is hanging out the “Agile Coach” shingle.  Agile has reached the point where many large organizations are adopting Agile practices.  As a result, consultants and consulting companies are trying to jump on the bandwagon to take advantage of this fad.  Unfortunately, we at BERTEIG are often being called in to clean up after other Agile coaches have made a mess of things.

Here are the most common mistakes that organizations make when hiring Agile coaches.

1. Not Measuring the Results of Your Agile Coach

Agile coaches should be able to measure their results as they work with your teams and your organization. Important measures include performance, cost, quality, time to market, customer satisfaction and others.  If you aren’t measuring results, you can’t possibly know if the money you are investing into your Agile coach is worth it.  Of course, some qualitative measures such as staff satisfaction with the coach are useful too, but quantitative measures are also essential.

2. Not Benchmarking before an Agile Coach Starts

You need to be able to know if an agile coach is making a difference. Knowing where you are starting is necessary.  Having benchmark measurements of important KPI’s will help you to make sure that your agile coach is successful.  Benchmarking is something that your agile coach should be able to help you with, but make sure that you are involved directly!

3. The Agile Coach is Lacking Advanced Certifications

Agile coaches need to have proven their knowledge and experience by obtaining advanced certifications. A “Certified Scrum Master” designation is just not sufficient. At a bare minimum a Certified Scrum Professional (CSP) or Kanban Management Professional (KMP) certification are critical. However more advanced certification’s such as Certified Enterprise Coach (CEC), Kanban Coaching Professional (KCP), or even non-Agile coaching certifications such as Leadership Circle Profile are important to see in a candidate.

4. Lack of Diversity of Agile Experience

An Agile coach must be able to prove having worked with at least Scrum and Kanban methods on more than one team in more than one organization.  However, there are many other Agile methods and techniques, and it is critical to explore the depth of your candidate’s knowledge and experience with those techniques.  Do they know how to do the Agile engineering practices?  Have they used many different retrospective techniques?  What about Innovation Games?  Estimation and planning tools?  If your coach has less than five years of experience with Agile techniques, chances are they don’t have the depth to deal with the complexity of your situation.

5. No Huge Agile Coaching Failures

An Agile coach needs to be able to explain how they have failed to achieve results in at least one case, ideally getting fired as a result. Failure and learning from failure are critical parts of the Agile framework. If an Agile coach can not share with you a significant failure then you cannot trust that they are able to learn from their mistakes.

6. No Systematic Agile Coaching Approach

Helping teams, groups and organizations become more Agile requires systems thinking and systematic approaches.  Organizations are complex (and sometimes chaotic!) – if an Agile Coach does not know how to deal with this complexity, and cannot describe to you their systematic approach, then they probably aren’t going to be consistent in their results.  And if the approach they describe doesn’t seem to make sense to you, you are probably right to give that coach a pass.

7. Missing Clear Agile Coaching Goals

This mistake is a little less common, but it is important enough that it still needs to be mentioned: your organization absolutely must have clear goals for the Agile coaching.  Those goals should be related to both Agility and business results.  Agile techniques are a means to an end.  Lacking clear goals often results in an organization spending far more than it needs to on Agile coaching.

8. Hiring an Agile Coach to do Training

(Or the other way around.)  Coaching and training are two completely separate disciplines!  It is rare to find an individual who is able to do both well.  The systems and techniques of coaching are different than those of training.  Becoming excellent at one, takes many years of focused work.  Becoming excellent at both, takes deep commitment and opportunity.  If you hire an Agile Coach who has good experience, don’t just assume that they can do training just because they have delivered a few talks or made up a slide deck.  Put the same discipline into hiring an Agile trainer that you would put into hiring an Agile coach.

9. Not Letting Leaders and the Agile Coach Work Together

This is probably one of the biggest mistakes of all!  An Agile coach must work with your organization’s leaders to have any hope of helping you with lasting change.  No matter how large your organization, the culture is set by leadership, Agile has a huge cultural impact, and your Agile coach needs to be able to link the two together (leaders and Agile culture).  Even if the Agile coach is “just” working at the team level, a lack of contact with leaders will make the coaching work inefficient, frustrating, and unsustainable.


Your organization deserves the best chance it can have.  Consider contacting us at BERTEIG to help you make sure your Agile coach (or Agile coach candidate) is up to the challenge.   We have a systematic program to develop Agile coaches.

BESTEIG Real Agility logo - Agile Coach development program


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Sometimes I Just Need to be Pedantic

Learn more about transforming people, process and culture with the Real Agility Program

Here’s an article that just drives me nuts: Using Agile Scrum to Manage Developer Teams. The problem I have with this article is that it is just crazy bad in its use of language and ignorance about the fundamentals.  Here are some examples:

Agile Scrum

This is not a thing.  Agile is a philosophy of doing software development.  Scrum is a particular instance of Agile.  Saying “Agile Scrum” is kind of like always saying “furniture table” instead of just “table”.  It shows a pretty fundamental gap in the writer’s knowledge.

As with any software development lifecycle (SDLC) framework…

Scrum is definitely not an SDLC.  Scrum is a framework (and the author uses the term correctly a little earlier in the article) but is deliberately missing most of the details that would make it an SDLC.  It is designed to be incomplete instead of complete.  SDLC’s are meant to be complete solutions for delivering software.  Scrum shows you the gaps and exposes the problems you have delivering products but doesn’t tell you how to fill in the gaps and solve the problems.

Next, the article mis-quotes Scrum.org by incorrectly capitalizing Product Owner and Scrum Master.  And in some sort of ironic error, puts “Scrum master” in quotes.  Yikes!

The conclusion of the article about when you might choose not to use Scrum is also a bit mis-guided.  There are lots of organizations successfully using Scrum in highly regulated environments: medical, banking, government, etc.  Some of them are even my clients!  I would be happy to provide direct references if needed.

Finally:

Does your team work remotely? Despite advances in video technology and online collaboration tools, the requirements for structured daily contact makes Agile Scrum tough to implement successfully for virtual teams.

Yes, remote work is bad with Scrum.  But it’s also just plain bad.  Don’t do it if you can avoid it.  All that Scrum does with a remote team is show you just how bad it really is.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

24 Common Scrum Pitfalls Summarized

Learn more about transforming people, process and culture with the Real Agility Program

Scrum is the most popular agile method… if you count all of the teams doing “Scrum Butt”.  Doing Scrum really well is much harder and much rarer.  Here is a list of 24 common Scrum pitfalls or bad behaviours of Scrum teams:

  1. Excessive Preparation/Planning: Regular big up-front planning is not necessary with Scrum.  Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans.  Even the Product Backlog can be created after the first Sprint has started.  Read more about the Excessive Preparation  Scrum Pitfall here.
  2. Focus On Tools: Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well!  Use manual and paper-based tracking for early Scrum use since it is easiest to get started.  Finding a tool is usually just an obstacle to getting started.  (And besides, check out what the Agile Manifesto says about tools.)  Read more about the Focus On Tools Scrum Pitfall here.
  3. Problem-Solving in the Daily Scrum: The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised.  Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested.  The ScrumMaster facilitates this meeting to keep it on track.  Read more about the Problem-Solving in the Daily Scrum pitfall here.
  4. Assigning Tasks: Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should assign tasks to team members.  It is better to wait for someone to step up than to “take over” and assign a task.  Read more about the Assigning Tasks pitfall here.
  5. Failed Sprint Restart: Although cancelling a Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting.  Teams should immediately re-start after cancelling a Sprint.  Read more about failing to re-start a cancelled Sprint here.
  6. ScrumMaster As Contributor: The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle.  Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions.  Read more about the problems of having a ScrumMaster as contributor here.
  7. Product Owner Doesn’t Show: The Product Owner is a full member of the team and should be present at all Scrum meetings (Planning, Review and Daily Scrums).  As well, the Product Owner should also be available during work time.  Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.  Read more about the pitfall of the Product Owner not showing up.
  8. Stretch Goals: The team decides on how much work it will do in a Sprint.  No one should bring pressure on the team to over-commit.  This simply builds resentment, distrust and encourages low-quality work.  That said, of course teams can be inspired by challenging overall project or product goals.  Read more about the pitfall of setting stretch goals for Scrum teams.
  9. Individual Heroics: Individuals on a Scrum team should not do excessive individual overtime, or in any other way try to be the “hero” of the team.  Scrum helps us build great teams of people, not teams of great people (quote from Barry Turner).
  10. Team Organizes Product Backlog: The team does not have proper insight into the needs of users and instead should be focused on solving technical problems.  The Product Owner needs to be accountable for ROI and therefore should resist any pressure from the team to do things in a particular order for “technical” reasons.
  11. Product Owner Specifies Solutions: The Product Owner must allow the team full freedom to come up with solutions to the problems presented in the Product Backlog.  PBIs should be free of technical specifications unless they can be tied directly to a customer or end-user request.
  12. Urgent Interruptions: Urgent interruptions should not be allowed in a Sprint… instead, if it is urgent enough, the team should cancel the Sprint.  Otherwise, the interruption should be put on the Product Backlog and deferred until the start of the next Sprint.
  13. Making Assumptions: Often team members will fail to ask the Product Owner about details of the work they are doing.  A team member solves problems, but it is critical to know about constraints.  The feedback between PO and Team Member should be ongoing throughout every day of the Sprint.
  14. Not Getting Done: This is hard to prevent from happening from time to time, but it can become a habit for a team to over-commit.  Make sure that a team that is doing this is using burndown charts effectively and is holding demos even when they have not completed all their work.
  15. Demo Not Ready: Sometimes a team forgets that it will take time to prepare for a demo: cleaning the team space, setting up a demonstration environment, getting scripts ready, and ensuring that critical stakeholders are prepped.  These activities can be part of the tasks in the Sprint Backlog.
  16. Prototype Not Shippable: A Scrum team should attempt to produce production-quality, “potentially shippable” software right from the very first Sprint.  Building prototype code just delays the inevitable need to write production code.  Similarly, wireframes, detailed designs and other similar tools should also be avoided.
  17. Distributed Team: Although Scrum does not officially require team members to be collocated in a “war room”, the reality is that any distribution of team members (even just into separate cubicles) has a huge negative impact on transparency and communication, which in turn has a huge impact on productivity and quality.  Here is a YouTube video on distributed Scrum teams.
  18. Directive ScrumMaster: The ScrumMaster needs to be a facilitator who supports the team in learning self-organization, and the Scrum rules.  The ScrumMaster should never succumb to the temptation to suggest how a team member does his or her work, nor what task next to work on.
  19. Changing Team Membership: Scrum is a framework for creating high-performance product development teams.  If the membership of a Scrum team changes, it forces that team to re-start the Forming-Storming-Norming-Performing sequence.  If the team is in Norming or Performing, then changing team membership for any reason is a waste of quite an investment.  Here is a YouTube video on changing Team Membership.
  20. Non-Scrum Roles on the Scrum Team: It is very common for an organization to create a Scrum team without changing the official title and duties of the people who are members of that team.  For example, a person who is a Project Manager might be given the responsibilities of the Product Owner without an official change of title.  Scrum teams should only have a ScrumMaster, a Product Owner, and Team Members.  Our video about the roles on a Scrum team explains why!
  21. Giving Up On Quality: Scrum has very high demands on teams regarding the quality of their results: “potentially shippable software”.  It is easy for a team or organization to fall back on the crutch of defect tracking software instead of maintaining extremely high levels of quality at all times (due to pressure to release features).
  22. Imposed Deadline Scope And Resources: Scrum is reality-based.  If an external stakeholder wants to impose a minimum scope, a deadline and constrain the resources available to the team then they must allow that quality will slip… which in turn is against the principles of Scrum.  The reality is that no-one can predict the future so any such imposition is simply a fantasy.
  23. Definition of “Done” Imposed:  There is confusion between the concept of the definition of “done” and “standards”.  Managers and other stakeholders often incorrectly impose standards on a team as its definition of “done”.
  24. ScrumMaster Not Present: I once saw an organization that had created a room for a “team” of ScrumMasters.  They worked there together most of the time!  The only time the ScrumMaster should be away from the team is when he/she is working on removing an impediment that is outside the team.  Otherwise, the ScrumMaster should be in the team’s room.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail