4 warning signs that your team is not agile

Agile projects get the most out of people, with huge payoffs in productivity and effectiveness.

Agile projects involve close collaboration and very fast feedback loops. When it works, users' expectations are closely aligned to the project deliverables, and very little time is wasted on nice-to-haves or perfectionism that has no business impact. Agile done right is a thing of beauty, and economical to boot.

But agile productivity typically depends upon the quality of the team members. It requires high IQ, high EQ, and high focus. Put someone in with insufficient subject matter expertise, drive, or decision-making authority, and the team will be chasing its tail. Further, agile depends upon the impedance match between the resources and the tasks: if a team member just doesn't care, or can't stand to be in the room with another team member, close collaboration simply won't happen.

Since agile is all about flexibility and fast iterations, it would be a joke if you did not assess the members of the agile team as early and often as possible to detect and correct the problem children. Fail-fast on team assignments is a best practice.

If, as the Zen masters say, "how you do anything is how you do everything," it should be possible to detect team membership issues before the first sprint has completed. Ideally, you could do that before the first sprint has started. But how?

4 major areas for concern in agile teams

If there's a good thing about a character flaw, it's that the flaw's owner seldom realizes they have it...and they often have it on full display. You just have to know where to look. In most agile teams, there are four major areas for inspection/introspection: users, developers, consultants, and management. Here are forty things (in no particular order of importance) that set off red flags when we see them in agile teams.

Users who...

  • Are not engaged, interested, or motivated; are too busy with their regular jobs to participate deeply
  • Are unwilling to own problems, action items, or deadlines; are unwilling to put their name to anything (particularly requirements, validation, and test scripts)
  • View risk, change, and learning as problems, not ingredients
  • Avoid taking on action items and deadlines; allergic to follow-through
  • Display blaming behaviors and spend time on CYA activities
  • Are outspoken about what they want, but are ignorant of cloud computing realities; assume that the incremental cost of a request is zero
  • Seem to add delay and ambiguity to most decisions; hate cutting to the chase; unwilling to cut "Gordian knots"
  • Fill meetings with inconclusive chatter; tend to magnify clearly bounded issues so that they mushroom into "boil the ocean" problems
  • Are not willing to take action with incomplete information; are always trying to hedge bets
  • Have ADD or are unable to read / write anything of substance

Developers who...

  • Are unwilling to pursue rough-cut solutions
  • Suffer from perfectionism
  • Are over-focused on architecture and software longevity
  • Focus on avoiding criticism rather than getting something out there
  • Are too willing to code first and ask questions later
  • Have poor communication skills, particularly under stress
  • Detest / lack empathy for users
  • Lack project management skills or have an empty-suit manager
  • Are afraid and indecisive
  • Are unable to listen

Consultants who are...

  • Displaying bid-to-win behaviors, are desperate to win a deal or keep the account (hint to clients: interview their CTO about the bid)
  • Too flexible, too compliant, willing to make commitments they cannot really meet (hint to clients: watch out for cultural differences)
  • Unable to deliver "bad news" quickly and effectively (ditto)
  • Unable to say no and make it stick (ditto)
  • Unwilling to take charge in an uncertain situation
  • Unable to listen
  • Unable/unwilling to respond to requests the same day (hint to clients: get an SLA)
  • "Yes men" / empty suits
  • Overemphasizing speed and volume of coding, underemphasizing building the right thing
  • Unwilling to be on site (or at least in the same time zone as the rest of the team)

Management that is...

  • Unwilling to actively participate in the project, as well as champion it
  • Excessively focused on command-and-control, requiring all key decisions to be escalated; unable/unwilling to trust or truly delegate
  • More focused on budget than value; overly interested in narrowly-defined metrics; limited attention span for broad objectives
  • Exhibiting ADD or memory issues
  • Willing to promote someone who really doesn't know the domain and doesn't want to learn it
  • Rewarding fierce intramural competition, so leaders have clear incentives to low-ball budgets, over-promise deliverables, and play games with milestones
  • Holding people accountable but not giving them control of resources.
  • Using fear as a management tool, and publically punishing failure
  • Unwilling to unequivocally prioritize, set realistic deadlines, or acknowledge tradeoffs; unwilling to filter the signal from the noise
  • During contract negotiation, adds unrealistic conditions and asymmetric risk items

The bottom line

There's no scoring system here -- but if you detect enough of the issues outlined above in a team member, seriously consider replacing him/her fast. If you detect enough of the issues in the management area, it's not likely that agile is going to be a success within that part of the organization.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments

Blog Posts

Non-linear transformation: The internal struggle

Let’s face it, transformation is messy. Every business is different, with a set of specific challenges based on a mixture of external (the market, competitors, regulation) and internal factors (technology, people and process investments over time).

Neil Kelly

Partner, transformation, Wunderman Thompson

7 ways to champion a human centred design culture

Human Centred Design (HCD) has come a long way in the last decade with many forward-thinking organisations now asking for HCD teams on their projects. It’s increasingly seen as essential to unlocking innovation, driving superior customer experiences and reducing delivery risk.

Shane Burford

Head of research and design, RXP Group

Building a human-curated brand

If the FANG (Facebook, Amazon, Netflix, Google) sector and their measured worth are the final argument for the successful 21st Century model, then they are beyond reproach. Fine-tuning masses of algorithms to reduce human touchpoints and deliver wild returns to investors—all with workforces infinitesimally small compared to the giants of the 20th Century—has been proven out.

Will Smith

Co-founder and head of new markets, The Plum Guide

It's a useful info for small businesses owners. We can't live without mobile apps. They are so helpful! It's hard to deny that.

Mae Davis

7 ways small businesses can benefit from mobile apps

Read more

Hi Jennifer,Fascinating read about design-led companies!If you would like to learn more, our Design Thinking and Innovation programme mig...

Andrea Foster

How to spot a ‘design-led’ versus ‘design-fed’ company

Read more

ABC web-site not easy to use/navigate. Even getting this far in sign-on to ABC My Space was problematic - it was asking for my password,...

Vee.

How the ABC used an online community to help build a movement

Read more

Thank you for your feedback, Astha! Always appreciated.

Vanessa Skye Mitchell

5 things marketers should know about data privacy in 2020

Read more

Hey Vanessa, thanks for providing us the things marketers should know about data privacy. This was really an informative post.

astha sharma

5 things marketers should know about data privacy in 2020

Read more

Latest Podcast

More podcasts

Sign in