Agile Transformation

Tweet

Agile Transformation is a very complex process that impacts many organizational dimensions: vertically and horizontally.
Before proceeding with transformation efforts, every organization needs to determine who genuinely supports changes and who resists.  Frequently, resistance is well concealed under superficial layer of pretended support.  With people that resist, it is important to identify a root cause of their resistance and deal with it.  John Kotter explains this really well in less than 4 minutes.

Organizations decide to become more agile for various reasons: to deliver products of higher quality, to perform work at lower cost (higher ROI, Earned Value etc), to respond to market demands quicker (to stay ahead of their competition. Although each one these reasons, by itself, is a valid one, it is a combination of them, including some other important system factors, that make an organization truly agile and capable of “…turning on a dime for a dime…”. This includes everything: speed of delivery, cost effectiveness, product quality, customer satisfaction and workers’ happiness.

Luckily, there are not too many companies left out there that still think (and mistakenly) of agility as the thing that only technology “should do”. Today, more and more organizational leaders have come to understanding that in order to ensure long lasting and sustainable impact of agile transformation efforts, all organizational layers have to be engaged.

Any agile Transformation rests on a few fundamental pillars:

• In-depth understanding and support of agile values by senior management. Buy-in and support by organizational leadership is the key ingredient to success.  Organizational improvements will go only as far as an organizational leader will allow.
• Accumulation and retention of theoretical knowledge and expertise by people involved, at all organizational layers. This could come through self-education but a strong benefit from more structured in-class learning is strongly recommended
• Continuous support in the form for Enterprise- and Team-level coaching at multiple organizational levels: senior management, mid-level management and teams. It is worth noting that opting out of such support by senior organizational leaders (on merits of “we know what we need”) may potentially translate into disconnection between how they (senior leaders) see/understand agile transformation and how mid-level organizational layers and teams are being influenced by agile trainers and coaches.
• Readiness to address organizational impediments and systemic dysfunctions that an agile transformation may reveal. Agile frameworks are known for their ability to lower waters and bring to spotlight problems that have been hidden under covers for a long time.

Organizational transformations should always begin with thorough discussions between Senior Leadership and Transforming Agents (Organizational/Agile coaches). It is responsibility of a coach to disclaim to an organizational leader all possible implications of agile transformation (it should also cover the pillars above). An organizational leader should have clear understanding how agile may change his/her organizational design, reporting structures, culture and employment opportunities. Clear boundaries must be drawn around a leader’s zone of comfort and these boundaries must be candidly discussed with a transforming coach.

Once a coach receives an executive “go ahead” to proceed, it is usually advisable for a coach to perform Agile Transformation Readiness Assessment (coaches’ Discovery phase) during which he/she will study an organization, at various layers and domains, trying to define organizational state “as of today”, as an initial point of agile journey. The initial assessment phase may include things like: organizational reporting lines, geographic distribution, subject matter expertise nature of internal and external relationships, compensation, employee happiness/satisfaction factor etc.

Then, a coach and organizational leadership should discuss and agree on what part of an organization is going to pioneer transformation.

Organizational sample should be of right size, to ensure a right balance between breath and depth of effort:

• Selecting as sample that is too small may not produce sufficient systemic results, nor will it generate enough lessons learned
• Selecting as sample that is too large (“too big to swallow”) may cause too much of organizational turbulence and disorder: resistance might be too strong, while impact – too superficial.

(Note: The above decisions also depend on a number of organizational coaches-transformers involved and their level of synergy with one another.)

Guidelines for Agile Transformation “Sample Size”:

If an organization is willing to experiment very conservatively, by starting “small”, it may attempt “flipping” a single Product Development initiative/single Product Area that involves a very limited amount of people.  In conventional language, it is usually referred to as a “project”.   Most likely, this will take the form of a single team implementation, working for a small group of end-customers, represented by a single customer voice.

Below, are some common guidelines that are used to select an initiative for such experiment:

• Senior Management, on both sides (business and technology), is aware of the experiment and is fully supportive of it. This also assumes that Senior Management has proper expectations for such experiment and understands its potential benefits for overall organizational agility
• Product Development initiative is not mission-critical:
  • Inspection and adaptation is expected along the way
  • Early failures are anticipated and lessons learned are welcomed
• Product Development initiative is visible enough to attract attention and serve as a role model for other initiatives and teams
• Product Development initiative is based on well-defined Product Vision, Product Road-map and Strategic Planning
• Product requirements are not locked in stone: there is fluidity in scope
• Alternatively, if there is rigidity in scope, there is fluidity in time-frames
• Key: time-frames, scope and resources are not locked all at the same time
• It is acceptable to deliver Product incrementally, in small batches that are composed of independent features and functionalities; customers clearly see value in iterative development that shortens Cycle Time and allows for more frequent feedback
• Key: Business is able to identify an individual that can effectively serve the role of Product Owner (PO), having such individual:
  • Properly incentivized and motivated
  • Engaged and empowered to make priority decisions
• Business is able to identify an individual(s) that will serve the role of SMEs, while ensuring that such individual(s):
  • Informed and knowledgeable
  • Available to provide clarifications and guidance to technology and PO, on demand
• Development Team is properly structured:
  • Team is built on the principle of volunteered participation
  • Team size is 3-9 individuals
  • Team is fully collocated or optimally structured for geographic distribution (composed of T-shaped/cross-functional individuals)
  • Team demonstrates no elements or organizational hierarchy (organizational flatness)
  • Team members show no signs of command & control behavior toward each other
  • Team ScrumMaster is democratically elected and embraces the role
• Key: Development Team members are properly incentivized and motivated:
  • Collective Ownership and Team Performance are recognized and encouraged
  • Respectively, single-handed Ownership and Individual Performance are viewed as trivial and less relevant
• Development team is fully dedicated to Product Development initiative
  • Resource sharing is “null” or minimal
  • No attention distraction/side-work
• Development Team has been through formal education by Agile/Scrum Trainer and is supported (at least, initially) by Agile/Scrum Coach during initial steps of transformation journey

Please note that a single-team agile transformation (a.k.a. “flip”) is not a conclusive indicator or organizational ability to improve and sustain its overall agility.  Local, single-team, single-small-product development improvements may not last for long and there is a high chance that things will revert back to old norms, values and habits.  In order to ensure better continuity and sustainability of changes, a deeper, more systemic organizational impact is required. Such results are usually achieved with deeper, more systemic/scaled solutions that involve multiple teams and multiple business verticals, simultaneously.

Below, are some additional (on top of what is above) guidelines for scaled agile transformations:

• Senior Management, on both sides (business and technology), is fully aware of deep systemic implications that ‘agility at scale’ may require:
  • Organizational redesign/flattening (revisiting of organizational charts)
  • Bringing down walls of departmental silos; challenging sphere of control of certain individuals
  • Further de-emphasizing importance of “organizational ownership” (reporting relationships) for individual career development and compensation
  • Re-assessing roles & responsibilities of first-line management
• Key: Fundamentally reassessing how individuals get incentivized, compensated and promoted requires a departure from conventional norms and standards and is critical
• Deep understanding of Products
  • Differentiating between Product Development Types (External, Internal, Vendor-driven)
  • Differentiating between Product Components and Product Features
  • Differentiating between Development Areas and Product Areas

Periodically, and as per an agreement between organizational leadership and coach, assessments/health checks could be performed to ensure that an organization is on-track. It is also worth noting that going too fast from start does not necessarily mean that a pace will be maintained forever: an organization may stall soon after it takes off if efforts are too aggressive or breadth of efforts is dis-proportionally larger than depth. Agile assessments become of secondary importance if a feedback loop between organizational leadership and a coach is short and interaction is more intense. There, more iterative feedback is more valuable than point-in-time assessments.  Its ties very closely to one of Agile Manifesto postulates: “Individuals and Interactions, over Processes and Tools“

Finally, the ultimate goal of any agile transformation should be to bring about permanent organizational changes that can be sustained autonomously and independently by an organization itself, without continuously relying on a coach.

A good coach-transformer will make it his/her goal to avoid developing a long-lasting Coach-Coachee co-dependency and will strive to “coach himself out of a job”, by ensuring that an organization has gained its autonomy, mastery, purpose and internal expertise within reasonable time-frames.

 If you have any questions or seek advice about best ways to start agile transformation at your organization, please contact me directly.