3 Ways you can Empower High-Performing Agile Innovation Teams

Picture yourself presenting a minimally viable product to executives, business stakeholders, and other subject matter […]

Picture yourself presenting a minimally viable product to executives, business
stakeholders, and other subject matter experts to develop enthusiasm and
garner their support for a new customer-facing innovation your team is working
on.

Now take a few steps backward in time, and consider how to empower your agile
teams, led by product management and supported through DevOps best practices,
to deliver an amazing MVP. That MVP will show some of the core capabilities
but will be far from all the features, bells, and whistles that executives and
stakeholders want and dream of in their product visions.

Which innovation practices will you focus on to empower your team and enable
them to optimize decisions on prioritization, user experience, data
structures, technology architecture, and the myriad of other decisions that
form an innovation’s foundations.

I share several of my innovation stories in my new book,
Digital Trailblazer, including one where the team had to turn around a stressful meeting of
executive stakeholders looking for advanced analytics capabilities in version
one of a new product. In addition to my stories, I share fifty lessons
learned that digital trailblazers and aspiring transformation leaders can
learn from.

Looking back at my experiences leading high-performing agile innovation teams,
here are three lessons I can share with you today.

1. Lead inclusive brainstorming that drives decisions and actions

Early in the design of an MVP, it’s common and necessary to assemble diverse
multidisciplinary teams to review opportunities, define problem statements,
and brainstorm solutions.

My key question is, how are product management and agile leaders conducting
these brainstorming sessions, especially when in hybrid-working environments,
you are unlikely to get everyone in one room? These meetings should be
facilitated in structured ways, and my recommendation is to

  1. Invite a small, diverse, multidisciplinary team to participate
  2. Designate a meeting facilitator, often a
    product manager
    or
    delivery manager
  3. Define the problem or opportunity, ensure the team stays on scope, and
    parking lot follow-up topics
  4. Coordinate the discussion so all voices are heard and dominant personalities
    don’t overtake the conversation
  5. Leverage tools to capture ideas, diagram approaches, and review data
  6. Schedule the final 30 minutes (or more) of the meeting to capture solutions
    and recommendations
  7. Document the recommendations, and leave them open for feedback, especially
    from those that were not part of the brainstorming process

This approach avoids several common pitfalls that I’ve witnessed in
brainstorming solutions.

2. Promote data-driven practices: Dashboards, not spreadsheets and PowerPoints

Innovation teams have to sell their ideas, share stories, and leverage data to
back up their recommendations. Now selling the idea may require creating a
deck, but when it comes to storytelling with data, I encourage teams to avoid
watering down data and analytical insights into overly simplified PowerPoints
or manually developed spreadsheets.

Show me dashboards
that connect directly to data sources and then develop your stories directly
off real-time data. Let me or any stakeholder audience ask questions and
hopefully utilize these same dashboards to answer questions.

More importantly, make analytics and dashboards a fabric of how innovation
teams operate. That’s one step to leading data-driven cultures.

3. Guide agile retrospectives that lead to action

Agile retrospectives should be closed-door discussions for teams to discuss
the previous sprint’s accomplishments. The
scrum master
or other team leader facilitates the discussion by asking each teammate what
went well during the sprint, what were some of the challenges, and what the
team should improve. Some organizations will also schedule retrospective
meetings after releases and other major milestones.

I’m hugely supportive of these meetings and usually don’t attend them. No one
wants the CIO or other leaders in the room when self-organizing teams discuss
their collaborative practices.

But I do expect to see their recommendations and want them itemized on their
backlogs. I expect product managers, product owners, delivery managers, and
agile team leaders
will review them and discuss what changes need to be prioritized. Discussing
problems and solutions only leads to improvements through transformative
actions.

 


The original article can be found at: Star CIO