Category Archives: Organizational Design

Proper Scaling of Scrum and Dynamic Financial Forecasting


The purpose of this post is to summarize two very important and independent topics and then integrate them together, into a joint discussion.  The topics are:

  1. Moving from rigid annual budgets to rolling forecasts (super important! in agile/adaptive product development environments)
  2. Quality of scaling in agile product development, specifically Scrum

…and tying effective scaling of Scrum to dynamic financial forecasting.


Rigid Annual Budgets vs. Dynamic/Rolling-Wave Forecasting

Challenges presented by rigid annual budgets have been known for a long time.  For people that are new to the topic, a great way to stay on top of most recent research and publications, is to follow what is going at BBRT.org (Beyond Budgeting Round Table).  One of BBRT’s core team members – Bjarte Bogsnes, in his book “Implementing Beyond Budgeting: Unlocking the Performance Potential” (please, refer to the book’s highlights here),  clearly summarizes the problems with conventional, end-of-year rigid budgets. They are as follows:

  1. Budgets represent a retrospective look at past situation and conditions that may not be applicable in a future
  2. Assumptions made as a part of a budgeting process, even if somewhere accurate at the beginning, get quickly outdated
  3. Budgeting, in general, is very time-consuming process, and it adds additional, financial overhead to organizations
  4. Rigid budgets, can prevent important, value adding-activities, and often lead to fear of experimenting, researching and innovating (crucial for incremental development)
  5. Budget reports are frequently based on subjective metrics, as they take on the form of RAG statuses, with the latter, introducing additional errors and omissions (for details, please refer to Red, Yellow, Green or RYG/RAG Reports: How They Hide the Truth, by M. Levison and The Fallacy of Red, Amber, Green Reporting, by G. Gendel)
  6. Budgets, when used as a yardstick to assess individual performance, often lead to unethical behaviors (e.g. “churning & burning cash”at year-end to get as much or more next year) or other system-gaming activities

…The list of adverse effects caused by traditional budgeting is long…

On contrary, a rolling-wave forecast, respects the fact that environmental conditions are almost never static, and recognizes that if too much reliance is placed on prior years’ financial situation, it may lead to miscalculations.  Rolling-wave forecasts are based on frequent reassessment of a small handful of strong KPIs, as oppose to large number of weak KPIs, as frequently done in conventional budgeting..  The more frequently forecasts are being made, the higher chance that most relevant/reliable information will be used in assessments.  One good way to decide on cadence of rolling forecasts is to align them with meaningful business-driven events (e.g. merchandise shipments, production code deployments, etc.).  It is natural to assume that for incremental/iterative product development (e.g. Scrum), when production deployments are made frequently and in small batches, rolling-wave forecasting could be a concurrent financial process.  Short cycle time of market feedback could provide good guidance to future funding decisions.

It is worth noting that one of the key challenges that Scrum teams face today, is the “iron triangle” of conventional project management, with all three of its corners (time, scope, budget) being rigidly locked. And while the most common approach in Scrum is to make scope flexible, ‘clipping’ the budget corner brings additional advantage to teams.  Above all other benefits, rolling-wave forecasts address the problem described in #4 above, as they provide safety to those teams that want to innovate and experiment.

But what if there not one but many Scrum teams, each working on their own initiatives, running under different cadences (asynchronized sprints) and servicing different customers?  How many independent rolling-wave forecasts can one organization or department adopt before things become too complicated?  What is too much and where to draw a line?

Before we try to answer this question, let’s review what is frequently seen, when organizations attempt to scale scrum.

 

Proper Scaling vs. “Copy-Paste” Scaling

Let’s look at the following two situations: (1) more than one Scrum team, independently, doing their own Scrum and (2) more than one Scrum team, working synchronously, on the same product, for the same customer, sharing the same product backlog and domain knowledge.  The former case, is referred to as “Copy-Paste” Scrum, clearly described by Cesario Ramos. The latter case can be seen in skillful Large Scale Scrum (LeSS) adoptions. Here are some of the most classic characteristics of both scaling approaches:

(1) – “Copy-Paste” Scrum (2) – Large Scale Scrum (LeSS) 
  • Product definition is weak. Applications and components that don’t have strong customer alignment are treated as products
  • “Doing Scrum” efforts are often a result of trying to meet goals of agile transformation (some annual % goals must be met), set at enterprise level
  • Tight subsystem code ownership
  • Top-down, “command & control” governance, with little autonomy and self-management at team level
  • Importance of Scrum dynamics and its roles are viewed as secondary to existing organizational structure blueprints
  • Too many single-specialty experts and very few T-shaped workers
  • No meaningful HR changes to support Scrum team design
  • Simplified organizational design. Reduction of: silos, handovers, translation layers and  bureaucracy
  • Scrum is implemented by coordinated, feature-centric teams, working on  widely defined Product, for the same PO.
  •  Local Optimization by single specialists is eradicated
  • Scrum is a building block of IT organizational structure
  • Teams are collocated Multi-site development is used for multiple locations
  • Strong reliance of technical Mentoring and Communities of Practice
  • No subsystem code ownership
  • Reduction of “undone” work and “undone department”
  • Focus on Customer values
  • Strong support by Senior Leadership & intimate involvement of HR

Note: Please refer to Scaling Organizational Adaptiveness (a.k.a. “Agility”) with Large Scale Scrum (LeSS) for additional graphic illustration.

Based on the above, the following also becomes apparent:

In “copy-paste” Scrum, development efforts, marketing strategies and sales (ROI) are not treated as constituents of the same unified ecosystem.  In this scenario, it is almost impossible to fund teams by means of funding real, customer-centric products.  Why?  There are too many independent ad-hoc activities that take place and artifacts that are created.  There is no uniformed understanding of work size and complexity that is shared by all teams.  Estimation and forecasting made by each individual team is not understood by other teams.  Team stability (and subsequently, cost-per-team member) is low, as individuals are moved around from project to project and shared across many projects.  Further, with multiple teams reporting into different lines of management, there is a much higher chance of internal competition for budget.  By the same token, there is a low chance that a real paying customer would be able to step in and influence funding decisions for any given team: too many independent and competing requests are going on at the same time.

In organizations, where “copy-paste” Scrum is seen (and is often, mistakenly taken for scaled scrum, due to lack of education and expert-leadership), there is still strong preference for fake programs and fake portfolio management.  Under such conditions, unrelated activities and, subsequently, data/metrics (often fudged and RAG-ed) are collected from all over the organization and “stapled” together.   All this information rolls up to senior leadership, customers and sponsors.  Subsequently, what rolls down, is not dynamic funding of well-defined customer-centric, revenue-generating products, but rather rigid budgets for large portfolios and programs that are composed of loosely coupled working initiatives, performed by unrelated Scrum teams (secondary, to conventional departmental budgeting).  As rigid budgets cascade down from top, onto individual teams, they further solidify the “iron triangle” of conventional project management and hinder teams’ ability to do research, experimentation and adaptive planning.

On the other hand, in Large Scale Scrum, things are different:

  • When up-to-eight LeSS teams work synchronously, together (side-by-side), on the same widely-defined product (real), their shared understanding of work type and complexity (having certain scrum events together really helps!) is significantly better. As a result, when it comes to forecasting a completion of certain work (features), eight LeSS teams will do a better job than eight loosely coupled teams that work completely independently, on unrelated initiatives.
  • Since all LeSS teams work for the same customer (Product Owner), there is a much higher chance that they will develop a shared understanding of product vision and strategy, since they are getting it from an authentic source – and therefore will be able to do planning more effectively.
  • Having more direct correlation between development efforts LeSS teams (output, in the form of shared PSPI) and business impact (outcome, in the form of overall ROI), makes strategic decisions about funding much more thoughtful.  When real customers can directly sponsor product-centric development efforts, by getting real-time feedback from a market place and deciding on future strategy, they (customers) become much more interested in dynamic forecasting, as it allows them to invest into what makes most sense.  Dynamic forecasting of LeSS, allows to increase/decrease number of scrum teams involved in product development flexibly, by responding to increased/decreased market demands and/or product expansion/contraction.

Noteworthy that in LeSS Huge cases, when product breadth has outgrown capacity of a single Product Owner and requires work by more than eight teams, dynamic forecasting can still be a great approach for Product (overall) Owner and Area Product owners (APO): they can strategize funding of different product areas and make necessary timely adjustments to each area size/grown, as market conditions change.


Conclusion:

All of the above, as described in LeSS scenario, will decrease organizational dependency on fixed budgets, as there will be less interest in outdated financial information, in favor of flexibility, provided by rolling-wave forecasting that brings much closer together “the concept” (where value is built – teams) and “cash” (where, value is consumed – customers).

December 6th-8th: Certified LeSS Practitioner Course With Craig Larman | NYC


Another Large-Scale Scrum Training (CLP), taught by Craig Larman in NYC, is in the CompuBox.

More than thirty people from all-around the globe (North America, South America, Europe) came together for this brain-jelling learning experience! The group consisted of product owners/managers, software engineers, managers and organizational design consultants (scrum masters, coaches and trainers) – people coming from different backgrounds and with a focus on different aspects of organizational agility. What has united them all, however, was their eagerness to learn in-depth about principles of organizational design and implications of Scrum adoption at scale in complex organizational settings.

Course Highlights

With exception of a few rare questions/clarifications, the class spent NO time discussing basic Scrum.  It was implicit (assumed) that everyone in class had strong knowledge and hands-on experience with the basic framework.  On occasions, the topics discussed would bump into “…oh this is not even LeSS-specific; this is just basic Scrum…” but those cases were rare.

Not until day three,is when the class took a deeper dive into LeSS Framework and LeSS-specific events, artifacts, roles…. Why was not it done sooner?   Well…

  • LeSS is Scrum. It is the same very Scrum described by Ken Schwaber and Jeff Sutherland in the Scrum Guide, but done by multiple teams, as they are working together, on the same product, for the same product owner.  LeSS is not “…something that IT does, that is buried in a company’s basement, under many layers of organizational complexity…”. LeSS is an organizational design that uses Scrum (team) as a building block.  Understanding basic Scrum made understanding of LeSS very easy for everyone.
  • The class was made of people that have completed all assigned homework (self-study), before attending. People knew what LeSS picture looks like 😉, when coming in.  Everyone in class was an educated customer.  Importantly: there were no attempts to change LeSS (or change training content 😊  of LeSS), to make it better fit conditions of organizations, where people came from.
  • Spending the first two days on understanding system modelling techniques, differences between causation and correlation (as well as other dynamics) among many system variables, made full understanding of LeSS on day three, come more naturally.

The class learned how to see ‘the whole’/full picture of organizational ecosystem and learned to appreciate why Organizational Design is the first-order Variable that defines System Dynamics (followed by everything else: culture, policies, norms, processes, etc.)

One of my (Gene) biggest take-away points (on the top of an excellent LeSS refresher, from Craig himself), that I plan on using immediately, was the fact from history that was discussed at the beginning of the course (and, sadly, forgotten or known known by many).  And it goes as follows:

…Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with what is known today as ‘Agile Manifesto’, the two contending terms to-be-used were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle).  ‘Agile’ won because of the reasons that are described here.  Truth be told, because the English meaning of ‘agile’ is not as intuitive is the meaning of ‘adaptive’, today, there is a huge number of fads and terminology overloading/misuse that make the original meaning of agile so diluted and abused…. As it was meant to be: Agile == Adaptive ==Flexible.  We all have to be careful with the meaning of words we use, to avoid this painful irony😉.


Here are some Kodak moments from the event:

NYC Salary History Ban – What Does it Mean?


On October 31-st, 2017, the Mayor of NYC Bill de Blasio signed the new Law, prohibiting companies in New York City from asking, searching or verifying a job applicant’s salary history during the hiring process.  From now on, violation of this law, by any NYC-based employer, will be viewed as an “unlawful discriminatory practice.”
(Please, read more about the NYC Salary History Ban.)

Below are some potential, consequences of this Law, as it applies to any employees-candidates and any NYC-based employing organizations:

  • If an individual has worked for a long time at the same company and, while employed, has acquired a lot of practical experience/skill set, but unfortunately was not able to secure compensation that was an objective reflection of her capabilities/expertise, she may now seek an employment at another company without worrying that prior, unfairly low compensation, will be a benchmark for her future offer.
  • If an individual is a self-starter/entrepreneur who has acquired a lot of knowledge/experience in ways, other than formal employment (e.g. self-paid study or research) and by doing so, has significantly increased her professional maturity, she may confidently leverage these rightfully owned credentials , when negotiating a salary with her next employer.
  • If an individual’s goal has always been to remain as a hands-on contributor (she loved what she did, and did not want to lose her practical skills) and was never aspired to seek a promotional/managerial position – something that usually leads to higher compensation, she may do so more freely, without worrying that she will miss out on a “compensation-bargaining-chip”, at her next job interview.  This also means that employees will be more experience/knowledge-seeking and less promotion-seeking, as it is really an experience, not prior organizational position that define their true self-selling power.  (note: often, promotions are associated with loss of hands-on expertise, in favor of managerial/administrative responsibilities).
  • If an individual’s full compensation consists of base salary and discretionary bonus (the latter, often being too subjective, as it is based on individual performance appraisals, efficiency of which have been proven as ineffective, for many decades), with a bonus, representing a significant chunk of her full salary, she does not have to be concerned so much with her next employer, trying to count in only her base salary,  as a ‘benchmark’ , while making an offer.  This will also, hopefully, drive companies towards paying higher base salaries, and away from subjective bonuses.
  • Recruiting agencies and staffing firms will have fewer opportunities to ask unethical questions (“how much were/are you making at your prior/current job?”), something that is often delegated to them by companies’ HR departments, with the ladder not wanting to be directly associated with unethical behaviors.  Further, this may lead to more transparency and direct interaction between hiring managers and candidates.
  • Companies-employers would have to improve their vetting/interviewing/hiring approaches significantly, by incorporating validation methods and more reliable/objective assessments of candidates, to prevent under-qualified, low-skilled individuals (some of whom may have strong negotiations and “talking the talk” skills) from slipping through companies’ doors and causing internal problems.  This may require conducting more practical tests, real-life simulations and hands-on exercises, administered directly by hiring areas and peers-coworkers. Further, this could also reduce an amount of subjective/administrative, error-prone and often unnecessary screening processes, usually handled by companies’ departments that are least benefited from hiring high-quality candidates, but at the same time, most benefited from creating and administering actual processes 🙂

In all the above situations, the main compensation-determining factors will be:

  • From an employee’s perspective: her professional competency, skill/mind set, ability to produce tangible results and deliver business value
  • From an employer’s perspective: ability to properly assess a candidate for what she is worth (not for what she was price-tagged in her past) AND clear understanding of how much an employer is willing to pay for a given job/to a given candidate

The natural question that comes to mind:  Does the new Law have any relevance to internal hiring situations (when employees move around a company)?  

According to the Employer Fact Sheet, the Law does not apply directly to internal re-employment (also, for most companies, employees’ compensation is transparent to hiring managers of the same company).

However….  There could be some indirect implication: NYC-based employers will probably realize that properly educated (know the Law) employees will have more confidence to ask a higher pay, when they seek a new employment internally.  The new “compensation-bargaining chip” for employees will be their increased self-confidence that they will be able to get a higher compensation elsewhere, irrespective of their current compensation (should their internal efforts not materialize).  As a result, to avoid losing good people to their direct competitors, employers will probably revisit their compensation increase standards, with regards to internal  re-employments.

Addressing Problems, Caused by AMMS


Nowadays, for too many organizations, Agile Maturity Metrics (AMM) have become a trusted way to measure improvements of agility at personal (individuals), team and organizational level.

However, it is not always apparent to everyone that AMMs are different from Agile Check-Lists (e.g. classic example of Scrum Check list by H. Kniberg) and this can often lead to problems and dysfunctions:

Check-Lists are just a set of attributes that are usually viewed on-par with one another; they are not bucketed into states of maturity (other logical grouping could be applied though)

On contrary, AMMs place attributes in buckets that represent different states of maturity, with one state, following another, sequentially.

With very rare exceptions (favorably designed organizational ecosystems), there are three potential challenges that companies face, when relying on bucketed AMMs:

1 – System Gaming: If achieving a higher degree of agile maturity is coupled with monetary incentives/perks or other political gains (for many companies that are driven by scorecards and metrics, this is the case), there is will be always attempts by individuals/teams to claim successes/achievements by ‘playing the system’, in pursuit of recognition and a prize.

2 – Attribute-to-Maturity Level relationship is conditional, at most: Placing agile attributes in maturity buckets implies that attributes in higher-maturity buckets have more weight than attributes in lower-maturity buckets. However, this is not always a fair assumption: weight/importance that every organization/team places on any given attribute, while defining its own maturity, is unique to that organization/teamFor example, for one team, “…being fully co-located and cross-functional…” could be much more important than “…having Product Owner collocated with a team…” For another team, it could be the other way around.

3 – Correlation between attributes is not linear, at system-level: Regardless of buckets they are placed in, many agile attributes are interrelated systemically and impact one another in ways that is not apparent, to a naked eye.  For example, placing “Scrum Master is effective in resolving impediments”attribute in a maturity bucket that comes before the maturity bucket with “…Organization provides strong support, recognition and career path to Scrum Master role…” attribute, dismisses the real cause-and-effect relationship between these two variables, misleads and sets false expectations.

To avoid the issues described above, it would be more advisable to treat every identified agile attribute as a system variable, that is on-par with other system variables, while assuming that it has upstream and downstream relationship.  In many situations, instead of spending a lot time and resources on trying to improve a downstream variable (e.g.  trying to understand why it is so difficult to prioritize a backlog) it is more practical to fix an upstream variable that has much deeper systemic roots (e.g. finding an empowered and engaged product owner who has as the right to set priorities).

Below, is the list of agile attributes (a.k.a. system variables) that are logically grouped (check-list) but are not pre-assigned to levels of maturity (all flat).   Some examples  of suggested system-level correlation between different attributes are provided (cells are pre-populated).

Please, click on the image to download the matrix to your desktop, amend the list of attributes if you feel that your situation calls for modification, and then use “Dependency on Other Attributes?” column to better visualize system-level correlation between the attributes are of interest to you and other related attributes (some examples are provided).

10/13 – LESS TALKS: MEETUP – Working LeSS Brings Great Results (Case Study)


Tonight -a  great presentation by Malik Graves-Pryor of Natoma Consulting, as he shared how his company leveraged LeSS to achieve  stunning results, while facing challenges and learning lessons.

Malik’s Summary

At the Thursday October 12, 2017 NYC Large Scale Scrum Meetup, Malik Graves-Pryor shared his company’s LeSS case study, “Web and Mobile Applications Agile Transformation”. He covered the extensive issues the company faced at the beginning ranging from only 1-2 releases a year with hundreds of defects, and how they transformed over the course of several months to an organization that released monthly, and then continuously, with low defects and high customer satisfaction and engagement.

The discussion covered the merger of the Sales and Product Management Pipelines, adoption of technical practices leading to a DevOps-focused culture, how to take the necessary steps to build trust and cooperation within the organization, as well as the road-map they used to iteratively migrate the organization to continuous integration and deployment.

The interactive discussion spanned two hours with attendees raising questions and issues about the case study, as well as correlating them with their own challenges and aspirations.

Presentation deck is available at  Natoma Consulting website for download.

 

What Should Agile Leadership Care About?


Agile frameworks (e.g. Scrum, Kanban, XP), individuals’ roles & responsibilities, processes & tools, metrics & reporting, burn-up charts, estimation techniques, backlog prioritization, agile engineering practices, agile maturity models etc. – all of them are important attributes of a typical agile transformation.  However, NONE of them are first-degree-of-importance system variables that are responsible for transformation success.  Most of them, are good superficial lagging indicators of agility but they are all corollary (secondary and tertiary) to another much more important system variable.

What is the most important system variable that defines a company’s agility?  It is Organizational Design –  the most deeply rooted element of organizational ecosystem that defines most of system dynamics.

When organizational leadership decides to take an organization through an agile transformation journey (it could take years, sometimes), it [leadership] needs to acknowledge that real, sustainable agile changes are only possible if deep, systemic organizational improvements are being made.  For that, leadership needs to be prepared to provide to its organization much more than just support in spirit, accompanied organizational messages of encouragement and statements of vision.  Leadership must be prepared to intimately engage with the rest of an organization, by doing a lot of real “gemba” (genchi genbutsu (現地現物)) and change/challenge things that for decades, and sometimes for centuries, have been treated as de-facto.

What does it really mean for leadership to engage at System Level?  First, it is important to identify what a system is: what are a system’s outer boundaries?  For example, one of the most commonly seen mistakes that companies make when they decide on “scope of agile transformation” is limiting its efforts to a stand-alone organizational vertical, e.g. Technology – and just focusing there.  Although this could bring a lot of local (to IT) success, it may also create unforeseen and undesirable friction between the part of an organization that has decided to change (IT) and the part of an organization that decided to remain ‘as is’ (e.g. Operations, Marketing).  For example, if Scrum teams successfully adopt CI/CD, TDD or other effective engineering practices that enable them deliver PSPI at the end of every sprint, but business is not able to keep up with consumption of deliverables (too many approvals, sign offs, red tape) then the whole purpose of delivering early and often gets defeated.  Then, instead of delivering to customers soon, in exchange for timely feedback, teams end up delivering in large batches and too far apart on a time scale.

A successful Agile Leader must treat an organization, that is expected to transform, as a sushi roll.  Just like seaweed alone does not provide a full spectrum of flavors and does not represent a complete, healthy meal, one single department (e.g. IT) is not sufficient enough to participate in agile transformation efforts.  Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment.  A slice does not have be too thick. In fact, if organizational slice is too thick, it might be too big to “swallow and digest”.  But still, even when sliced thinly, an organization must include enough layers, to be considered as a ‘complete meal’.

Note: A great example of treating an organization as a sushi role, while making it more agile, is Large Scale Scrum (LeSS) adoption.

So, what are some key focus areas that every Agile Leader must keep in mind, while setting an organization on agile transformation course?

  • Location strategies. Geographic locations.
  • HR policies (e.g. career growth opportunities, compensation, promotions)
  • Budgeting & Finance
  • Intra-departmental internal boundaries and spheres of influence
  • Organizational Leadership Style
  • And some other areas that historically have been considered as …untouchable

All the above listed areas are defined by Organizational Design and can be better understood through self-assessment, done by organizational leaders at all levels.

Agile Organization, as a Sushi Roll


When we ask an experienced Scrum developer what defines a good User Story, the answer we hear almost immediately is that “…every user story must be INVEST-able…(taken from B. Hartman’s post)”.

When we further elaborate on “INVEST” part, we hear that splitting user stories should be done Vertically (along features), not Horizontally (along components or applications layers).  Why is the latter condition so important? Because when split vertically, and cross-cutting through multiple components, a user story has a much higher chance of representing a potentially shippable product increment (PSPI).  Delivering, UI/UX alone, or business layer alone, or database alone, does not present value to a buying customer.

Frequently, we hear the analogy of a sushi roll, when describing story slicing: “…every User Story must represent thinly sliced sushi roll that provides taste and flavor of multiple layers (caviar, seaweed, rice, tuna, avocado, etc)…


…Now, imagine an organization that is undergoing agile transformation.  Predominantly (statistically), transformation efforts stem from Technology, where agile improvements come in the form of introducing good engineering practices, such CI/CD, TDD, unit testing, test automation, automatic deployments, etc.  But technology alone, is just one layer of an organizational sushi roll.  Sure, just like seaweed alone, it may be tasty enough for starters, but without adding additional flavors, it is not a complete, healthy meal.

Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment.  A slice does not have be too thick. If organizational slice is too thick, it might be too big to “swallow and digest”.  But still, even when sliced thinly, an organization must include enough layers, to be considered as complete meal.

What are some of those layers?  Let’s consider a few:

Business & Operations:  it is imperative to have real customers intimately involved in agile transformation efforts and making them closely aligned with technology partners. This requires identifying and providing a strong support for some key agile roles, such as product owner, stakeholders and SMEs.  Often, this requires organizational realignment and changes to sphere of influence.

HR:  Subjective monetary rewards that are based on individual performance assessments and fueled by invisible internal competition among employees, must be discontinued, in favor of incentives that promote teams’ collective ownership and performance.  An organizational slice that wants to become more agile will have a much higher chance for success if HR policies were genuinely supportive of the initiative of the efforts.

Budgeting & Finance: For agile teams (Scrum, Kanban) that use adaptive planning and iterative development, and continuously have their work re-prioritized by business, it is imperative to have flexible budgets (“flexible spending”).  By unlocking a rigid budget corner of what is known as Project Management Iron Triangle (budget, scope, timeline), technology dramatically increases their chances to do research or conduct new experiments, if an opportunity presents itself (often, unexpectedly).  There is also a higher chance that more Scrum teams would be built out faster, if budgets were flexible and not done as ‘budgets against the wall’ (‘the world ends on December 31st’) – more flexibility to acquire new talent.

Real Estate & Facilities: Having agile teams co-located under the same roof is a huge win: e.g. Scrum team dispersed around the globe is not as good as Scrum team placed on the same floor. (Note: Please, do not confuse a single Scrum team spread thin across multiple locations with multi-site Scrum product development, when many, whole teams are collocated but separated from from peers-teams by geography).

However, putting a team on the same floor is not sufficient.   Interior design must be supportive of team collaboration and dynamics: ‘caves & common’ (read A. Cockburn about XP), information radiation techniques (lots of whiteboard space, flip-charts), breakout areas, extra space to accommodate extended user community during sprint reviews, etc. – is all required.  It is unfortunate but common to see so-called Scrum team members sitting in a long single row, next to each other, spear-headed by a line manager (usually, a window seat), all joining a daily stand-up call by phone (while sitting!) and ‘reporting on status’, while staring at an electronic story board on their respective monitors.  Agile teams don’t want that.


As a summary, please consider the following quote that describes sushi-roll-like organizational design in Large Scale Scrum (LeSS), by C. Larman:

“Who are the Judges?” Who Decides on Who is Gonna Coach?


Lets kick off this post with the quote from another recent discussion that generated a number of strong comments from experienced professionals:

“…as long as companies remain complacent and reliant on outlived staffing/head-hunting approaches, cold-calling techniques, and ineffective HR-screening processes, performed by people that poorly understand the essence of an agile coaching profession, while trying to procure cheap “agile” resources (using “preferred vendor lists”) or treat seasoned professional coaches, as “requisitions to be filled”,  a coaching bar will remain low, and companies will be getting EXACTLY  what they have paid for: coaches-centaurs (p.17)…”

 

To summarize, the purpose of the above referenced discussion was to increase awareness about implications of ineffective coaches and coaching that exists in abundance today.  Here, lets look at some root causes why this problem exists.

Who Defines the role of Agile Coach?

For the most part, organizational understanding of a coaching role is weak.  Definitions of a coaching role that flow around, suggest that companies are still confused about what coaches do.  Definition of a coaching role is frequently lumped together with the role of a project manager, team lead, business analyst, Jira/Rally/VersionOne administrator etc. While some of these other roles, could represent potentially relevant past experience for a coach, lumping all of them together in one all-inclusive role description, delimiting them by a commas or forward slashes 😊, is ironic, to say the least.  Many of these “ace pilot/submarine captain/NHL star” roles create a conflict of interest not just for people that step into them but for everyone else who gets affected by interaction.  Very often, inaccurate definition of a coaching role leads to inappropriate behaviors by a coach, such as attempts to seek authority and organizational power, exhibition of command & control behavior, competition with people being coached for ownership of deliverables, monetary incentives and other perks.

Once a poorly-defined coaching role description hits the street, it enters a vicious cycle – reinforcing feedback loop.  (described in detail here ):

(Note: the above illustration excludes other system variables that may have effect on the variables and variables’ relationships shown above).

This vicious cycle usually leads to one inevitable result: over-time (usually months; sometimes a few years) companies realize that agile coaching did not bring about enough sustainable organizational improvements, as it was expected.  This further leads to two outcomes, both of which dependent of senior leadership vision and goals:

  • Companies seriously re-assess their own initial actions, acknowledge mistakes made, and then improve coaching standards and elevate the bar in favor of real, experienced coaches
  • Companies, try to water down mistakes they have made, trivialize a coaching role for a lack of it’s benefit and, and by doing so, further reinforce the loop above
Who Really Makes Decisions and Why?

Rarely, senior executives take an active role in a coaching hiring process; exceptions exist but they are rare (usually,  exceptions are seen when things become very urgent – page 14).  But even when they [executives] do engage in the process, it is usually more the act of a formality, to ensure that a hired person “fits the culture”. Of course, and very ironically, one of the key expectations from an experienced coach should be to challenge an organizational structure (both, at enterprise and team level), and since culture is corollary to structure (Larman’s Law # 5), the latter would change (would be challenged) as well.  But this is not something that too many senior executives would like to hear.

For the most part, a hiring process is delegated to first- and sometimes second-line management, as well as internal agile champions that oversee and own agile transformations.  While Larman’s Law # 1, historically, has defined the attitude of middle management towards fundamental changes that challenge a status-quo, the recently added Law # 4 neatly describes “contribution” by some internal agile champions.  And while exceptions do exist, trends and statistics speak louder.

Let’s imagine the process by which an organization wanted to hire an agile coach (as employee or consultant – no difference):
In this process, the interviewers – are individuals described in Larman’s Law # 1 and # 4.   On the other hand, an interviewee, is a seasoned agile coach, with long enterprise- and team-level track record: she is a system thinker, dysfunctions challenger, a real organizational change agent.

Impact on a hiring process by Larman’s Law # 1-type Interviewers:

At an interview, a coach-candidate meets with first- and/or second-line managers that also expect that a coach will report into them, when she joins a company.  During a discussion, interviewers hear from a coach certain things that coaches usually bring up, uninhibitedly:

  • Simplified overall organizational structure, where developers receive requirements and communicate on progress, by interacting directly with end customers, not middle-men
  • Flattened team structure, where developers self-organize and self-manage. Overall reduction of supervision and resource management, in favor of increased autonomy, mastery and purpose, by individuals that do work
  • Harmful effects of individual performance appraisals and subjective monetary incentives, especially in environments, where team commitments and team deliveries are expected

Unsurprisingly, the biggest question that many interviewers walk out with, after interviewing such a candidate is: “What will my role be like, if this coach is hired and brings about above mentioned organizational changes?

 

Impact on a hiring process by Larman’s Law # 4 -type Interviewers:

Knowledge and experience of a coach-candidate supersedes that of internal agile champions and process owners.  Some of the discussions a coach elicits, and answers provides, by far exceed expectations (not to be confused with a term used in a performance appraisal process 🙁 !) of her interviewers.  Some suggestions and ideas shared by a candidate are a great food for thought for senior executives but not at a level, where Larman’s Law # 4-type coaches are authorized to operate.  Interviewers clearly see that a coach-candidate, if on-boarded, soon may become a more visible, influential contributor than the interviewers themselves.   A coach may also bring about some organizational turbulence that will take out of comfort zone some individuals that are resistant to changes.

What are the odds that this experienced coach-candidate will be given a “pass”? What are the odds that she will be even given a chance to speak to senior executives involved in a hiring process, to attempt to influence them,  to open their eyes, to offer a deeper system perspective on a situation, to make them think and talk about the forbidden?

Slim-to-none. 

And this is one of the ways, in which organizations that are complacent about agile improvements, shoot themselves in a foot: they very effectively disqualify qualified agile coaches and by doing so, reinforce the feedback loop illustrated above😉.

You Get What you Ask For: Agile Coaches-“Centaurs”


Why are there so many troubled agile “transformations”?  We frequently hear the following answer: “because companies lack senior leadership support”.  True.  And let’s not trivialize this: without strong and genuine support by senior leadership (beyond slogans and “support in spirit”), without selecting a deep, systemic approach to problem resolution, companies can only expect localized, peripheral and, most likely, short-term improvements.

But is there anything/anyone else that can be conveniently held accountable for failed agile transformations?

How about ineffective agile training and coaching?  [Note: If you are interested in learning more about some of the most common challenges with agile training, please visit this page.  This post is about coaching .]

…There is a vicious cycle that hurts so many companies (can be also considered as a self-inflicted wound):

initially, companies set a low bar for coaches, based on poor understanding of a coaching role  low quality coaches (quasi-coaches-“centaurs”) are hired, most of whom are not even coaches, but rather people that have mastered agile jargon and know how to impress HR and uninformed hiring managers  weak coaches (most of whom have minds of conformists, not challengers) cannot effectively guide companies to fix systemic weaknesses and dysfunctions  teams and departments  don’t really improve; rather create a superficial appearance/illusion of progress (often, to impress senior management)  companies lose faith and stop seeing value in coaching → companies start trivializing a coaching role  companies decide not to spend more money on high quality coaching cheaper, even less effective, coaches are hired (or internal, misplaced people are refurbished into coaches, overnight, as per Larman’s Law # 4) initially, low-set coaching bar, is lowered even further…and so on….

Graphically, it looks something like this:

As a result, what was initially meant as a strategic organization- improvement effort, now takes on a form of just another system-gaming change management fad that ultimately leads to a failure and responsibility/blame-shifting.

What are some of the reasons why the above happens?  Here are some suggested reasons:

  • Companies don’t understand the essence of agile coaching role: it is viewed as another “turn-on switch” management function
  • Leadership does not feel a sense of urgency (p. 14) to make changes and exempts itself from being coached: people are too busy and too senior to be coached; they find coaching trivial
  • Certain organizational pockets are genuinely resistant to/feared of changes that can be brought about by real coaches (as per Larman’s Laws 1 – 3)
  • Market over-saturation with unskilled recruiters that hunt for low-quality coaches and contribute to the above cycle: this further lowers a company’s chances to find a good coach
  • This list can be extended….

Who is responsible for initiating this vicious cyclic dysfunction?  Does it really matter if we identify guilty ones?  Maybe it does, but only, as a lessons-learning exercise.  What probably matters more is how to break out of this cycle.  Where to start: discontinue low-quality supply (coaches) or raise a bar on demand (by companies)?  Usually, demand drives supply and if so, for as long as companies remain complacent and reliant on outlived staffing/head-hunting approaches, cold-calling techniques, and ineffective HR-screening processes, performed by people that poorly understand the essence of an agile coaching profession, while trying to procure cheap “agile” resources or treat seasoned professional coaches, as “requisitions to be filled”,  a coaching bar will remain low, and companies will be getting EXACTLY  what they have paid for: coaches-centaurs (p.17).

Big question

What should companies be looking for when hiring a coach?”

An organization should be looking much father and beyond of what is typically presented in a resume or a public profile of a candidate: usually, a chronological list of an employment history or a long list of google-able terms & definitions,  popular jargon or claims of experience in resolving deep, systemic organizational challenges with Jira configurations 😊.  Much more attention should be paid to the following important quantitative characteristics of a coach:

Coaching Focus: What is an approach and/or philosophy to coaching does a coach have?  This will help a company understand an individual mindset of a coach.

Coaching Education AND Mentorship: What active journey through education, mentorship and collaborative learning in coaching and related activities over significant period has a coach taken?

Formal Coaching Education: What has contributed significantly to a person’s coaching journey, including courses on topics of facilitation, leadership, consulting, coaching, process, and other related activities which have influenced a person’s coaching practice? Such education may not have to be degree-related (training and/or certification from any recognized institution could be sufficient).

Coaching Mentorship & Collaboration: How a coach developed a skill/technique or received guidance to a coaching approach and mindset?  Respect and recognition of mentors – matters here.

Informal Coaching Learning: What important topics outside of Agile/Scrum literature have impacted a person’s coaching philosophy?  This increases chances that a coach is well-rounded, beyond standardized book learning.

Agile Community Engagement & Leadership:  Does a coach engage in agile user groups, gatherings, retreats, camps, conferences, as well as writing, publishing, reviewing, presenting, facilitating, training, mentoring, organizing, and leading agile events?  An active participation and leadership in the agile community is a good demonstration that a coach has not developed herself within a unique organizational silo, by self-proclaiming and self-promoting, but rather has diverse and ‘tested’  industry experience.

Agile Community Collaborative Mentoring & Advisory: Does a coach mentor or advise other individuals (not for pay) on how to increase their competency or development?  Is a relationship on-going, purposeful and bi-directionally educational?

Coaching Tools, Techniques and Frameworks: Does a coach develop awareness and understanding of tools, techniques and frameworks while engaging with organizations?  Has she customized or developed anything that was client/engagement-specific?

In addition to quantitative characteristics , here are qualitative characteristics of a good coach:

Coaching Mindset
  • How does a coach react when an outcome of coaching was different from what she had desired? In the past, how did a coach address this situation?
  • How, based on clients’ needs, a coaching mindset had to change? In the past, what compromises did a coach make? What was learned?
  • What new techniques or skills did a coach learn, to meet a client’s needs?
Coaching Competencies
  • Assess – Discovery & Direction
  • Balance – Coaching & Consulting
  • Catalyze – Leadership & Organizations
  • Facilitate – Focus & Alignment
  • Educate – Awareness & Understanding
Coaching Specialties
  • Lean / Kanban
  • User Experience / Design
  • Scaling Agile / Enterprise Agility
  • Technical / Quality Practices
  • Organizational Structures
  • Lean Startup
  • Product / Portfolio Management
  • Organizational Culture
  • Learning Organizations
  • Non-Software Application
  • Business Value / Agility
  • Technical / Product Research
  • Multi-Team Dynamics
  • Organizational Leadership
  • Organizational Change

[Note: The above, is based on guidelines provided by Scrum Alliance application process for CTC and CEC.]

While running some risk of sounding self-serving (very much NOT! the intent here) : please, be mindful and responsible when you select guidance-level professionals in your agile journey 😉.

Grassroots of Modern Command & Control Behavior


Examples of Command & Control behavior can be historically traced back into centuries, to the periods of dictatorship, imperialism, monarchy, feudalism and even further back, to more primitive social systems.  However, for the sake of this discussion, let’s refer only as far back as Industrial Revolution of the last century.  Back then, workforce predominantly consisted of low-skilled laborers that performed routine, mundane physical work and managers-supervisors that were responsible for setting goals, assigning responsibilities, monitoring progress and praising-penalizing workers, based on individual performance of the latter (using “carrots & sticks” approach).  This type of management was a classic example of what is known as Taylorian Management (Frederick Taylor), according to which, there had to be clear delineation between individuals that performed work and individuals that controlled/managed work of others.  This type of human relationship in work settings was also later described as Theory X Management (Douglass McGregor), and it suggested that managers needed to use totalitarian and repressive style to ensure tight control over workers, because the latter would otherwise not work hard and efficiently enough.

…Fast forwarding to modern days…

Today, we still have many examples of Command & Control behavior that shape relationships among people in modern organizations.  This happens even in situations, where organizations have workers that are very highly skilled and intellectually advanced.  More frequently, this is seen in organizations that are at Laloux’s Orange state of maturity or lower.

While in part, modern Taylorian Behaviorism can be explained by long-lasting “cultural inheritance” that hopefully will wear off over time, it would be interesting to look closer at some specific root causes of modern-days Taylorian behavior.

Although not exclusively, the examples below, are more frequently observed between individuals that are related to each other by hierarchy (boss-subordinate).

Insecurity about own job. Worries about own career growth.

A manager does not feel secure about his own position.  This could be caused by company reorganization (e.g. merge, acquisition, flattening) and a manager feeling that his role may be reduced or eliminated.   This fear of becoming dispensable could be worsened by realization of personal incompetence and/or lack of professional knowledge.  This is frequently seen in situations, where managers, as they have progressed the hierarchical ladder, have given up their hands-on skills and became peoples’ managers.

Misunderstanding roles of other people

A manager does not keep up with evolution of roles and does not understand purpose/importance of some new roles that have emerged in a workplace.  As a result, a manager tries to “map” new roles to old roles and apply the same yard-stick to measure and manage a subordinate.  His own lack of understanding could be frustrating to a manager and, therefore, make him feel defensive in discussions of roles and responsibilities of his subordinates.

Compromised self-esteem and desire to protect own Status Quo

While being a part of a larger organization, a manager might be getting a significant portion of mistreatment, in the form of command & control behavior, from his own superiors.  This is where the desire to protect his own status quo and not to look defeated in the eyes of his own peers and sub-ordinates kicks in.  There is a growing need for self-redemption and the urge the relieve a built-up psychological stress.

Note: All three examples of the root causes of Command & Control behavior above, usually result in a manager becoming passive aggressive and seeking ways to discharge negativism onto others.  Typically, “others” come in the form of a manager’s own subordinates, with the latter becoming defenseless recipients of mistreatment.

“I am Great” competitive stance “Tribal Stage 3” (D. Logan)

With the attitude of “I am great and you are not”, a manager perceives himself as someone who is smarter and greater than his subordinates.  The person that acquires a managerial position, that is sometimes is just a result of skillful pursuit of a new vacancy (e.g. due to reorg, force reduction) and/or experience to navigate organizational political terrain, feels the need to demonstrate his superiority to others.  To continue being perceived as a super-star and to stay in a spotlight of all events that can further multiply his glory, as well as to be able to claim someone else’s credit (delivery, innovation, invention) as his own, a manager wants to keep his subordinates “at bay”, to prevent their independent advancement and autonomy.

Individual resentment and animosity towards other people

While not very common and rightfully speculative, there are situations when outside-of-work relationships or individual perception outside of working environment, define the relationship between a manager and subordinate.  Broken friendship, unsuccessful romantic relationship, differences in personal values, norms or beliefs – all can impact professional relationship at work.  A manager, who has an upper hand, may leverage his superiority to repress a subordinate, in retaliation to work-unrelated matters.  On top of being unprofessional, this behavior could be also viewed as “non-sportsmanship-like conduct”. 

I am Expert” distrusting stance (distrust in competence of others)

This could be viewed as the least “harm intended” manifestation of command & control behavior.  This is more commonly seen in situations, where a manager still has sufficient hands-on expertise (e.g. technical lead) and can-do work.  Viewing himself as a “super-doer-expert”, a manager usually prefers to “shut the door” and resolve all problems on his own, instead of trusting his subordinates to collaborate and come up with shared decisions.  A manager-doer prefers to make single-handed decisions, while controlling actions and interactions of other people, in a fear that someone’s failure will be perceived as his personal failure.

Below is System Modeling diagram-example that illustrates relationships Command & Control behavior with the reasons described above and some additional system variables that impact system dynamics.