Category Archives: Scaling

Addressing Problems, Caused by AMMS

For 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 that AMMs are different from Agile Check-Lists (e.g. classic example of Scrum Check list by H. Kniberg) in ways that may actually 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 usually place attributes in buckets that represent different states of maturity that follow one another, sequentionally.

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 are always more weight-carrying 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 correlated systemically and impact one another in ways that are not apparent, until system modeling techniques are applied.  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 more advisable to treat every identified agile attribute as a system variable, on-par with others, while assuming that it has upstream and downstream relationship with other system variables.  In many situations, instead of spending a lot time and resources on trying to improve a downstream variables (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 a 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).

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:

LeSS “Construction”: What is it like?

[also, cross-posted on less. works]

Large Scale Scrum (LeSS).  It is the framework for scaling agile development, done by multiple teams, as they work on same product and work for a single Product Owner.   In order to be effective, LeSS requires organizational descaling that means simplification/flattening of organizational design.

What is Organizational Design?  To understand it better, let’s look for analogy in construction industry.  What is required to erect a building? In our analogy, we shall stay simple: bricks (foundation block) and cement (connective material that holds bricks together).

Imagine two buildings: Building A and Building B.

Building A uses brick as its main foundation block.  In fact, when looking at the building’s facade, the most prevalent object, caught by a naked eye, is a brick.  Bricks are positioned next to one another, with just enough cement in-between to glue them strongly together. There is no excess of cement anywhere: the connection layer is very thin/lean.

Architectural design of building A is simple and flexible: the structure is flat (one-story high) and it sits on strong foundation, also made of brick.   Because of its design, architectural adjustments are possible in various sections of the building, independently, with little additional labor.  Due to such modular structure, the building can be expanded laterally, just by adding more bricks to the wall.  Of course, due to its flat structure, the building is also very stable and can withstand a strong wind, flood or an earthquake: practically nothing can be shaken off or washed off the building.

When waste is produced inside the building, it becomes noticeable immediately. Waste disposal is also very simple: it does not require complex chutes or automated waste ‘packaging’ systems.  Waste removal can be mostly done manually, by building residents.  Any necessary supplies (e.g. food, water, furniture, other materials) can be easily delivered to any building area, without the need of advanced technology or mechanics.

Finally, building inspection and maintenance is a very easy process, because of flat structural design: foundation, walls and floor assessment – all can be performed with a naked eye; corrections can be done timely and efficiently.

This is what building A looks like:


Building B is made of a very few bricks and a lot of cement in-between that holds bricks together. In fact, the ratio (by weight) of bricks-to-cement is very low.

Architectural design of building B is rigid. It has many floors, with top floors made primarily of cement.  The building represents a heavy and monolithic structure, and although it also sits on brick foundation, as building A, the bricks are widely spaced with lots of cement in-between.  This means that the overall weight of building B is dangerously high (foundation can crack).  The building’s expansion limit, to accommodate growing occupancy demands, is low: it cannot be easily extended (scaled) horizontally with a couple of extra bricks added to the side, because the bottom brick layer would require multiple horizontal cement layers added on top – to follow the originally intended building design.  If additional cement layers are added on the top of foundational brick layer this will further increase risks of foundation cracking.

Waste disposal is a serious issue for Building B.  While waste can be relatively easy removed from the bottom floor (it is also not in abundance there) and, to some extent, from top floors (by taking it to the roof and using a waste removal chopper 😊), there is a huge amount of waste that gets accumulated at middle floors – and it sits there.  It is extremely challenging to remove this mid-section waste and what building management does from time to time, is ordering for this waste to be moved from one floor area to another (the building is very compartmentalized).  Sometimes, waste gets moved to floors above; sometimes – below.  This creates an illusion of waste removal. But waste remains.

Delivery of supplies and food to Building B occupants is a real challenge, especially if elevators are out of order.  This makes occupants angry and frustrated and sometimes they turn onto each other; become competitors and rivals.

Finally, building inspection and maintenance is a nightmare for Building B.  Many living units are out of compliance with building codes, but violations (and violators) are hard to identify and remove because true facts are well concealed and numbers are gamed by building occupants.

This is what building B looks like:

Large Scale Scrum requires organizational design that is analogous to the construction represented by Building A.


In LeSS:

Team represents the main building block (a brick). Selected team representatives (developers) and mentors-travelers–ensure effective coordination/connection between teams.  There are no additional roles required for coordination.  Cross-team events are minimal (Overall Product Backlog Refinement, Sprint Review, Overall Retrospective).

If product definition widens and more developers are included, another team can be formed and positioned laterally to existing teams – just like a brick.  Should product definition become too wide and the number of required developers exceeds 50-60 people (8 teams), another product area can be identified (new independent module, made of bricks).  Now, LeSS becomes LeSS Huge.  The only additional coordination that would be required in LeSS Huge is between Area Product owners and Overall Product owner – for strategic planning of Potentially Shippable Product Increment (PSPI) at the end of every sprint.  In both, LeSS expansion from 2 to 8 teams, and LeSS Huge expansion beyond 8 teams, there is no need for additional coordination that is different from what is described above (no extra cement needed to keep bricks together).  Also, in LeSS Huge, when one Product Area expands and another one shrinks, moving the whole team from one area to another, does not require expansion or shrinkage of any additional “supportive” organizational layers.

By design, LeSS foundational structure is very lean: flat, fungible and cross-functional.  There is no waste or overhead with roles, responsibilities, events or artifacts.  Everything is very minimalistic.  If any waste is generated in LeSS, it has practically nowhere to hide.

Because there is so much transparency in LeSS, waste is seen immediately.  Any findings of waste or any other required improvements to individual teams or LeSS framework, can be effectively done in Team Retrospective or Overall Retrospective, respectively.  Thanks to its flat organizational structure, LeSS (and LeSS Huge) don’t have to worry about waste removal from additional organizational layers – they [layers] just don’t exist.   There are fewer layers that sit between LeSS teams and LeSS Product Owners and these layers are much thinner.

What happens with LeSS organizational structure during rough times: slow down in business, increased market competition? Arguably, because LeSS is so lean and there is continuous learning, it is much less likely that LeSS people will be displaced. LeSS is also more likely to withstand other types of reorgs and shake-ups because LeSS has very few moving parts, loose pieces or weak links.

Organizational designers that support LeSS think like building architects that want to build strong, reliable, easily-maintainable, low-waste, cost-effective and long-lasting structures!!!

Many thanks to all LeSS Trainers, Coaches and Practitioners building reliable structures 😉.

Signed: ____________The Organizational Building Management 😉

05/26-28: Scrum Coaching Retreat | Kiev, Ukraine

2017 Scrum Coaching Retreat in Kiev  is in the books!!!  The event has brought together a few dozens of agile coaches and trainers from nearby and far away.

The participants came from different backgrounds and focus areas but due to everyone’s extensive experience in self-organization and self-management, got the show on the road very quickly.  After a short round of self-intros, each participant introduced a few topics that they wanted to discuss. By using a combination of dot-voting and affinity clustering techniques, the group came up with a handful of key topics that everyone wanted to deep dive into.  The group broke up into four teams, with each team picking one high-priority topic – to be worked on in consecutive three (3) sprints.

The team I joined (“Happy 7”) picked up the topic “How to influence decisions of senior management directly, from the bottom of organizational pyramid”.  The team consisted of experienced ScrumMasters, Team-level and Enterprise-level coaches.

The problem statement that defined our team’s effort was:

“There are so many instances, of challenges and obstacles that teams face, are not being heard at the top of a food chain.  And even when they are heard, often, original messages get distorted and lose urgency, as they travel up through multiple “translational” layers.  What can be done to fix this problem?  What techniques could be used to effectively segregate impediments that are local and can be resolved by teams and the ones that are systemic/organizational – and must be aggressively escalated upward?” 

The problem above has direct dependency on organizational design, specifically, on its thickness: the number of organizational layers between working teams (on one hand) and senior leadership/paying customers (on the other) – is a well-recognized challenge today.

Our working group has identified the following organizational design scenarios that define dynamics and human interaction in modern Product Development:

  1. Development teams and Product Owner belong to the same organization and end-Customer is positioned internally
  2. Development teams and Product Owner belong to the same organization and end-Customer is positioned externally
  3. Development teams represent Vendor-company and Product Owner represents Client-company and relationships between Vendor and Client are based on:
    • Out-staffing model – when a vendor provides human assets (developers) that are then owned by a customer, from management perspective, whereas legal ownership (e.g. insurance, taxes) is still by a vendor
    • Out-sourcing model – when an entire project gets outsourced to a vendor and a paying customer has no or minimal interaction directly with human assets (developers) that do work (most of communication flows through Engagement Management)

Interestingly, since many of our working group members had a lot of experience with #3 option above, the primary focus of our discussion was about how to bring closer senior leadership of paying customers and agile teams of delivering vendors, closer together, despite multiple “anti-agile” organizational layers that frequently reside in-between the former and the latter.

The ultimate result of our brainstorming was the invention of a non-commercial, collaborative game that was given the name of Influence Poker.

Our game’s purpose was:

  • To identify challenges that delivery teams often face
  • To classify challenges, based on origin, severity and implications
  • To discuss potential ways of resolving and/or escalating challenges
  • To ensure resolution ownership and transparency on its progress

Note: The initial contributors to the game creation were: Serhiy Lvov, Kiryl Baranoshnik, Artem Bykovets, Alexander Karitsky, Mark Summers, Jonas Mann and Gene Gendel .

The most serious organizational design challenge, when a paying customer engages with a vendor-company, is seen with an out-sourcing model.  Here, no matter how agile/robust technology teams are, their ability to deliver effectively is hindered by:

  • Involvement of Delivery Manager (usually, placed on a client site) who owns a relationship with a customer, serves as a single filter-channel of communication between a customer and teams, makes commitments and furnishes progress reporting on behalf of teams. The same person also streamlines feedback from a customer back to teams and frequently assigns work to team members.  This is usually accompanied by micro-management and command and control behavior.  The situation can be further worsened by the presence of Vendor Management function (customer side) that enforces SLAs, SOWs and other formal contracts between a customer and vendor: this just adds additional tension to a relationship and moves further apart end-customers and delivery teams.
  • Weakening of Product Owner role – the importance of this critical Scrum role gets downplayed, because a customer company no longer sees value in direct communication with technology teams.  Instead, Delivery Manager is treated as a single person, responsible for project delivery.  This dramatically narrows all communication media that are used in Scrum (holding events, sharing artifacts).

The above two challenges are inter-related through a positive feedback loop: the less disengaged Product Owner becomes, the more pivotal the role of Delivery Manager becomes.  The opposite is true too: strengthening the role of Delivery Manager, leads to further “excusing” Product Owner from stepping into the game, as Scrum requires.  This is a viscous, de-stabilizing loop that continuously weakens Scrum.

Please, look out for the Influence Poker.first official release that is coming soon! It may greatly help your teams visualize their organizational problems and discover potential workable solutions.

Note: For attendees and participants, here are additional shortcuts:

Agile Flyer – 04-09-2017

 



 

Public Announcement:
Scrum Alliance® Announces Partnership with LeSS Company

 

Denver, CO,— SCRUM ALLIANCE® – The news are finally out and public: On 4/7/2017, Scrum Alliance interim CEO Lisa Hershman, has announced that Scrum Alliance,
most established and influential professional membership organization and certifying body in the Agile community,entered in partnership with LeSS Company to support widespread adoption of Large-Scale Scrum (LeSS).

-Read the entire press release…

Join your local LeSS communities today.
(LeSS NYC)

Applying LeSS Thinking to Basic Scrum
“LeSS Hexagon of Values”

As per Scrum Guide, “…Scrum is a framework for developing and sustaining complex products…
It [Scrum] is lightweight, easy to understand and difficult to master”.
The guide talks about basic Scrum, or Scrum by one cross-functional team that works for only one Product Owner, on one single product.
The guide also mentions situations when multiple Scrum teams must work on the same product backlog and share the same Definition of Done (DoD) – an example of scrum scaling.

Large-Scale Scrum (LeSS), on the other hand, is a product development framework that extends Scrum with scaling rules and guidelines, without losing the original purposes of Scrum.…”.
Some of the hallmarks of LeSS are:

  • It is the framework that requires organizational de-scaling (simplification), to scale basic Scrum
  • It is the framework that strongly relies on effectiveness of organizational design and system dynamics of multiple organizational layers, departments and spheres of control
  • It is not merely a group of teams doing their own Scrum, while working for different product owners and supporting different products.
    Rather, it is a group of teams (2-8) that works together, synchronously, on the same product and serves the same product owner.

-Read more…

 


More Selected Periodicals:
Unspoken Agile Topics

This paper, originally written in February 2013, brings to light some of the least-discussed topics and consequences of “broadband agilization” that currently take place in the industry.
The materials of this paper are subdivided into two general sections:

  • The first section describes certain impacts that Agile has on individuals and their personal career advancements.
  • The second section describes organizational-level Agile impacts that pertain more to client companies that undergo Agile transformation,
    as well as service-providing vendor companies that deliver Agile-transforming expertise to their respective clients.

-Read more…

Be an Educated Consumer

You just bought a house and decided to renovate. You brought in a contractor to estimate the work that you want done. What is your biggest fear? Here are a few possibilities:

  • The work will not be done.
  • The work will not be done on time (winter is coming and you need wall insulation before it gets cold).
  • The work will be done on time but it will cost you much more than you can afford and more than this job really costs.
  • The contractor is charging you more than he should; he is taking advantage of your ignorance.
  • The quality of the work will be poor but, unfortunately, you will not know this until all of it is finished and you have to move in (after you pay in full).

-Read more…

Fresh Collection of Ad-hoc Agile References:

I continuously collect articles and publications that come from everywhere: colleagues, coaches and trainers, clients, occasional encounters.
I keep a comprehensive list of resources here, categorized by themes.
Some of my most recent samples from the collection are below:



From www.ScrumAlliance.org

Connect with a Certified Coach for Online Coaching!
(re-published from Scrum Alliance newsletter)




 

Applying LeSS Thinking to Basic Scrum

As per Scrum Guide, “…Scrum is a framework for developing and sustaining complex products… It [Scrum] is lightweight, easy to understand and difficult to master”.  The guide talks about basic Scrum, or Scrum by one cross-functional team that works for only one Product Owner, on one single product.  The guide also mentions situations when multiple Scrum teams must work on the same product backlog and share the same Definition of Done (DoD) – an example of scrum scaling.

Large-Scale Scrum (LeSS), is a product development framework that extends Scrum with scaling rules and guidelines, without losing the original purposes of Scrum.…”.  Some of the hallmarks of LeSS are:

  • It is the framework that requires organizational de-scaling (simplification), to scale basic Scrum
  • It is the framework that strongly relies on effectiveness of organizational design and system dynamics of multiple organizational layers, departments and spheres of control
  • It is not merely a group of teams doing their own Scrum, while working for different product owners and supporting different products. Rather, it is a group of teams (2-8) that works together, synchronously, on the same product and serves the same product owner.

It is worth stressing the last bullet point above:
Frequently, novice agile adopters mislabel scrum implementation by independent and unrelated teams, as “LeSS”. Sometimes, they are genuinely mistaken. But there are instances of intentional LeSS terminology overload. In either case, inappropriate use of LeSS terminology creates asymmetry between LeSS guidelines and rules, on one hand, and reality of teams’ working dynamics – on the other.

Another prevalent misconception about LeSS (and more on this later in this post), is that LeSS postulates are ONLY applicable in large scale settings. Some, less experienced agile practitioners feel that if an organization implements Scrum in its basic form only, without attempts to scale, the facing organizational dysfunctions that are vividly exposed by LeSS, could be avoided. This is a mistaken belief: LeSS principles can be used to improve basic Scrum as well. Practically, any organizational dysfunction that is exposed by LeSS, also presents a challenge for basic Scrum, but perhaps, in a form that is not so obvious, and with a manifestation that is not so disturbing. In a way, LeSS serves the purpose of “dysfunctions amplifier/magnifier” that allows seeing more clearly, at scale those things that may not be as obvious at single team level.

Below are the six big topics (LeSS “Hexagon of Values”) that are always brought up in LeSS discussions. Lets take a closer look and see if they still retain their relevance in basic Scrum:

Feature Teams over Component Teams

From LeSS perspective:

From a stand-point of a paying customer, feature-centric product development is the most effective way maximize business value.  Feature teams can perform this work best, since they are able to operate across multiple application components, independently and autonomously.  Component teams cannot do the same. A component team is focused only on one single application domain that is not shippable (marketable) on its own, if viewing from a standpoint of paying customer.  Trying to fake LeSS, by putting under the same wrapper multiple component teams, creates a large amount of handover and other procedural overhead before a release.  For example, if eight component teams (max. # in LeSS) work only on respective single component items, pulling them from the same backlog, there will be a lot of component integration required, before a product becomes truly shippable (PSPI).  This will either, at best, consume a lot of teams’ capacity at the end of each sprint, or will require an additional “hardening” sprint before going to production (at worst).

How is this applicable to Basic Scrum?

It is not uncommon to see single component team that pretends ‘doing scrum’, by introducing scrum roles, artifacts and events to their work model.  At a glance, it may appear that a team does what other scrum teams do – it sprints, but the goal of scrum: to deliver PSPI – is still absent.  The impact of such faking, on the ability to meet a product owner’s goals may not be as strong and obvious, because delivery expectations from a single team just are not as high as expectations from 8 LeSS teams.  (Another word, from a standpoint of time & resources spent and humans involved in performing work, a single component team that pretends ‘doing scrum’ would have an easier time to justify to a product owner and stakeholders ‘why’ their end-of-sprint deliverable is not shippable: justifying ‘undone’ work by 3-9 developers of basic scrum is just easier than justifying ‘undone’ work by 50 developers of LeSS).  However, the core underlying problem still exists in basic Scrum: a sprint deliverable is not PSPI. 

Component Mentorship over Component Ownership

From LeSS perspective

There is a distinction between Component Ownership and Component Mentor-ship:

Component Owner  – is an individual (sometimes, a group) that has unique privilege to work on a particular application component.  If any other team needs to make modifications to a given component, they must delegate this work to a component owner.  Rarely, these ‘private code policies’ are justified by external regulatory requirements or internal audit needs.  More frequently, such ownership is due power retention and sphere of control ambitions of certain individuals/groups, both being secondary to internal organizational politics.

On the other hand, Component Mentor – is an individual that has a lot of work experience with a particular component, but instead of becoming a bottleneck to component-specific work, he teaches others how to do the same.  Effectively, a component expert becomes a teacher of “how to fish”, instead of a giver of an “already caught fish”.  With such approach, any feature team, over time, becomes proficient at working on any application component, without being dependent on a component owner: each component becomes a shared property; no more someone’s private and protected domain.

By giving up the privilege to be the only person who can touch an application component, an application mentor should not lose his organizational value: instead of being a single-contributor/performer he now becomes an educator and advisor – the role that is much more scalable in large organizational settings. This empathizes another concept (below) that is strongly advocated by LeSS trainers and coaches: Job Security should not be confused with Role Security.

How is this applicable to Basic Scrum?

Perhaps, the most important distinction in basic scrum is that for a single-team operation, the benefit of having experienced and willing to share their knowledge with others, component mentors, is not as obvious.  Also, an organization may have a hard time to justify designating a component mentor, per component, serving a stand-alone and unrelated to others, scrum team.  But even for a single team that does basic scrum, the problem still remains: not being able to work directly with certain application components will continuously lead to having external dependencies on other teams/individuals, and therefore, will put at risk the ability to deliver PSPI at the end of each sprint.

System Optimization over Local Optimization

From LeSS perspective:

There is strong contrast made between Local Optimization and System (Global) Optimization.   Any single-specialty department (UI/UX, BA, QA, Dev, DB) is ‘locally optimized’. This means that people within each department might be very busy and work hard to complete a series of tasks that ONLY they can do.  The opposite is true too: a group of single specially workers can perform ONLY a subset of tasks that their skillset allows.  While from their own (local) perspective, they work very devotionally and produce a lot of output, from a stand point of a paying customer, the overall outcome is still low.  False perception of local efficiency by single-specialty workers does not directly translate into system efficiency: individual ‘local progress’ does not add up to system progress.  A classic example of local efficiency could be over-production of comprehensive BRDs by Business Analysts (BA), way ahead of development efforts: while from a stand point of BA, lots of great documentation is produced and signed off, from a stand point of a paying customer, much of this work may become obsolete (projects are delayed, priorities change, budgets get cut, etc) before implemented in code.

How is this applicable to Basic Scrum?

Manifestation of local optimization, also being a direct result of single-specially (component) work, is frequently seen on basic scrum teams that lack T-shaped developers.  For example, non-technical business analysts and manual testers, will be, most likely, focused on ‘writing stories’ and producing manual test cases, respectively, way ahead of sprint development.  For example, is not uncommon to see BAs, attempting to ‘clarify’ user stories by adding to them a lot of conventional, contractual documentation (e.g. BRDs) that leads to reduction of communication with a product owner and stakeholders during sprinting; this introduces elements of mini-waterfall in scrum.

Job Security over Role Security

From LeSS perspective:

Any person should have a job and be capable of making living.  Offering job security to each employee, should be one of the most important goals for any organization. However, job security should not be equated to role security.   Gradual changes of needs in any particular role, could be a natural process that follows bigger industrial changes: modernization, computerization, robotization, etc.  Efficiency an overall system organization should not be sacrificed for preserving specific roles that no longer bring value.

One of the most common role changes discussed in LeSS is the role of Project Manager (usually, first-line PM).  Scrum requires self-organized and self-managed teams that take full responsibility for their own work and interaction with customers.  Everything is done by a team that performs work: work estimation and assignment, ownership and information sharing, communication and reporting.  Historically, all of this has been handled by a project manager.  Shifting all these responsibilities to a team, makes PM feel underutilized, sometimes annihilated.  In environments, where teams no longer require tight managerial control, managers may have to re-focus on removing organizational challenges that teams face and cater to teams everything, what is required, to optimize team work.

It is critical that any organization that reevaluates its existing roles, also takes a close look at existing job families and employee career paths.  If an organization suspects that some employees might be displaced due to changes of roles and responsibilities, it must provide other alternatives for people: education, training, internal mobility to other parts of an organization, etc.

How is this applicable to Basic Scrum?

The need to provide job security for potentially displaced workers in basic scrum settings is no less important than in LeSS.  Business analysts and manual testers should be given an option to move into scrum teams and learn additional skills.  In basic scrum, unlike LeSS, where there is a much stronger need for addressing and resolving organizational impediments, it could be less obvious how a first-line manager of a single scrum team can be fully occupied, with removing impediments, as this is usually Scrum Master’s responsibility (in basic scrum, at single team level, impediments may also be not as systemic).  In such cases, line managers should be given an option to move to another part of an organization, where traditional development is still practiced.

Narrow & Deep over Broad & Shallow

From LeSS perspective:

When it comes to large-scale agile adoptions, it is very easy to develop a false assumption that bigger is always better.  Some organizations are trying to jump on a bandwagon of agile-mania and claim early victories (this is often caused by ill-defined motivation and bonus schemas that praise people for achieving certain fabricated goals, e.g.: by ‘rolling out agile’ to a very large part of an organization.  Such attempts of broad coverage also lead to shallow impact: organizations are able to demonstrate short-term superficial (sometimes, fake) results but there is not enough momentum to ensure continuity and long-term success.

It is always much better to focus on a narrow part of an organization, by extrapolating it from a larger organizational construct, and improving organizational agility, by going deeper into organizational structure.  In LeSS, the recommended size of an organization (at least, on technology side) is about 50 people.

How is this applicable to Basic Scrum?

This concept is probably not as applicable to basic scrum, as other concepts mentioned so far.  ‘Breadth’ of implementation implies wide organizational areas and involvement of many people.  Basic scrum is not as concerned with horizontal span of efforts because, by definition, a scrum team is  only 3-9 people.

Owning over Renting

From LeSS perspective:

When it comes to making decisions, organizations and teams should look for ways to develop their own approaches, instead of ‘copying & pasting’ solutions of others.  Relying on professional trainers, is a great way to learn from expertise of others, in classroom settings.  Leveraging help of professional coaches, is another, longer-term, way to mature, through self-discovery, experimentation, inspection and adaptation.

Organizations and teams should be striving to own their own decisions and take responsibilities for successes and failures.  On occasions, trainers and coaches may lead by example (e.g. mock-up a behavior of a specific agile role), share lessons learned from prior engagements, but this is not done to encourage customers to copy/paste approaches and styles.  Ultimate decisions should be always made by those that will live with those decisions in a long-term.

How is this applicable to Basic Scrum?

In basic scrum, just like in LeSS, teams are expected to leverage what they have learned from trainers and coaches, to gain autonomy and become owners of their decisions and solutions.  Through frequent inspection and adaptation, teams that work in basic scrum should be able to ultimately modify their processes, as needed.  Logically, it would be also expected that a coach who assists team (s) that use basic scrum, coaches ‘himself out of work’ sooner than a LeSS coach, since organizational design challenges have much more severe impact on LeSS team that on basic scrum teams.

Challenges with Agile Training: Examples, Reasons, Consequences

Virtual networks of professional agile coaches and trainers is good place to pick up some most thoughtful and provocative agile discussions.  The most reputable networks that I know of, and happen to belong to, are the communities of: Certified Enterprise Coaches and Certified Scrum Trainers (both, from Scrum Alliance), and Candidate Large Scale Scrum Trainers and Coaches (both, from LeSS company).  These communities are great because there we continuously  share our experiences and learn from one another.

The summary below is the result of one such in-network discussions that spans in duration for more the a year. It is focused on in-class training experiences and highlights  – some of the most common challenges that we encounter with our students in pre-, in- and post-classroom situations.  Some of our observations are specific to internal classes, some – to public and some – to both.

Below, are some of the common challenges with Agile Training that we face:

Training “Wrong” Attendees with “Wrong” Intentions

At times, we get training attendees that have never held agile roles (e.g. ScrumMaster, Product Owner, Team member), … nor did they ever have an intention to do so.
While agile education is recommended at all organizational levels and for all horizontal structures (perhaps, with different focus, depending on audience), what is sometimes observed is that certain types of individuals show no signs of desire to truly understand to further implement newly-learned agile principles. Instead, their true desire, seems to be, in understanding agility concepts just enough to be able to figure out a way of creating “anti-dote” against them.  Typically, this is seen with individuals that are concerned with their own role security (not to be confused with job security) as it frequently gets challenged in agile and lean organizations (includes processes, tools and roles).

This situation is rather difficult to control in public classes, where any individual who pays a fee, can attend.  However, it can be (and should be) much easier to control with internal training. By requesting class attendees to come in ‘clusters’, as hands-on technical teams that share work already, accompanied by their respective business counterparts, trainers can ensure that right people are gathered together in the same classroom, at the same table, for shared learning, collaboration, and simulation exercises.  This is the most effective way to ensure that in-class learning will retain its momentum, when people go back to their work areas and start implementing newly gained knowledge in practice.
It is important to note that for any trainer who is planning to engage with trainees for a longer period of time and coach them, it would be especially important to have right people in the room during training – together.

Training “Certification Collectors”

It is not uncommon to see individuals that come to training with the main goal to add another trendy certification to their collection.  This is mainly fueled by job market demands, as hiring companies create job requisitions and look for a “soup of certifications”, sometimes, asking for most awkward and, sometimes, conflicting combinations.  For example: “A candidate must have CSM, PMP, PMI-ACP, SAFe, PRINCE2, etc”.  Most of such jobs are usually poorly described and contain erroneous statements about actual role expectations.

This situation has been observed much more frequently in public training courses, where individuals pay their own money to attend.  Less so, this has been observed with internal training, where students do not pay their own money to attend (nor do they get certified). As such, their eagerness to maximize ROI from attending aa class is much lower.

Also, as a side-effect of this unfortunate pattern, blind pursuit of certifications by non-practitioners who don’t have any intentions to put their learning to practical use,  also dilutes meaningfulness of certifications in the market and adds even more confusion to hiring companies.

Influence of Past Quasi-Agile Experience or Misguidance

Some individuals come to training after prior “agile theater” experience.  Please note that in this post, the emphasis is made on specific cases, when prior agile exposure was of low quality and had created confusion or conflict with new learning.

Bad agile experience may come in various forms.  For example, poor agile implementation “on the job”-  often due to a complete lack of training and misguidance by management.  Another example would be previous low-quality/misleading agile training that was delivered by unqualified guides.  The adverse effects of these types of wobbly foundations are observed equally frequently with public and private training.

It is worth mentioning some well-known sources of unqualified guidance:

  • Vendor companies that lack internal agile expertise or track record of teaching.  Historically, such companies have done mostly staffing/recruiting or management consulting of some sort and just recently decided to step into ‘agile arena’ in pursuit of additional revenue (pretty common these days).  Such companies “get lucky” when their is long-standing clients pull their names off a preferred vendor list and ask to fulfill agile staffing needs.  Usually, hiring companies that use this approach get exactly what they paid for :).
  • Internal employees that have been promoted/fast-tracked into trainers or coaches to fulfill a growing internal company demand for agile guidance.  Such individuals, most of whom do not have any prior field experience as coaches or trainers, are too restrained to existing organizational norms and standards: they are not reformists and challengers by mindset; they are conformists and executioners. Thus, in classroom settings, they present “by the book”, at rudimentary level and steer their followers towards “…this is how things are done around here…lets conform our Scrum to constraints of our organizational design and our internal best practices…”.  Such agile guides are not very effective in handling out-of-the-box situations or addressing serious inquiries that require deep understanding of organizational design and system dynamics.

Internal agile trainers that have been more successful in their work than their peers, usually position themselves in a way that they have, first and foremost, ensured their own security and operational safety that is required to drive organizational changes from within. Secondly, such individuals also have a very strong connection with external professional circles of trainers and coaches, though which they explore horizons of their learning beyond boundaries of a single organization and continuously hone their craft as trainers and coaches.

Lack of Pre-Training (Self-Study)

Almost any trainer will appreciate having in her class well-informed students (a.k.a. “educated consumers”) that have done recommended preparatory self-study before attending training.  Self-study helps normalizing basic understanding of concepts and level-setting students’ expectations from in-class learning.  It also, potentially, reduces the amount of basic, rudimentary questions that unprepared students often ask in class: about terminology, conventional abbreviations, jargon, etc.  By spending less time on explaining basic book definitions, an instructor can spend more time on collaborative activities, role-playing, discussing real-life simulations and doing practical exercises.  This case of low preparedness is more frequently seen with internal training, where a company sponsors an event (even, when an external trainer is hired from outside, employees don’t pay from pocket) or training is totally free (done by an internal trainer).  Just like in the situation described above, students’ desire to maximize ROI is lower than in public training, where people invest their own time and money to attend.

Attempts to Change Training Content to “Conform to Reality”
  • “Is it possible to shorten our training from 2 days to a few hours?”
  • “Can we conduct training just for IT people, since it is hard to justify to our business partners why they need to be away from their desks for a few days?”
  • “Can we conduct training just for business people, since our IT people are already well-trained in agile, “doing stand-ups” and using Jira/Rally to track time spent 🙂 on tasks and they see no value in going through another training, alongside with business?”
  • “Can we review training materials upfront, to make sure that we don’t waste any time on topics that are not relevant to us and ensure that we conform to our existing organizational reality (philosophy, norms, rules)?”

These types of requests are almost unique for internal training arrangements.  Frequently, they come from first- and mid-level managers that get their marching orders to “do agile” (a.k.a. “support-in-spirit”) from senior leadership, and while orders are given, the empowerment to make sure that things are done properly– is not there.  Such corner-cutting and artificial scope reduction has its own reasons. Here are some of them:

Sometimes, agile training is perceived by both: attendees and their managers – as an easy way of meeting personal objectives in order to receive good performance appraisals (when students are asked in class why they are there, they frequently respond that “…it is in our personal development plan and our management wants us to do it, because everyone else is doing it…”.  [Author’s irony: “if everyone was jumping off the roof would you do the same?”].  There is no clear understanding, purpose, vision or goal.  There is no clear strategy on how to put new learning to work, after attending classroom training.

There are other times, when attempts to change training content are caused by a desire to circumvent or avoid sensitive topics that could be perceived by some as politically-incorrect implications of organizational dysfunction.  For example, topics about harm of performance appraisals and monetary rewards, weaknesses of conventional budgeting, inappropriateness of old methods to procure for agile roles (e.g. product managers, T-shaped developers or agile/technical coaches), ineffectiveness of waterfall requirements in agile product development, shifting control and responsibilities form first-line management to teams, etc.).  In these situations, agile training might be reduced to a discussion of “best practices” (agile tooling, metrics collection, agile status reporting, etc.) or reviewing some sort of an internal agile guide for best practices that usually comes in a form collection of publicly available, commoditized (internet) information.  On the other hand, there are situations, when internal agile training turns into a battle field between people, whose hidden friction and conflicts of interest become more obvious because of agile topics and associated  with them transparency.

Attempts to Steer Training Content towards “Unique Situations”

Somewhere like the above, this case of uniqueness is more frequently seen with public training, where people come from different companies and pay for training out of their own pocket.  While their intentions to get “more bang for buck” are good and well understood, sometimes, methods are not.  There are instances, when students attempt to steer discussions towards their unique situations at work, by frequently interjecting with inappropriate comments or asking an instructor to reflect, in real-time, on their personal work experiences.  If this happens too frequently, it becomes disruptive for other students and reduces effectiveness of basic learning for everyone.  It becomes a trainer’s responsibility to ensure that special cases and real life scenarios are reviewed at appropriate times, preferably, with participation of other students, in team break-out sessions (could be also facilitated by a trainer).  Such cases of uniqueness are not as frequently observed with internal training because there is much less variance in situations within the same company.

Requests for Exemption from Training by “Special” People

There is a fundamental difference between support- in-spirit (a.k.a lip service) and true, genuine hands-on involvement and support-by-action (a.k.a. gemba).  Unsurprisingly, there is a shared belief among organizational coaches that: “…a coach can take an organization in its agile journey only as far as an organizational leader is willing to go…”.  It is imperative that senior leadership that is behind agile transformation is well informed and educated.  While content of agile education for senior leadership (executive training and coaching) may differ from content taught to feature teams, ScrumMasters and Product Owners, it must be delivered as the earliest phase of transformation, to prepare seniors for inevitable organizational changes: structurally, culturally, processes -, norms – and values-wise.

Unfortunately, there are many cases when senior leaders excuse themselves from agile education.  They delegate this critical activity to more junior people beneath.  Soon, this leads to misalignment and disconnection between teams that are trying to implement agile changes and senior leadership that is trying  to effectively support the effort, but cannot – due to lack of understanding of systemic and organizational implications.

It is a rarity to see senior leadership attending public training – they just find it too difficult to allocate time for this external activity.  With internal training, things are somewhere better, but not by much.  On occasions, senior leaders will attend initial part of agile training, and try to motivate their subordinates by personal example.  While it is somewhere useful to create initial momentum, it is not sufficient.  As a rule of thumb, having a senior leader sit though an entire experience of in-class learning that includes collaboration, system modeling and practical exercises, alongside with a feature team developer or product owner, is extremely rare. As a result of this, leaders leave with superficial knowledge and limited understanding of what their teams will be experiencing on practice.

Lack of Classroom Participation

In public training, it is hard to attribute lack of students’ participation to any specific cause; it is rather situational. Factors may vary from student’s disinterest in a topic (e.g. a person attends only for certification, as described above) to an instructor’s inability to effectively engage with a class, …to anything in-between.

With internal training, however, the situation is slightly different.  Here, in addition to a wide array of factors, suggested above, there is an additional important factor of individual safety.  Existing organizational structures (e.g. reporting lines, chain of command, seniority) may seriously influence in-class environment and dynamics.  Junior folks may feel unsafe and act submissively to others, whose seniority is higher, either by reporting structure or by experience.  It is not uncommon to see first-line managers and team leads attending internal training, alongside with their subordinates and more junior co-workers, and dominating in classroom by trying to set a pace and tone.  What sometimes worsens a situation even further is that, inexperienced internal agile instructors that are also a part of the same organizational structure, are not able (or not willing) to control in-class dynamics to ensure safe and democratic participation by students: they lack their own personal safety and hesitate to put a hard stop to misbehavior of empowered bullies.

Too Much Reliance on Training Materials

This is probably one of the most difficult paradigms that is hard to break: there is often so much reliance on documentation that goes as far as violating the second postulate of Agile Manifesto.  Most commonly, this is seen in internal training, at companies that mostly rely on their internal ambitions and self-confidence to become agile. When it comes to internal communication or information sharing, employees are accustomed to lengthy, “high-density”, corporate-style presentation decks.  They carry this experience into agile training, where now it becomes their expectation of what agile training materials should look like: they look for lengthy pages of instructions and execution plans.

Speaking of training materials, it is relatively easy to distinguish training materials of a professional trainer and materials produced by an internal agile champion, who has little experience in the field.  In the former case, materials are usually light in verbiage, more illustrative, graphical and entertaining; they mainly serve as conversation enabler and a “pacer” for an instructor.    In the latter case, materials are very data-dense, fine-printed and require intensive reading.   Unsurprisingly, when students attempt to follow pages of heavy presentations, they disengage from their classmates and instructor.  This further reduces learning and information retention.  This is also a primary reason why there is so much reliance on slides post-training.  Students mistakenly believe that what has been presented on slides is a prescriptive set of executable instructions.  Upon exiting “deck-driven” training, people end up ‘renting’ decisions that were suggested on slides, instead of deriving and owing their own decisions.  Instead of leaning more towards experimenting, inspecting and adapting, people look for directive guidance and “best practices” from a trainer (whose experience might be also questionable).

A few classic erroneous requests that thrown at internal trainers:

  • “Can we review training materials upfront so we can evaluate relevance of training to how we work today, so we can decide if we should come?”
  • “Can we be excused from training but review training materials instead to get up to speed?”
  • “Can training materials be finalized and standardized across all current and future training for all teams?”
  • “Would it be OK if we joined via audio or video bridge and closely followed training slides, instead of attending in person?”

What some people also don’t realize is that today, the best training/educational information is an absolute commodity and it is freely available on the internet.  Today, a heavy training deck has practically no intrinsic value because it is, most likely, a digest of books and articles created by others with a lot of copy-pasting involved (often, plagiary).  From a standpoint of a professional trainer or coach: if someone is looking for so much reliance on training materials and execution scripts, they may just purchase a really great agile book and read it on their own, instead of coming to class.

Summary:

Challenges with training (both public and internal) may cause further downstream adverse effects, beyond classroom:

  • For public training, this may potentially lead to bad reputation of a trainer or give undesirable publicity to his/her course value
  • For internal training, especially in situations, where it is followed by longer term coaching (could be also done by the same person that delivered training if he possesses coaching skills), this may lead to inability to effectively assist a team in their agile journey.

2017 Business Agility Conference – NYC

On 23-24th of February, there was the first ever 2017 – Business Agility Conference, held in NYC.  The event could be best described as “…2 days of authentic short stories and facilitated deep dives on business agility; focus on organizational design, market disruption and product innovation, agile outside IT and next-generation leadership…” (quoted from http://businessagility2017.com/)

The uniqueness of this event was due its demographics, and in particular: due to the breakdown of attendees – based on their organizational roles.  Although agile conferences (both, local and global) are never geared towards Technology and Information Systems only, this particular event was specifically geared towards business. As it can be seen from the statistics below, there were a very large number of people that represented Senior and Executive Management (more than 45%).

As always, another large share of attendees was represented by organizational and agile coaches.

It is also interesting to know that there were practically no discussions at the event about Scrum, Kanban, XP, tools, processes or frameworks, at the event.

My personal, experience as one of the facilitators of this event, was enriched by reuniting with some folks, whose work had significant impact on my own work:

With Steve Denning  With Mike Beedle With Bjarte Bogsnes

Note: Special thanks to Mike Beedle for mentioning my name in his Enterprise Scrum Executive Summary. (download pdf report to view)


Highlights from Steve Denning’s Presentation:

According to Steve Denning – the author of Radical Management, 20th Century Teams – were “teams” in name-only.  Team of the 20th century were gears of a classic, bureaucratic organizational machine, characterized by: top-down management, individual responsibilities and little interaction among people.  On contrary, real Agile teams require: autonomy & cross-functional structure, collective accountability and high degree of interaction. Steve focused on the following four main Agile themes:

  • Delighting Customer – there needs to be a fundamental shift in how management perceives relationships between Firm and Customer. This shift is best described by Copernican revolution: no longer Firm remains a centerpiece, with Customer revolving around it. Instead, Customer becomes a centerpiece and Firm revolves around Customer, delivering products, services and ensuring overall satisfaction.  Pre- Copernican Management belief was in making the main purpose of a firm to generate money for its stakeholders and was best described by Jack Welch’s quote: “…The dumbest idea in the world…”  The Post-Copernican Management belief is that, as was described by Peter Ducker in 1954: “…the only valid purpose of a firm is to create a customer…”
  • Descaling Work – in a volatile and complex modern world, where uncertainty and ambiguity prevails, any attempts to resolve big problems simultaneously, with one big-bang approach, are no longer effective. Instead, work must be dis-aggregated in small batches and performed by small, autonomous, cross-functional teams.
  • Enterprise-Wide Agility – to consider Agile as “IT thing only” is a huge mistake.  Attempts to improve organizational agility, with only a few small teams trying to “do agile”, with the rest of the organization remaining top-down, bureaucratic, slow-moving behemoth will result in a failure.  In order for the whole organization to become more agile, it has to embrace the entrepreneurial mindset front-to-back and top-to-bottom.
  • Nurturing Culture – is a huge undertaking that each organization must commit to and flourish from within. This includes leadership strategies, organizational structure, culture, norms, values and principles.   Excluding organizational design and system dynamics from agile transformation efforts by senior leaders is a costly mistake.

Throughout his presentation, Steve Denning highlighted additional important aspects of organizational agility:

  • “How many layers should Organization have?” –  There is no perfect number to give, but the fewer – the better. What matters is that there should be full transparency and direct communication between: Management, Customers/Users and Workers (employees, contractors, suppliers)
  • The Law of Network – “plugging” agile team into a bureaucratic environment may create visibility of local efficiency but over time will lead to unbearable friction between “old” and “new”.
  • There is a lot of “Agile PR” and “fake Agile” – it is usually brought about by IT attempts to embrace agility, with very limited support from business.  Frequent claims from management (sometimes, very senior) that is indicative of their gross misunderstanding of organizational dynamics is:
    • Agile is only for software
    • Agile does not scale
    • Agile cannot handle complexity
    • Agile is not reliable
    • Agile does not last

Steve Denning’s discussion was summarized by the example of Microsoft:  “In 2004, Microsoft was viewed as a huge battleship, slowly moving through waters at relatively low speed, and not being able to turn quickly and cost-efficiently.  In 2015, Microsoft is viewed as a flotilla of speedboats, moving fast but synchronously, and being able to turn “…on a dime for a dime…” (the author’s of this post quotes C. Larman)”

Highlights from Bjarte Bogsnes Presentation:

The chairman of Beyond Budgeting Roundtable (BBRT)  Bjarte Bogsnes, who has a long international career in Finance and HR, with successful implementation of BB at two large European companies, Statoil and Borealis, presented a short synopsis on Adaptive Management Model.

(Note: Being Bjarte’s follower and advocate for years, I recommend for your attention the following personal summary page: for in-depth understanding of Bjarte’s work).

Bjarte made a clear distinction between Management and Leadership.  People obey Managers (usually, mandatory) and follow Leaders (always, voluntarily).  Management is focused on: Rhythms (around events), Targets, Plans and Forecasts, Resource Allocation, Performance Evaluation and Rewards Distribution.  On contrary, Leadership is focused on: Purpose, Values, Transparency, Organization, Autonomy and Customers.  A lot of focus in Bjarte’s discussion was paid to ineffectiveness of fixed (“accordion-like”) budgets that are driven by calendar years, not by business cycles; harm  and dangers of producing and measuring wrong KPIs (often mistakenly considered as “KPTs”, where “T” stands for “truths”); lumping Budgets, Forecasts and Resources Allocation into one single KPI number, and then, coupling such ill-defined KPIs with individual appraisals and monetary rewards/bonuses – the main cause of system gaming and unethical behaviors that many organizations see today.  Bjarte’s presentation was followed by comprehensive collaboration, by many individual teams that used a variety of visualization techniques to illustrate a future state of agile budgeting & finance:

Other Great Highlights:

There were a few other great discussions that took place at the conference.  Here are a few excerpts that are worth including (paraphrased here):

  • From Charlie Rudd: “…Organizational Change Management != Organizational Transformation. Many more people tend to resist to the former; much less so to the ladder…” and   “…In Change Management, processes and system behaviors are predictable.  In Transformations – they are not…”
  • From Paul Cobban: “…Agile Education is not just for doers. It is also for Executive folks…Exempting themselves from continuous education, Executives lose touch with reality” and “…Stop Starting and Start Finishing…(or learn how to manage WIP at enterprise level)”
  • From David Grabel: “…Agile is not just for IT. A great example of Agile adoption success is Marketing…” and “…Adoptive, agile Marketing can drive organizational agility at large…”
  • From Venkateswaran NS: “…Do senior leaders have good vision? Does middle-management have right job descriptions (for themselves and their subordinates)?…”
  • From Pat Reed: “…Business Agility – is bravery to step into the area of unknown…” and “…the phrase ”I will believe it when I see it”…should become “I will see it when I start believing it”
  • From Fabiola Eyholzer: “…HR should stand for Human Relationships not Resources (from the author of this post: there is a common belief that calling humans as ‘resources’ is demotivating and disrespectful)…” and “…most discussions between employees and HR are scripted and lack sincerity and open-mindedness due to the fact that there is always a legal aspect to it and both parties are great of doing CYA…”
  • From Chip Loving and Jason Hall: “…Management by Objectives is wasteful and harmful…” and “…Transparency != Awareness…(from the author of this post: being able to see something and fully comprehend it, is not the same thing)” and “…Quarter-based profit sharing that is peer-based and transparent is much better than end-of-year subjective discretionary bonus decided by people that are mostly remote from action and area, where real business value is produced…”
    • From the author of this post: example of most harmful intensives allocation schema and less harmful intensives allocation schema

Product DetailsFinally, some great new publications were presented at the event.  I came to discover that my colleague and friend, agile coach Dana Pylayeva has published her new book “Introduction to DevOps with Chocolate, LEGO and Scrum Game”.  It goes on my To-Do list to read.