The Agile Regression: How to Avoid Moving Backwards

After the Webinar – More Insights from the Experts, part 2 

Last week I posted more insightful audience questions for Forrester Principal Analyst Kurt Bittner from our recent webinar Dev Ops in the Enterprise.

Since we had such fantastic audience engagement from our listeners – here are some additional that we hand-picked for Gene Kim to answer around The Agile Regression: How to Avoid Moving Backwards

Doug: Our team has been transitioning to Agile, but we seem be regressing and losing our discipline. How do we remedy that?

Gene: There are barriers to agility that usually cause this back-sliding, despite the best of intentions.  –when the governance model reinforces a waterfall approach, agile adoption will usually fail as the up-front planning and back-end reporting wears people down. A team that has milestones such as “requirements complete”, “design complete”, “code complete”, and “testing complete” cannot help but be worn down.

Lack of supportive tooling is bigger than people think.  Agile teams need access to environments, continuous integration and API-driven testing to really make progress.  If your QA is manual there is going to be a real limit to how agile you can be and how fast you can go.

Agile is a great technique for reducing batch size and WIP, but if the business does not embrace this and wants all requirements defined up front, at the start of the project, the team is never really going to be agile.  They can iteratively build and test, which helps a little, but it misses the opportunity to get feedback on whether the right solution is being built.  Many projects fail because they build a technically competent solution to the wrong problem.  Getting early feedback from the right people is key.

The agile culture is a learning culture. If the organization has a culture of punishing mistakes, agile will never take hold. If you hear people talk about “holding people accountable”, it is usually a sign of a culture of blame.  Organizations who react to problems by blaming people rather than looking at the systemic causes of problems fail to learn from the mistakes and tend to habitually repeats them.  This culture and style of management is antagonistic to agile approaches.

The Tug-of-War between Engineering Director and Product Owner

Doug: How do you go about resolving/mediating between engineering director and Product Owner – both of whom want to “own” the team.

Gene:  No one “owns” the team, in the sense that they can direct the team and tell them what to do or how to work.  

Engineering directors who want to direct the team, managing it from outside, prevent the team from self-organizing and making essential decisions. The role of the engineering director is to support the team, making sure it has the resources to succeed and clearing roadblocks that prevent superior performance.  This is sometimes called a “servant leader” style of management. If roadblocks have been removed and the team is not performing, the engineering director may need to change the composition of the team, removing some resources and replacing others, but this represents a pretty broken team and care must be taken in re-forming the team.

Product owners who try to “own” the team are usually micro-managers who try to direct the activities of the team members.  They are not acting as good agile product owners.  The role of the product owner is to represent stakeholders, to set priorities for work items, and to provide subject matter expertise (or access to subject matter experts).  They are not “managing” the project and they should not be directing team members to do work.  How the team organizes to do the work is up to the team.  When a product owner tries to do this they have misunderstood the role of the Product Owner and someone at a higher level in their management chain needs to reset their understanding.  If it continues the Product Owner needs to be removed from the project.

We’d love to hear what questions your organizations have?

–          Doug