Do this, Not that: 8 Bad Habits Sabotaging Your Agile Transformation

break bad Agile habits, build good habits - motivational reminder on colorful sticky notes - self-development concept

There are a lot of bad work habits: being late, checking Facebook too* many times, not putting your dirty coffee mug in the dishwasher, and interrupting your coworkers during meetings. Bad habits are “bad” because results are negative. They become even more destructive when they directly oppose a goal, e.g., late-night eating when you’re trying to lose weight.

It’s the same with Agile.

During an Agile transformation or adoption, behaviors that were innocent, even positive, can pause momentum or even BLOCK progress. That’s because Agile is not just a process change. Truly becoming Agile involves updating practices and taking a long, hard look at company culture. Below are nine bad behaviors to curb and good replacements if you want to make sure Agile sticks.

Instead of…Rushing teams through training

Do this…Invest the time to train teams, leaders, managers, stakeholders and provide role-specific training to SM’s and PO’s

Training is tantamount to the change initiative. After the organization or department understands the reason for the transformation, it is important for everyone to have the same vocabulary and toolbox. There is also the “practice” part of training where the team learns new practices and lingo by observing the Agile coach at the office and then starting to apply it themselves as they gain confidence.

Instead of…Trying to align to a waterfall/PMO structure roles & cadence

Do this…Leverage the routines, roles & cadence of a Scaled Agile Structure

Define a  program-wide definition of ”Done” that takes into account mandatory requirements for Audit, compliance, operations, NFRs, Security.

Instead of…Having multiple sources of truth

Do this…Create a single, prioritized, Epic-level backlog in your chosen tool (JIRA, Rally, physical board) and use it to gain alignment, visualize, and manage the work.

If you need to create an epic, write them to achieve business value instead of writing them for a specific team. Also, make sure team-level backlog stories are children to the epics, setting the themes and making them visible.

Instead of…Partially allocating people

Do this…Ensure all team members are 100% allocated to their team

Also, each team should have a single Product Owner and ScrumMaster. Dedicated PO’s can scale up to two teams as they still need time to meet with stakeholders. Dedicated ScrumMasters can scale up to two teams well otherwise they turn into the checklist ScrumMaster who is only able to schedule/ facilitate meetings and update metrics.

Instead of…Reacting to delivery team needs

Do this…Leverage information radiators to anticipate needs

Information radiators like a product roadmap or a single, prioritized epic-level backlog forecasting upcoming work, which gives you the opportunity to make sure the team is prepared. They may need more help (additional team members), training (if it’s something they have never done), or tools. In addition, implement a program-wide definition of ready and apply it! This will leaders and ScrumMasters the chance to anticipate the team’s needs.

Instead of…Planning and Executing in silos

Do this…Establish a Program Increment boundary (recommend 3 sprints) and conduct PI Planning

All the teams (architects, dev managers, development team) that need to plan should be on the same planning cadence. In addition, they should be planning together, not in silos, with the help of tools like JIRA and Sococo. The people doing the executing should be involved in the planning to ensure buy-in and commitment to the plan.

Instead of…Reporting by “feel”

Do this…Establishing standards for JIRA and USING it

Even if JIRA isn’t your tool of choice, the point is you need a standard way of measuring and reporting productivity. Another thing, don’t inflate your data or your burndown charts. Gather data from actual team routines, behavior, and action to get a true measure of where you are and how much you have left to go.

Instead of…Expecting the existing system to enable Agile delivery

Do this…Identify systemic issues to efficiency and flow and address root causes

Regardless if you’re all-Agile, Scrummerfall, or straight waterfall, assessing the entire value stream and understanding where the process is slowed will help delivery efforts. Also, empower teams to say “no” to activities and documents that don’t add value and don’t support and enable delivery.  

 

For more on our approach to building lasting business agility, you can check out our Transformation Services page.

Leave a Reply