I’ve occasionally shared blog posts related to questions from my good friend Lee Copeland. Lee will occasionally send me an email asking a question related to an article or talk idea that he has. In this case, he asked me about – “bad things that Scrum typically exposes”?

He sent me this list to illustrate the sorts of things he was looking for:

  1. weak people (who managed to hide),
  2. time stolen (by people for pet projects), and
  3. Parkinson's Law (work expands to fill the time allotted).

I thought about it for a couple of days, as I didn’t necessarily resonate with his short list. In fact, my initial reply to Lee was that – Scrum exposes EVERYTHING; so making a list could be a long effort. But upon reflection, I’ve created a “Top 10” Baker’s Dozen of things (challenges, dysfunctions, problems, etc.) that I typically see when organizations transform to Scrum.

It’s not intended to be exhaustive, but I hope you find it thought provoking…

  1. That Leadership generally distrusts their Teams;
    1. They distrust their skills, their intentions;
    2. That they are accountable, responsible, and committed;
    3. That they are hard working;
    4. That their estimates don’t contain fluff, pad, or buffer;
    5. That they can work independently (without micro-management).
  2. That most organizations have established ineffective or dysfunctional metric systems;
    1. Measuring pure output and not outcome;
    2. Measurement that is aligned with rewards and performance critique;
    3. Measurement that is aligned to stack-ranking;
    4. Measurement that truly is about micro-management and control;
    5. Measurement that focuses on trust, but VERIFY.
  3. That there is a lack of teamwork, instead individuals want to work ONLY on their “little piece”;
    1. Narrow views toward what “I” need to contribute;
    2. A lack of interest to any work beyond my own;
    3. Considering a story to be “done” when my part of the story is done;
    4. Not engaging in whole team planning in Sprint Planning;
    5. Not engaging in whole team estimation in Backlog Refinement;
    6. The language of “I don’t really care about that” emerges often within the “team” meetings.
  4. That Teams generally distrust their Leaders;
    1. Their ability to make a decision – for example choosing feature priority in backlogs;
    2. The fact that they “care” about the great people they’ve hired;
    3. That they trust the team, so a “circle” of mistrust;
    4. They often don’t hear about the leaders vision, so they don’t necessarily trust it when it comes;
    5. That they are transparent and tell the truth.
  5. That we have a general inability to estimate software development well – in a word, we still SUCK at it;
    1. That we often get too far into the weeds too soon trying to understand every detail;
    2. We want to break every User Story down into 1 or 2 point stories;
    3. Estimating only the development or the development-centric work;
    4. Estimating tasks in fine granularity and losing the “big picture”;
    5. Tasking stories out too soon (before Sprint Planning) in an effort to understand everything;
    6. Thinking that exhaustive planning is a guarantee for successful execution.
  6. That we continue to pursue the fools errand of trying to define upfront requirements at 100% detail;
    1. We continue to assume that (written) requirements can be the sole communication method for customer needs;
    2. We continue to want to exchange (text – email, text messages, tweets, etc.) rather than TALK to each other;
    3. We also continue to forget that working code (visuals, prototypes, mock-ups, etc.) are one of the best ways to envision needs;
    4. We continue to get trapped by – “That’s not what I asked for” when we deliver our software;
    5. We continue to forget that CONVERSATION is the essence of communication.
  7. That we still have an affinity towards tools and processes (Silver Bullets) solving our hardest problems;
    1. First step for many agile transformations – what tool do we buy?
    2. Second step – what process do we pick?
    3. Third step – what scaled framework do we pick?
    4. Fourth step – managers draw an organization chart.
    5. Fifth step – managers form teams around org chart; little training, little team engagement.
    6. Then – Go, Be Agile!
    7. Much later step – WHY isn’t this “agile stuff” working as promised?
  8. That teams generally lack the ability to admit a failure AND the ability to ask for help;
    1. We continue to assume that teams are perfect and don’t make mistakes OR don’t tolerate mistakes;
    2. We continue to assume that failure is bad;
    3. We continue to reward loudness, brashness, extroverts, reactive over proactive thoughtfulness;
    4. We continue to look at experimentation, prototyping, exploration, and trying new approaches as a “waste of time”;
    5. We continue to expect learning to be done “outside of” our projects, as if we always know everything there is to know.
  9. That Organizations and Teams ALWAYS seem to bite off more than they can CHEW;
    1. We continue to short-shrift backlog refinement as a wasteful activity;
    2. We continue to succumb to business pressure and reduce our estimates;
    3. We continue to cut corners because of date constraints;
    4. We continue to be optimistic in our estimates in plans – even though history usually shows us otherwise;
    5. We continue to forget that under promise and over deliver is a VERY effective strategy;
  10. That we would rather rework something over and over than build it “right” the first time;
    1. We continue to implement the requirements, then be amazed when someone says – that’s not what I wanted;
    2. We continue to rush into designs and code, succumbing to pressure and cutting corners – only to have to redesign (or not) later;
    3. We continue to think that code complete – is done;
    4. We continue to think that you – test in quality;
    5. We continue to wait to the last possible moment to show our work (100% done) to our clients for “sign-off”;
    6. We continue to think that lots of bugs are “inevitable”.
  11. That teams ALWAYS know who the best (and worst) performers are on the team;
    1. Managers continue to think that they are the best judges of who performs best in teams;
    2. Managers continue to rarely ask their teams who is “leaping tall buildings”;
    3. Managers continue to view individual performance OVER team performance;
    4. Managers are usually uncomfortable engaging their agile team ceremonies and OBSERVING to gather performance information;
    5. Managers continue to lack open-mindedness to change their minds on overall performance (team, individual, etc.) based on other information.
  12. That teams aren’t the primary challenge when “going Agile”. Instead organizational leadership and culture ARE the primary impediment;
    1. We continue to focus training towards the teams;
    2. We continue to focus coaching towards the teams;
    3. We continue to assume / allow “managers and leadership” to SAY that they understand agile principles and approaches;
    4. We continue to use the same management approaches (and metrics) for leading our agile teams;
    5. We continue to wonder WHY agile transformation is so hard and blame it on those pesky teams.
  13. That CHANGE is HARD!
    1. Organizational change is hard;
    2. You often need Champions and Leaders who inspire, envision, and lead the efforts;
    3. Everyone is involved in an agile transformation, no one is exempt, and it requires continuous effort and learning;
    4. Staid leadership that continues to push agility when the going is easy and hard;
    5. Asking / seeking help is a sign of strength, not weakness and that external agile coaches are part of the change; so don’t go it alone.

Wrapping up

I hope this list inspires you to think of anti-patterns that you might recognize in your own agile transformation. Not to make you feel intimidated or overwhelmed, but to encourage you to face them as the impediments they are.

One of the key activities that can help in any agile transformation is capturing organizational impediments as mentioned in this Scrum Alliance posted article:

https://www.scrumalliance.org/community/articles/2009/april/top-ten-organizational-impediments

#10. Failure to Remove Organizational Impediments
Jeff Sutherland, co-creator of Scrum, considers the failure to remove organizational impediments to be the main obstacle facing large organizations. Common reasons for not removing impediments are "That's the way we've always done business" and "We won't change because we invested so much in this."

But to remove them, you first need to recognize them. That’s really been my focus in sharing these thoughts & patterns.

Stay agile my friends,

Bob.

Comment