Overusing Agile Can Reduce Your Success

/in /by

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

/in /by

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?

/in /by

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.

Manage Scope by Assessing Ownership

/in /by

When project ideas flow freely, managing scope can challenging. One sure way to manage scope is to assess ownership. Unless the identified owner is appropriate, that element shouldn’t be part of your project. An owner is appropriate when:

They can provide funding. An appropriate owner will fund the development of their scope item. In addition, they can increase the funding (within business case parameters) if the cost of delivering the scope increases.  If the identified owner must go elsewhere to obtain or release funds, they aren’t an appropriate owner.

They can provide resources. Appropriate owners provide capable resources for requirements, verification, and implementation of scope items. Providing new or lower-level resources could indicate a lack of dedicated ownership. Delays in getting resources could indicate that other scope items have higher priority, in which case you should evaluate whether the scope element should really be out of scope.

They can make decisions. Scope item owners can make decisions regarding how the scope will be built and implemented. While others may be involved in decision making, an appropriate owner is the final arbiter.  In instances where scope decisions affect others, the appropriate owner has the means to consult with and influence others regarding the scope element (to resolve potential stakeholder conflicts).

They defend the business need. Project constraints can require scope prioritization. An appropriate owner can articulate and defend the business need for their scope items. As the project progresses, they make themselves available to discuss required changes, and assess the impacts of those changes to their business.

To learn more, watch this course.

How a Project Manager Adjusts to Agile

/in /by

Experienced project managers can manage agile projects — IF they make the necessary adaptations! Here’s how you need to adjust when managing agile projects:

Ditch the Gantt Chart. Agile is a fluid production approach based on progressive learning and adapting to business priority changes. As a result, the pre-planned tasks in a Gantt chart aren’t relevant. Instead, you manage a fluid set of design, build and test activities by measuring production for the client.

Revise your view to change management. In agile, change is the norm, not the exception. Project managers need to be comfortable with continually revising scope and priority to meet client needs. Change management is not a separate and distinct control process in agile; it is inherent to the agile approach to delivering client value.  

Use a different status report format. Agile emphasizes velocity – the rate at which functions are produced and the productivity of each sprint. Your status reports should include these elements along with feedback from the end users who are using the functions the agile team has produced.

Rethink “project controls.” Project managers need to direct their efforts to eliminating obstacles that impede the agile team. Resource retention and team and client personnel engagement are paramount. An agile leader must ensure that the team’s capabilities are fully utilized, instead of managing a set of control processes that traditional project managers embrace.

Enjoy the differences! Agile’s focus is on collaboratively creating content that is most useful to the client – even when the client can’t describe what they need in detail! The benefit – and fun – of agile is that you can enjoy the discovery process and deliver capability in the shorter term!

For more on agile, check out the LinkedIn Learning Become an Agile Project Manager learning path.

 

The Right Way to Fast-track or Crash Your Project

/in /by

Fast-tracking means scheduling tasks in parallel when possible. Crashing is adding people or spending money to complete work earlier. Don’t be overly ambitious with these techniques. Here are some dos and don’ts for fast-tracking and crashing:

Do look for opportunities to fast-track or crash. These strategies can shorten the schedule, but also add risk — so make sure they’re worth it.  Fast-tracking increases the risk of rework because products developed in parallel might not integrate. Crashing increases cost, because you must obtain and coordinate additional resources. 

Do add review tasks after fast-tracking. Adding review time lenthens your schedule, but not as much as you save by fast-tracking.  Reviews mitigate the integration risk of fast-tracking. Team members who work on parallel tasks should conduct joint reviews to ensure products are compatible. 

Do use skilled resources to crash your tasks. Adding skilled team members can improve the quality of the product and save time.

Don’t add marginal skills to tasks you’re crashing. Lack of skill creates more overhead – ensure you have capable people. Also, limit the number of people on crashed tasks. Too many people get in each other’s way, wasting time and money.

Don’t compromise project integrity by fast-tracking testing. Testing tasks should be exempt from fast-tracking. Testing evaluates the appropriateness of your products. You can’t conduct high-integrity tests while product development is still in progress. If you do that, you’ll need additional regression testing, which negates the fast-tracking time savings.

Don’t apply both fast-tracking and crashing to the same tasks. This increases risk dramatically and is rarely successful. I call this “fast-crashing,” because, like a car accident, you can’t help but look, though the results aren’t pretty.  

For more on these techniques, watch my LinkedIn scheduling course

 

What you can and can’t change in Agile

/in /by

Agile methodologies accommodate change easily, which is why they’re called -er- agile! However, some things don’t change. Here’s an overview of what you can and can’t change with agile:

Priority.  Each sprint includes a review and re-prioritization of the functional backlog, so you can change priority before each sprint.  Prioritization of items commonly occurs as functions are produced and stakeholders learn from using those functions. New business challenges and the benefit of new functions can come to light and be addressed. Priority changes must comply with technical practicalities and logical business sequences. For example, you can’t build a balance sheet unless you can process both revenue and expenses!

Schedule. When you review the functional backlog, you can adjust the schedule by moving the functions the business needs or wants into upcoming sprints. However, rescheduling requires accurate effort estimating.Developers learn more about the functions they produce, which improves their ability to estimate effort. As a result, you can more easily manage the schedule as the project progresses.

Scope. New scope ideas often surface after a few functions are produced. Scope changes are not only accommodated, but expected, with agile approaches. However, this often involves trade-offs. Budget and time negotiations or dropping existing scope items to accommodate new and important functions are likely to occur.

Deadlines. Agile projects usually involve allocating personnel for a pre-determined amount of time. Scope becomes the variable. As scope changes or reprioritizations are discussed, you can adjust the sprints to change deadlines for specific functions. The overall project deadline can even be changed– assuming the whole team is still available.

Don’t count on changing cadence or personnel! Setting the agile team anda sprint schedule – and sticking to it – are major success factors with agile. A major benefit of agile is what is learned along the way. Changing personnel disrupts that learning and diminishes agile benefits. Changing sprint structures can also be disruptive. Schedules are built around the vital, focused sprint meetings and activities. Changing the schedule can throw the team off their rhythm and disrupt the estimates and sprint plans that have been created.

For more on agile, check out the Become an Agile Project Manager learning path 

The Benefits of Dedicated Resources

/in /by

Dedicated project team members might appear expensive, but they provide significant benefits, which might reduce your project costs:

Focused responsibilities. Dedicated people aren’t distracted by day-to-day operational issues. They can fully examine the project deliverables and understand how the project is proceeding so they can deliver what’s best for the project. You get better outcomes and reduce rework.

The right skills for the job. Operational knowledge is important, but it doesn’t necessarily mean the person has the best skillset to create project deliverables. Recruiting people with the most appropriate skills and assigning them to project tasks can optimize your project delivery. Contractors can join the project as dedicated resources for only the time needed to accomplish their tasks, which can reduce project overhead costs.

Greater efficiency. Dedicated, skilled team members typically take fewer hours to produce their deliverables because they don’t have to multi-task. Multi-tasking wastes time while not making progress — like catching up when you reopen a novel after putting it down. Operational personnel who also produce project deliverables are multi-tasking: they need to re-acclimatize themselves each time they switch between operational and project work. This wastes time and increases costs.

Continued access to operational knowledge. Assigning dedicated team members to your project doesn’t necessarily mean losing operational knowledge. Your dedicated team members can interview or shadow operational personnel to obtain first-hand knowledge of business operations and then apply that knowledge to your project deliverables.

Quicker delivery. The efficiencies of dedicated resources can mean a shorter project. Your business value is realized more quickly, and you can move on to your next project – and deliver more business value sooner!

To learn more, watch Chris Croft’s course Managing Resources Across Project Teams.

 

A Project Manager’s Responsible Optimism

/in /by

The pessimism of Eeyore, the gloomy donkey from Winnie-the-Pooh, would make him an uninspiring project manager. But unchecked optimism isn’t good either—you come off as unrealistic. Here are some tips for achieving the balance of constructive optimism:

  • Complement optimism with risk management. Balance your optimism with constructive risk discussions. Openly surface issues and the response actions you are taking. Create a risk management culture within your project. You can enhance stakeholder management with well placed optimism based on your experience and abilities. Taken too far, you may create concerns that you’ll overlook roadblocks.
  • Support optimism with history. Strengthen the validity of your optimism by referencing past successes. Successes from your current organization are the most powerful. When your history comes from elsewhere, discuss the characteristics your current organization has in common with past environments. This bases your optimism in fact, versus only a cheerful attitude.
  • Accept any pessimism you may encounter. But address that pessimism with open dialog to determine how to manage the situation. While pessimism can be draining, pessimistic viewpoints can raise valid risks. Don’t discard them without first evaluating their validity.
  • Be yourself. You became a project manager because of your skills and abilities. You shouldn’t change what you do now! Be mindful of how your optimism or pessimism affects others. Using the tips suggested here, tweak your levels if necessary. However, don’t fake optimism. People see through this eventually, and it’ll do more harm than good.

For more on project management, follow me on LinkednIn (https://www.linkedin.com/in/bonniebiafore/) and check out the LinkedIn Learning Become a Project Manager learning path