For Agility's Sake

In this episode Hannes Färberböck shares his rich, 20+ year history of agile and its various methodologies with us. Hannes is the Managing Director of Nagarro's Austrian operations and the had of their Testing Business Unit. He first started his journey by learning and applying Extreme Programming (XP), and then conducting trainings for other teams on XP.

Hannes recalls hearing about the first ever XP conference, where many of the signatories of the Agile Manifesto were in attendance (before it actually existed).

Looking back over time and seeing how agile has evolved, here are some of the changes that Hannes reflects on:

1. + There is more than one process you can use to be agile
2. + Companies can (and should) adapt those processes to meet their needs
3. + DevOps significantly helps reduce silos between dev teams and operations (he sees the next best version as DevTestOps).
4. Continuous Delivery: while it has the right goals, it can unintentionally turn "burndown charts" into "burnout charts" where teams never get a moment to take a breath.

To that last point, we discussed the importance of NOT ignoring or delaying your continuous improvement focus. Whether it be a technical area like refactoring code, or a more interpersonal area like building trust on the team, these things cannot be delayed because we have too many things to deliver. Instead, we need to make them a routine that becomes part of the fabric of the organization.

Luke Nieuwenhuis, VP of ABO Incentives at Amway explains how Agile is a way of getting work done. We often overcomplicate it, but it's really about how we get things done as an organization.
WHY IT MATTERS
Our ability to move more quickly from one thing to another (markets, projects, strategies, etc.) is paramount to our ability to keep serving our customers.
On the ground floor, our teams can be very flexible. They often know that what we're working on might not be the most important thing - the struggle is to get the rest of the organization to keep up.
EXPLAINING AGILE IN SIMPLE TERMS
Don't get caught up in the terminology (epics, features, sprints, etc.) The more we can talk about agile in terms of the intent behind the things we're doing, the better people will understand it.
Our intent: focus first on the customer. What are their needs? How do we know those are their needs? How do we go about executing in solving those problems? How do we know our solution has solved it? These are the questions that agile is helping us answer.
CHANGING MINDS IS HARD
We tried to explain that we don't need to force "everything" into one big launch, but until we showed people how it could work differently, it didn't stick. The proof was in showing them it's viable, and only after that did we really start to shift thinking.
WHAT DOES IT MEAN FOR THE CUSTOMER
Their feedback has a greater influence on how we make decisions and build solutions that help them run their business. The faster and more often we incorporate their feedback, the more trust we build with them.
The caution is to not over do it. At some point, too much change makes it impossible to keep up with. If a tool you use to run your business changes every month, it's going to be difficult to be efficient and effective.
THE CHALLENGES
The relationship between the process of how we work and the corresponding organizational structure. Today we are organized by functions and departments, and when we have work to do we spin up a project team and assign people to it. Getting to a place where we have stable teams is critical. Most teams should be persistent - and the work flows to the team.
The transition from a project-based approach to a flow-based approach has a messy middle. It requires us to think differently about how teams work, and at the same time, identify ways we can do it in an organizational system that isn't completely designed for it yet. The risk is that we think "agile isn't working" because we haven't given the organization time to catch up with this new way of thinking - and at that point the tendency is to go back to what we've always done.
HOW A LEADER CAN HELP

1. When you get a new "project" or objective to accomplish, pause before you spin up a project team. Consider what stable teams exist (or should exist) in order to help you accomplish the work.
2. Be more aware of how agile is seeking to accomplish the goals / work.

Product Management Coach Scott Sehlhorst goes deep into how an Agile Workflow Model and Product Management can enable a company to thrive in an increasingly complex world.
Our Agile Workflow Model is a robust decision making system; providing clarity and alignment at each decision point. This is the only way we can manage the complexity AND stay aligned as we execute.
Scott explains the difference between a "regular workflow" and an "Agile workflow" and much more:

• Cross-functional collaboration over multiple Product teams and how they should work together.
• Product Teams should be focused on the prolems they are solving. It's not about building the thing. It's about solving the problem set before us and achieving the outcomes that result from solving the problem.
• Scaling and coordination across product teams is a challenge, but it's a requirement for large companies.
• The tiers of our workflow model are not hierarchical, they are a separation of concerns, they are looking at different time horizons, they are making decisions on different levels of the problem. They MUST work together.
• 3 Amigos: Product Owner, Tech Lead and QA Lead. Each person has their own vantage point and their own blind spots - but together, you minimize the likelihood of shared blindspots. Add the Scrum Master to those 3 roles and now the team can improve their own execution and effectiveness. As the team gets better at self-improvement, the Scrum Master role becomes more and more about cross-team coordination.
• What do you do if you have too much work for a Product Owner? Don't add a second product owner - then you have two cooks in the kitchen. Instead, add a Business Analyst - someone who can think like a PO, but doesn't hold the same role.
• T-shaped teams: some roles look broader at the situation and context, other roles are very narrow and specific to a topic/discipline. It's rare to find a single person who has both. On our teams with 3 amigos, we improve our odds of seeing things broadly and deeply (as in the T-shape).

Link to Count Basie song Scott mentioned and incorrectly named: Count Basie - Straight Ahead

Marty Bradley, Sr VP at LeadingAgile, says Agile Transformation is NOT about Agile; it's a way of achieving your companies goals. Here are some of the other topics we discussed.

• It's not about Agile. It's a way of achieving your goals.
• Companies have to get better de-risking their investments.
• Example: Increasing Sky Atmosphere sales with fast feedback loops.
• 3 elements of agility: teams, backlog, working tested software
• Teams: a stable cross-functional team has all of the members it needs to ship a product.
• Backlog: a healthy backlog of clearly defined work increases predictability.
• Working tested software: deliver something that a user can try - it's ok if it's rudimentary, but it has to "work")
• Face to face collaboration is ALWAYS faster.
• Deciding what to work on based on data
• Managing an Agile Team
  1. Step out of the Project Management elements.
  2. Identify ways to make your team more effective / efficient - be a coach.
  3. Lead your people: develop them, not the product/tech.
  4. Stop solutioning - support the delivery system by trusting your team

Learn about the System of Transformation we use to improve the organization (currently only available to Amway Employees).
Send questions/comments to the Agile Transformation Office.

Product Management Coach Erin talks about her experience with agile as a developer, a Scrum Master and an Agile Coach over the last decade.