Overusing Agile Can Reduce Your Success

Overusing agile will decrease your organization’s success! Here are signs of agile overuse:

Agile is the default: Using agile on projects without short-term needs puts unneeded pressure on scarce agile resources. Project solutions needing in-depth, long-term thinking often won’t benefit from agile, because agile doesn’t provide time to think through long-term consequences. If a project doesn’t have true short-term delivery needs, use traditional project management. Apply your agile teams to time-critical projects.

Designs focus on today without considering the future: If your sprints are consumed by fixing functions from hasty, ill-conceived designs, your speed will only get worse if you continue with agile. Lack of long-term analysis and design produces awkward tools or processes that require frequent band-aids. More agile then means more fixes and more fragile solutions.

Prioritization loses integrity: Over-reliance on agile to produce fast results reduces clarity needed to properly prioritize work. When everything is #1 priority, relentless pressure to produce decreases staff effectiveness. The urgency that used to differentiate crucial and nice-to-have is lost. Project timelines lose meaning because deadlines aren’t seen as authentic or justified.

Leaders are impatient to deliver: Another sign of inappropriate use of agile is a rush to deliver, which might introduce sub-par testing and implementing solutions without appropriate training. Leaders, who are focused on speed of change rather than improved outcomes, produce chaos and lose credibility with their teams and customers. Improvements envisioned at project initiation are often abandoned, because team members spend their time correcting issues created by earlier solution implementations.

Agile discipline breaks down: Instead of short, daily stand-up meetings, consistent sprint length and dedicated team members, you see the cadence of delivering functions sputter and confidence in agile wane. In some organizations, the agile terminology remains but doesn’t match what happens. “Stand-ups,” which are supposed to short, daily meetings focused on status, become weekly, long meetings of solving problems in addition to sharing status. The end of a sprint is determined by the next time any work is completed, rather than by the set cadence for progressing the initiative. Retrospectives become complaint sessions and don’t produce meaningful changes to improve results.

Agile can generate outstanding results when properly applied. If you see the symptoms here, don’t abandon agile; reset your conditions for launching agile initiatives.

Picking the Right Tool for Effective Communication

Effective communication content is critical for project managers, but so is the tool you use to send your messages. Here are tool guidelines based on the intent of your communication:

  • Email is appropriate for repeatable and expected messages such as status reporting or scheduling meetings. Because recipients can’t use factors like the voice inflection to interpret the meaning of your emails, it’s unwise to use email for messages that require interpretation. That’s why email should be limited to messages when only a straightforward acknowledgement is required from the recipient.

 

  • The telephone works when more information needs to be exchanged and the data or management process has been previously discussed, such as risk items, known issues being resolved, confirming requirements or simple change requests. Communication like this conveys information that may be questioned by the recipient, but those questions are predictable and the information is easy to discuss. Note: In situations where conflict may occur, use video conferencing or face-to-face meetings to manage the contention.

 

  • Video conference tools are recommended when new or unexpected information needs to be shared. Problem solving, discussing more complex requirements, or reprioritizing requirements are examples where this richer medium is needed. Idea generation and complex problem solving can also be performed via video conferencing, if functions like whiteboard sharing are available and all participants are comfortable with them. Otherwise, train attendees before using these virtual tools or meet face-to-face.

 

  • Face-to-face meetings are recommended when discussing your project in depth with difficult or powerful stakeholders or working through very contentious issues.

 

It isn’t always possible to use the recommended tool. To reduce risk, use the richest possible communication tool for the situation at hand.

Don’t trade efficiency for effectiveness. If you send a lot of messages that don’t yield the actions or answers you need, you’re sending the wrong message or using the wrong communication tool.

 

For more on communication, check out Doug Rose’s LinkedIn Learning course on project communication.

Should you build a detailed project plan?

Bob McGannon and I talk about whether it makes sense to build a detailed project plan given that projects usually change once you start working on them.

https://youtu.be/XVv81PkX5tU

To learn more, check out my Project Management Foundations course on LinkedIn Learning.