A Practical Approach to Agility and Product Management

Month: June 2016

Agile is Everything – Everything is Agile

As agilists, we are all fighting – to various extents – the perception that Agile is a set of processes, techniques, and (if we’re lucky enough that people understand this) mindsets to optimize software development teams. To some degree I can’t blame people for thinking that because that’s kinda how Agile got started. But nowadays Agile is taking a very holistic approach, a perspective that goes far beyond helping a team of developers function better. By the way, when I say “Agile”, I’m including Agile scaling frameworks as well as Lean and related product development approaches (so yes, I’m casting a pretty wide net, which is reflective of the close relationships between these different knowledge areas).

Here are additional angles Agile is looking at the world from and tries to impact:

  • arrows with AgileOrganizational agility: enabling the organization to act and react quickly to environmental and market conditions.
  • Portfolio management, i.e. understanding size and benefit of high-level initiatives and making optimal decisions for the business. Working on the right things (in the right order).
  • Systems thinking (vs. local optimizations), aimed at optimizing the whole process of value delivery, not just software development.
  • Removal of waste in processes and shortening cycle times of value delivery (not just creating shippable code).
  • Making decisions based on economical and empirical considerations.
  • The Lean Agile mindset which influences leadership style and organizational decision making.
  • Organizational culture, including, but not limited to trust, respect, empowerment, etc.
  • Organizational design and structure as well as performance management and recognition approaches.
  • Product development approaches, e.g. the Lean Startup.
  • Drive away from industrial era management beliefs and styles.
  • Accounting practices impacting if and how capitalization is practiced, budgeting and planning.
  • Appropriate metrics and KPIs.
  • Technical practices (CI, CD, DevOps) and quality practices (test automation etc.) and technical craftsmanship.
  • Architecture (think emergent architecture, loosely-coupled components, micro services, etc.)
  • Relentless (self-) improvement at all levels. Kaizen.
  • Team and interpersonal dynamics.
  • Team and organizational health.
  • Product innovation.

I probably forgot a few elements, but you get the gist. This is why agilists want to engage with and influence various levels in the organization, including senior management, and individuals in

  • Engineering, technology, architecture, quality (obviously)
  • IT infrastructure
  • Product management
  • Project management
  • Finance & accounting
  • Human resources

Hopefully over time the limited perception of Agile will be corrected by people and organizations understanding the holistic nature of Agile. With that approach, we can really unlock and enable the potential of an organization and its products.

Internal Agile Coaches – “Planting” vs. “Building”

In recent years, more and more companies have realized the value of Agile coaching and the need to have full-time employees in the role of Agile coaches to help keep the Agile ship on course. The most effective candidate for this kind of job are people who’ve already played the role of Agile coach before and have gathered experience with several other companies, therefore companies often find themselves hiring coaches from consulting companies, people who want to “get off the road” and prefer to cut down on their travel and dedicate themselves to a single organization. As these former consultants get used to life inside an organization, it’s interesting that more often than not they have to adjust quite a bit and learn that what made them successful as a consultant will not make them successful inside an organization. To use an analogy, being successful as an internal Agile coach is more like “planting” whereas being an external coach and consultant is more analogous to “building”. Let me explain:

When an Agile consultant is brought into an organization, there is often a specific problem to solve that  requires buildingimmediate attention and action, such as leading a transformation or increasing the maturity of a group of teams. The person comes in with with an objective and expectation of results, which may translate into some kind of mandate and organizational power and influence. It’s like building a house where quickly a foundation is laid upon which parts are assembled to produce a building, the desired outcome of an engagement. Ideally the building isn’t hacked together over a few days, but there is certainly the desire to complete the building upon a solid foundation over several weeks or months. Then the person moves on to the next building or leaves the organization with the goal accomplished.

As an internal Agile coach, the situation is quite different. Sometimes there is a specific short-term goal that needs to be accomplished quickly (e.g. launching a certain release train within the next 2 months), which requires functioning more like an external consultant, at least for some time. Apart from those circumstances, living as an internal coach inside an organization requires the newly hired coach to come in to build credibility and trust via relationships. Without these roots in the organization, the coach will not be successful. It’s about creating internal “pull” for coaching services aplantingnd getting people to see the value in coaching, so that that they will want to consume this service. A new person entering a company in this role will find himself in more of a “planting” mode where he’ll put various seeds in the ground in several locations and continue to water. This process will take time and patience and only few plants will spring out of the ground quickly. In most cases it may take months for the majority of plants to take root and then emerge from the soil. There are no guarantees and shortcuts to accelerate the process. Despite best efforts, not all seeds will come to life. With the coach building solid relationships, trust and “pull”, ultimately large plants with deep roots will flourish over time. These plants are a natural extension of the environment and will hopefully be able to weather storms and persist long-term. This is different from erected buildings, which are typically more like foreign objects in nature, with more shallow foundations, which may make them more susceptible to natural forces.

Being a successful internal coach is challenging and hopefully this mental model is helpful in describing the differences between an external Agile consultant vs. an internal Agile coach. A slightly different way to think about this is via the comparison to “missionaries vs. mercenaries”. Mercenaries (external consultants) are being dropped in a tense situation with a short-term mission in mind which often requires swift and sometimes drastic action. Missionaries, on the other hand, will approach things with more compassion and pay more attention to the human side. Their efforts will certainly also require more time and they’ll still be there to deal with the results of their early work – good or bad (while external consultants would likely have moved on already at that time). They have “skin in the game” and focus on the long-term best interest of their organization.

Don’t get me wrong, based on the situation, either mode can be appropriate and I certainly don’t want to diminish the approach and work of external consultants. A really good coach, external or internal, will be able to assess the circumstances and have the experience and skills to apply the correct approach. All that said, becoming a long-term internal coach requires a different perspective that may not be as obvious coming from the consulting world.