Getting your Agile Framework Into Shape
As we have heard, Agile is a framework—not a prescription or a rule-book. In this article, Millie Paniccia discusses her experience working in different environments over the last 18 years. She explains how to start with a strong foundation in Lean Agile principles and how to keep supporting that foundation, the team members, and their roles to maintain fitness and strength.
A Fit Agile Framework
By Millie Paniccia
People tell me I have “drunk the Kool-Aid.” Maybe that’s true.
I’ve dedicated the last 18 years of my professional life to working in commercial software product development environments—from employee to executive. As the current Managing Partner of an advisory services firm, I have seen just about all there is to see in business, working with startups whose employees range from three to large organizations that have tens of thousands. Nowadays , I spend most of my time helping organizations with product delivery issues improve, scale or prepare for IPO.
I have learned that regardless of industry, organization size, or belief in an organization’s individuality, most of these environments actually have a lot in common—including teams comprised of good people with good intentions. Unfortunately, most of these teams are lacking a common framework in which to operate.
I believe that an Agile framework is much better than how we used to get work done. I have found that the application of Lean Agile principles with consistency, just like a good exercise regime, can transform how product is delivered to market.
How to Get Your Agile Principles In Shape
Extensive writing already exists defining Lean Agile principles and my intent is not to re-write these articles. The Scaled Agile Framework (SAFe ©) website and texts are an excellent resource on this topic. While all of the Lean Agile principles have value and importance, I have found organizations are most likely to get in shape and stay there, by staying mindful of the following.
Sometimes the only way to get into shape is to re-train teams, together.
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.
People really are doing their best.
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.
Product and engineering need to be in the boat together.
- 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.
It is leadership’s responsibility to provide clear business 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.
Sometimes you just have to reorganize.
It’s ok to have a tech lead on a scrum team.
There, I said it. I know this flies in the face of what we have been taught to create: flat, self-organizing teams. I do not want to take away from the importance of each team member feeling responsible and empowered. However, a tech lead role can provide a lot of value to the team, especially in troubled organizations rebooting their Agile framework. It’s the third leg to the stool, giving the team the balance to stand (product owner, scrum master, tech lead). I have seen the tech lead work effectively to clear engineering impediments within the team and serve as the technical point of contact for the team during the early days of an agile transformation or reboot. As the use of Agile matures in your organization, the need for this separate role may diminish.
There may still be a role for project management.
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.
Teams need an engaged product owner.
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.
Keeping an Agile framework fit requires leadership & ownership.
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.
Organizational Lifestyle Change
We humans do not see much benefit in our health when we head to gym for a month and then leave our sneakers in the closet for the other 11 months of the year. Staying in good physical shape requires an individual lifestyle change.
Getting an organization into shape with Lean Agile is much the same. It requires that leadership and teams set an intention and follow through. Not just for a month, a quarter or even a half-year, but for the life of the business. There must be an organizational lifestyle change. Clear priorities from leadership, a sense of ownership and well understood Lean Agile roles and responsibilities are what it takes to get an Agile framework in shape and keep it that way.
Get In Touch
Contact us to learn how we can help you
increase performance and accelerate value.