Five Tips on How To Manage Disruptive Projects in an Agile Organization without going Crazy!

Don't Panic, Posted by J Linwood

Agile teams are best organized when team responsibilities are clearly defined and separated from other teams, when business deliverables can be accomplished with a minimal number of teams, and when there is clear process to handle the communication and dependency between teams. Anyone who has led or participated in an agile organization knows that the easiest deliverables are ones that can be fulfilled by a single team. When multiple teams are needed, you need well defined responsibilities and coordination practices which add to overhead and risk.

A well designed agile organization defines teams to minimize cross-team dependencies. But what happens when a project, epic or other business need requires the coordination of teams that is outside the norm? What happens if these projects have dependencies on vendors or other teams that are not part of your agile organization?

Disruptive Projects in Agile Organizations

I call these Disruptive Projects because they disrupt the natural cadence that agile organizations target. These projects often have blocks, stop and go rhythms, unclear lines of ownership, and probably ill defined technical "nonfunctional" requirements. Examples include infrastructure upgrades, multi-organization workflow changes, ERP driven projects, security investments - basically horizontal projects that cut across multiple departments and technology platforms. These projects might require relatively small, but critical contributions from individual teams and where teams must collaborate differently than business as usual programs.

I have seen many of these projects, and they can drive teams crazy! So if you are leading or on one of these projects, here are some tips that I pass on to my teams.

1. Break Dependencies - When you hear people say, I'm waiting for another team to finish their deliverable - or that other teams are running behind, my response is, "So what!" Are you fully prepared to run things once another team completes, their work? More often teams are ill prepared on their own responsibilities and use scheduling unknowns or risks to divert responsibility. This behavior is often non intentional and it more often reflects the team's difficulty to break dependencies and to conceive their own responsibilities, requirements and solutions before receiving complete direction. I tell teams, that to improve Agile Velocity, have at least two sprints of fully defined stories in the backlog - one tactic to help the blocks or stop/go rhythms of disruptive projects.


2. Focus On What You Control - This is related to (1) and sounds academic, but teams often forget this when faced with uncertainty or ill defined requirements. Teams should ask themselves, what can we do today, this sprint, for the next milestone that will improve the health of the project, remove a risk, or realize a new opportunity. When individual teams think this way on a continual basis, they will either improve collaboration (by looking internally first), improve the project's execution (by identifying risks early and working on solutions) or even innovate (by establishing a new tool or capability that is beyond or tangential to the project scope).


3. Don't Panic! - Faced with a complex project, unknowns, and risks team members sometimes resort to bad behavior including blaming, backtalking, passive aggressiveness, or just expressing their stress. This can be magnified if the project has significant business implications, the team is under stress to hit a deadline, there are a difficult set of requirements, or a combination of these factors. Despite the pressure, it is important for leaders especially in IT to stay calm, logical, and collaborative. I often quote the famous Douglas Adams line, "Don't Panic!" - the planet is not about to blow up.  Teams in this situation have usually failed at (1) and/or (2) and bad behaviors materialize instead. This can be brought under control, but relieving the pressure (Don't panic!), and addressing the fundamental issues (1 and 2).


4. Ask "Thinking" Questions - Thinking questions should be designed to help teams or individuals recognize gaps in plans or in testing. "Have you thought about..." or "How are you testing for..." or "What will happen if..." type questions force teams to think through their solutions, processes, and testing strategies for completeness.


5. In the 3rd Period, Change Up Your Lines - In hockey, you'll sometimes see coaches move players from one line to another in the hope that a different combination will surprise the opponent and score goals. This strategy sometimes works for horizontal projects, especially toward their ends (the 3rd period) if the amount of coordination across teams exceeds the amount of work that needs to be completed. Sometimes, it's better to regroup individuals from across multiple teams with the goal of getting the project done.  

Hope you find this helpful!