Getting your Agile Framework Into Shape

Yes, yes, I know—I have heard all of the objections to this. “I already received training (at this company or someplace else),” “I already know what Agile is all about,” and so on. It’s true: most teams today have had exposure to Agile in some form. Many have lost their belief that it’s effective.

While it may cost more up front, a team reset with re-training is sometimes the only way to get things back on track. Re-training teams together enables one or more teams to implement the same Agile framework within the current organizational context. They can share a revised set of principles, roles, responsibilities, and processes. This enables teams to collaborate much more effectively and deliver value to market faster than before.

During my first week at a new organization I was told, “You may have to get a whole new team. The team you are working with is terrible.” I am proud to say that several years later, many of the same people still worked at that organization in similar or different roles. I really do believe people are doing their best (with occasional exceptions). What’s really going on is that teams are struggling to connect their work to the business objectives and team members are often not assigned to roles that play to their strengths.

Managers who take the time to optimize people to roles will reap the benefits for years to come (and form valuable, long-term relationships in the process). Most people are not incompetent or lazy. On the contrary, they just need to know what to do and why they are doing it, and have the skills and information required to get the work done.

There must be partnership from the top-down between product and tech: if one tips the canoe, they all fall in. Unfortunately, it is not uncommon to find trust issues between product and technology. This is the most important issue to resolve. Like most relationship issues, these take time to develop and will take time to go away. Often I hear things like:

• Product doesn’t know what they want.
• Product makes bad decisions.
• Engineering never delivers anything (or anything on time, or anything that works…)
• Engineering should have been taking care of this tech debt along the way.

This destructive talk needs to stop immediately. Product has the responsibility to determine business value and priority while engineering has the responsibility of building quality, scalable, and releasable code. One needs the other and they sink or swim together. This needs to be the message from the top-down, left, and right. It is the responsibility of leadership to carry and reinforce this message. To do anything different is sabotage.

This seems simple, but in almost every engagement I start, clear and current business objectives and priorities are missing. Frequently, teams do not understand what is most important to the organization. Every team member at every level of the organization should have access to and understand the organization’s strategic objectives. Furthermore, they need to understand how their work ties to those objectives.

Remember good old requirements traceability–today’s Lean Agile practices show us “strategic traceability” is far more valuable. When we start working with new teams, we often ask “What are the current strategic objectives?”, “How does this feature or user story support specific strategic objectives?” Most of the time we find that  the teams can’t articulate the strategic objectives nor connect them to their work, When they do, amazing things happen; we have seen teams come up with solutions not imagined up front or when they are at an impasse on how to best achieve value, the traceability to strategy can be the tie breaker.

Tying features to business value will empower teams to prioritize more effectively, enabling them to develop and release product that will make the greatest impact to the organization. Working on what matters is exciting and when people feel engaged with what’s important, amazing things happen. Leadership, it is your job to provide clear business objectives to your teams so they can make these priority connections.

Aakk—more Agile heresy! Sometimes there are dependencies that fall outside of teams using an Agile framework. There are key initiatives that span many teams that need to be coordinated. While I would love to have an entire organization utilizing an Agile framework, that’s just not happening in many organizations.

Whenever I hire a scrum master, I make sure I evaluate whether s/he is comfortable wearing a project coordinator/manager hat if needed.  Why make an unwilling tech or product person coordinate when there are individuals who like to coordinate? A project management or a lead scrum master role can be extremely effective, and the attitude that these should not be utilized drives me a little bananas.

Really, the goal is to deliver valuable products to market. How can that happen if the person responsible for the product does not spend time with his or her team? Too often I have encountered product owners or managers who are unavailable to the team or worse, uninterested in the work of the team.

A product owner is a critical team role and the team’s PO is responsible for what the team delivers. The product owner should want to be part of this. In scrum, this means attending daily stand-ups and other scrum meetings, writing and collaborating with the team on epics and stories refinement, assigning business value, and being available to help with prioritization as is needed by the team.

Don’t assume that a disparate set of scrum masters has the authority to provide the Agile framework with the care and feeding it needs to stay alive and effective. It’s the support of the framework that is most important to preserve its effectiveness. Leaving this responsibility to centers of excellence is not enough support. This needs to be the job of one or many people.

While the term “PMO” has lost is shine in many circles, my experience has been that a PMO (or similar organization) to own the framework is quite effective. PMOs that only have responsibility for process can be perceived as unhelpful and ineffective.  However, PMOs that share responsibility for delivery with engineering and product by serving as the dotted or straight line reporting structure for the scrum masters, can provide even greater value to the organization, as they really are part of the team.