The Power of Agile — You Asked, We Answered

The Power of Agile Written over Many Question Marks

Last month, we presented the webinar, How Teams and Leaders Can Unleash the Power of Agile. You can view the accompanying blog post as a primer to learn about how to shift from “Agil-ish” to Agile. We received so many great questions on the topic and have included answers to the top questions below. Thank you all for engaging in our webinar!


How do you get executive buy-in for implementing true Agile practices when your start-up is Agil-ish, but not fully invested in the Agile methodology?

As we discussed during the webinar, practices do not make you Agile. The foundations of Agile are values and principles. Small organizations and startups tend to not invest much time into thinking about and discussing values and principles; rather, they allow them to develop organically in an ad hoc manner, and the organization ends up with whatever evolves.

If you want to take proactive steps to become Agile, your team needs to start with a common foundation and vocabulary of what Agile is, and then develop what Agile means in your organization. Begin with values and principles, then develop practices and processes that work for your context. That means starting with quality training and possibly some follow-on guidance from a consultant who has experience guiding organizations through Agile transformations.

We have found that alignment and team-building are almost equal in value to the insights we impart during training. In just a day or two of courses, teams come away aligned in terms of mindset, values, and principles, as well as the practices that embody them.

If you are in a Product Manager role, and the “Agil-ish” forces are coming from the top down, here are several recommendations:

  1. If your senior executives are open to your input and suggestions, start having discussions around Agile and the outcomes Agile brings. Be sure to point out the anti-patterns that are occurring and the impact they are having on the organization. Share great Agile content with them, including blogs, whitepapers, and books. There are many great books on Agile, such as Jeff Sutherland’s book, “Scrum: The Art of Doing Twice the Work in Half the Time,” that we mentioned in the webinar. Select one book and make reading, reviewing, and discussing it a work-time activity for your team. Ultimately, encourage them to attend an executive-level Agile course while your team is also in training.
  2. If you feel that your executives aren’t open to your suggestions, then work within your immediate team to define Agile principles and values, practices, and processes, and start using those within your immediate team. Leverage retrospectives, chartering, and working agreements. If what you are doing creates positive results, your executives should be more open to learning how to apply this across the organization.

Why can’t budgeting be Agile and added incrementally by milestone or outcome?

The current budgeting process draws its roots from early work on scientific management and supports a command-and-control approach to budgeting. By funding specific outputs with a specific budget, management can sufficiently control the outputs with the goal of controlling the organization’s ability to achieve business outcomes. The problem is that the current annual budgeting process incentivizes some bad budgeting and spending behaviors, and doesn’t necessarily align to how markets really work. In addition, current budgeting processes do not align to Agile values, especially those of trust and accountability. Fortunately, companies are rethinking how they approach budgets. Here are some possible approaches:

Product v. Projects
Many business cases fund a specific project scope. One possible approach is to support a product funding model, in which products are funded in general without a commitment to a specific scope. Instead of specifying a scope, a Product Manager defines product and/or business outcomes they need to achieve to support the organization’s strategy. The desired outcomes are funded. Then, the Product Manager is trusted to make the correct scope decisions and is held accountable for achieving the outcomes. This approach enables more Agile product management and gives Product Managers the flexibility to make the best decisions to achieve outcomes.

Agile Budgeting
Another approach is to create a more Agile budgeting process, in which future budget expectations are more generalized. As you come closer to executing on your scope, you refine the budget or resource allocation based upon the most recent market insights and information. One way this can be done is through the “Now, Next, Later” format. What you are working on now is more detailed, what you are working on next is a little more general, and those items that are later are much higher-level, with a more generalized budget forecast.

To implement any of these approaches, you must be able to demonstrate the value you are delivering by defining and taking accountability for achieving measurable product outcomes, with the expectation that those product outcomes will lead to desired business outcomes.

Doing so requires a significant cultural change within the organization to put more trust into the decision-making ability of those closest to and with the most insight about the challenge at hand.

How do we get Product Owners and Squad Members to truly own the outcomes rather than take order tickets from Product Managers?

If you are implementing Agile practices, the Product Manager should embrace the value of collaborating with the Product Owner and the Scrum Team (Squad Members). Some ways we have found useful in creating that sense of collaboration is sharing context on the customer problem you’re attempting to solve. Tools such as Problem Scenarios, Story Mapping, and Personas can help communicate this contextual information. Also, as part of collaboration, the Product Manager should engage the team in defining solutions that best meet the context and writing the appropriate user stories that feature the key points. A User Story can trigger a conversation that encourages understanding and team collaboration. Better yet, the Product Manager can take team members along with them to actually observe customers using the product. That creates the greatest context of all.

The better the Product Manager communicates the context of the customer need, and the more they collaborate with the Product Owner and Scrum Team, the better each team member can connect the dots between the work they are doing and the impact it has.

Too often, we find teams understanding what the issue is but not having a sense of the greater purpose. Product Managers, Product Owners, and Engineering Managers must ensure that every team member has a sense of the difference their work is making to the business, to the customer, and to the world.

What should we consider with Kanban vs. Scrum squads in terms of meeting the same Agile aspirations?

The same values and principles apply in either case. The difference is in the practices.
While Agile values and principles apply equally to Scrum and Kanban, Scrum and Kanban do not equally support Agile values and principles emerging for different kinds of work.

Scrum, with its aspirational sprint goal, its sprint planning ceremony, its approach to daily standups (daily scrums) as teams coming together to replan daily, and its end-of-sprint demo and retrospective, supports both teamwork in taking on a larger project one set of increments at a time, and internal teamwork every single day via the team supporting every team member to resolve the incremental challenges.

When Kanban teams set and hold themselves accountable to appropriate Work-in-Progress Limits, the need for everyone with a piece of the story to finish before anyone can be finished can motivate internal teamwork that drives to completion. But the team is being driven to complete pieces more than a larger increment that a sprint goal represents. Kanban can feel much more oriented to piecework, making it more difficult to connect the team to customers, larger outcomes, and impacts. Whenever possible, leverage Scrum for projects and products, and leverage Kanban for customer service (in both the smaller and larger sense) and operations.

If you find yourself with a Product team using Kanban, you’ll need to devote more focus to connecting members of the team to customers, impact, and mission, in addition to each other. With Kanban’s lack of regular cadence, retrospectives can become irregular, and experiments (for more team joy, better throughput, higher quality, etc.) all too infrequent.

On the other hand, when presented with outside pressure, Scrum teams may be inspired to focus on output instead of outcomes. A lack of focus on value can lead to:

  • Standups that devolve from replanning to status meetings
  • Planning ceremonies that focus on output rather than outcomes
  • Demos that teams sleep-walk through
  • Retrospectives that don’t yield an experiment to try in the coming sprint

Whether Scrum or Kanban, teams need to be diligent in asking if their practices are delivering on the promises of teamwork and customer focus embodied in the values and principles.

Amp Up Your Team with Agile Values

To become more effective at leveraging Agile, you must first understand why you’re using Agile, then work toward adopting true Agile values, not just Agile practices. Shifting the mindset in your company may take some time, but it’s worth it to create long-lasting and more effective change, so you can continue to delight your customers. Sign up for 280 Group’s Agile Product Management training course to learn how to harness the Agile methodology from the Product Management perspective, to build products that matter — faster and more effectively.


Your Questions Answered By:

Ron Lichty is a Consultant: Interim VP Engineering.
Ron Lichty has been managing software development and product organizations since Apple recruited him from a boutique programming consultancy in 1988. He led the development of Apple’s UX/UI, then brought engineering discipline to product delivery at Stanford, Check Point, Razorfish, Fujitsu, Charles Schwab, and a host of startups. Ron literally wrote the book on software development, Managing the Unmanageable (Addison-Wesley). A strong believer that product development is a team sport, he consults as an interim VP of Engineering and advisor in transforming chaos to clarity and making software development “hum,” including training executive teams on how to support their Agile teams.

Tom Evans is a Principal Consultant and Trainer at 280 Group.
Tom Evans is a Senior Principal Consultant and Trainer at 280 Group and is an internationally recognized authority in product management, product marketing, international business, go-to-market strategies, business partnerships, and entrepreneurship. In his extensive experience, he has helped start-ups through Fortune 500 companies create and launch winning products and has led business development efforts in the US and global markets. Tom has been responsible for successfully developing and implementing Product Management & Product Marketing methodologies at multiple companies.

280 Group is the world’s leading Product Management training and consulting firm. We empower Product Professionals with the knowledge and tools to create products that matter.

What are your thoughts? We’d love to hear from you.

Your email address will not be published. Required fields are marked *