Category Archives: Team Dynamics

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

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.

Product Development Types: What Challenges to Expect in Each Case?

Not all types of product development are the same.  The most three distinct types are:

  • Internal Product development, where
    • Users/Customers are internal
    • Product Owner is internal, playing the role of a conduit between Users and Technology
    • Dev/Technology/IT is internal, mainly dealing with Product Owner (and her team)
  • Outsourced Product (“Project”) development, where
    • Users/Customers are internal
    • Product Owner/Lead User is internal, playing the role of a conduit between internal Users and external Technology vendors
    • Technology is external, represented by vendor-companies
  • External Product Development, where
    • Real (paying) Customers are external
    • Product Owner (classic Product Management/Business Unit) is internal and facing external Customer
    • Technology/R&D/Development is internal and interacts only with Product Owner

While these classifications may seem to be obvious, there are some important “nuances” that are often being overlooked.  Awareness of these nuances could be important for making product development practices less vulnerable.

Here are some potential pitfalls to look out for, with each type of product development:

(Note: This post does not provide any recommendations on how to avoid/reduce pitfalls.  Some suggestions might be covered in future publications.)


Internal Product development

  • Fake Product Owners (delegates, proxies, surrogates) that lack either authority, or vision/breath of product knowledge, or both
  • Artificial “internal contracts” between various company units, secondary to organization design. These, are often driven by internal competition, ineffective external motivation, subjective monetary incentives and bonuses
  • Technology is too remote from real customers, does not deal with them directly and has to go through additional organizational layers, units, groups, roles (even to get to  internal Product Owners)
  • Excessive amount of processes, tools, metrics/KPIs and reports that are used as mechanisms for measuring business value delivered and levels of customer satisfaction.  This is because of absence of real, short-loop customer feedback.


Outsourced Product (“Project”) development

  • Low mutual trust (both, client and outsourcing company). Product development process is “wrapped” into artificial projects and portfolios, typically, with fixed scope, timeline and budget.  Customer-vendor relationships are very contractual, with legal binders.  While there are much more effective agile contracts that exist today, they are rarely used, because of lack of ability, by either side, to execute them.
  • Documentation is voluminous and is at expense of collaboration and transparency. Approvals and sign offs are mandatory and are usually accompanied by rigid legal processes
  • Unfit vendors: many companies still rely on vendors, with whom they have been dealing historically (via vendor management system), instead of turning to a market place, every time there is a new need,  and searching for best candidates. Preferred vendors feel safe and comfortable, and with such “monopoly” in space, they have low, if any, desire to strive towards improving technical skills, adopting new technologies, etc.   Also, nothing prevents such “preferred” vendors from making unsubstantiated claims about their experience with agile product development: rarely cases studies or references from other clients are requested.  Fixed contracts just make things worse.


External Product Development

This product development type is probably the best candidate for agile approach: customers are real, real money exchanges hands, competition is real and often strong, fast market changes require product companies to be nimble, light-footed and fast-responding.  However, there are still some challenges here.

Specifically, the communication channel called “Clarifications” (between Technology and external Customer) that is crucial in agile development (e.g. Scrum) is usually weak or does not exist at all.  Due to geographic distribution, legal contracts and compliance issues, it is challenging to co-locate real customers and developers and have them directly engage with each other.

Since everything flows through Product Management /Marketing/Business internal organizational layer, technologists get their information second-hand.  This also leads to producing additional overhead (processes, documentation, and approvals) by a product development company:  multiple external communication channels and competing priorities (different customers) that must be collected/filtered/prioritized and then single-threaded to technology.  To complete this job, internal Product Owner will require help.  This is how internal Business Units grow thick and as this happens more waste/overhead is introduced to a system.

Dec 19-21, 2016. LeSS in New York: CLP Class & Meetup

December 19-21. This week, there was a mind-blowing 3-day experience of system thinking and organizational design modeling with Craig Larman.  Having been at wide array of Craig’s training and public presentations in the past, I was still overwhelmed with volume of education that this class offered.  One of the main distinctions ( imo – improvements) of this LeSS training from the previous, was the emphasis on hands-on system modeling by class participants,  with the use of Causal Loop Diagrams (CLDs). Personally, being a huge fan and frequent user of CLDs,

I was able to graphically reinforce, once again, postulates of LeSS,
while modeling organizational design and inter-connecting system variables, as well as identifying which relationships are
Causation and which ones are Correlation.

Below, are some visuals that illustrate the course dynamics and working artifacts that were produced.

Class Kodak Moments:

Course Artifacts:

Course Highlights (personal):
  • If we go back to history and recall how Agile Manifesto was originally created and naming chosen, “Agile” was never meant to describe ‘speed’, ‘efficiency’ and ‘cost effectiveness’. It was always meant to describe Adaptive-ness.
  • To main goals of LeSS: to maximize Customer Value and ensure continuous learning
  • Organizational Structure is one of the most important, 1st Order Factor that influences System Dynamics.  (Some other 1st Order Factors are # of sites, group structures, organizational roles and hierarchies.)
  • Many junior/unseasoned agile coaches give their clients a distorted coaching advice about agility, by recommending to focus only on 2nd and 3rd Order Factors (e.g. values, norms, culture)  and omitting 1st Order Factors.  By doing so, they (coaches) misguide clients to go after local manifested/superficial problems, while leaving real underlying, systemic issues unchallenged.
  • Young, ambitious, career-seeking senior leaders that are in active pursuit of promotion are not the best supporters of agile transformations from within a company. Most likely, they will view agile as a way to fast-track their career and after 3-5 years of supporting the “movement” they will leave their role and move on.  There is a high chance that someone, who takes over will “undo” what was done.
  • While using Causal Loop Diagrams (CLDs) it is important to distinguish between Correlation and Causation relationships that connect Variables
  • Team structure sub-optimization has multiple “dimensions”, e.g. too narrow-defined Products or teams built around Components
  • As per TPS, Kaizen does not mean “small”
  • Budgeting is rarely an issue in product companies. However, it is a BIG issue in internal development companies (e.g. banks)
  • John Kotter (The Heart of Change): <paraphrasing>”… get skeptics and resistors out of the way…. there is a low chance they will support changes…
  • While delivering agile/scrum education, strive to focus on an entire team, not of separate roles (e.g. SM, Team, PO).
LeSS Meetup Kodak Moments:


11/30-12/2 – Certified Agile Leadership (CAL) Class in Orlando


This was an amazing two and a half-day working session, with participation of organizational leaders and enterprise coaches coming together from different parts of the world: Sweden, Costa Rica and USA.

One of the co-creators of Certified Agile Leadership (CAL) course – Pete Behrens took the mixed group, consisting of managers and coaches through a very engaging training experience. CAL curriculum was geared towards improving theoretical expertise and practical skills of people that operate in various agile leadership capacities.  Presence of both, managers and coaches in the same room throughout the entire training, ensured that many real-life scenarios  were simulated and explored in-depth.

There were a few Enterprise Coaches in the room who assisted the instructor with facilitating the course: Rick Regueira,  David Barnholdt and me (Gene Gendel).

Note: It is worth noting that with exception of a short Case Study presentation, where the use of .ppt slides was inevitable, the entire course was based on very direct interaction, facilitation and the use of very effective graphic visualization techniques (see below).

Stage Setting: Learning Objectives

CAL’s learning objectives included the following (top themes):

  • Governance policies that enhance organizational agility
  • Organizational Structures that support agility
  • Factors that influence organizational culture
  • Alignment of leadership development framework with agile
  • Alignment of organizational metrics with agile behaviors
  • Management trends and their historical fit with business
  • Economic/market factors that lead to rise of agile approaches
  • Relationship of complexity/uncertainty to agile approaches
  • Organizational challenges with understanding agile
  • Benefits of becoming Agile Leader
  • and more…


Case Study Review

The goal of this session was to deconstruct two types of case studies presented, to better understand how two different companies try to be more agile, respectively. The two companies presented were: Consulting Company (name obfuscated), with its “Create” culture and SalesForce with its “Compete” culture.

Both companies were analyzed along the following three dimensions:

  • Organizational Structure
  • Organizational Policies
  • Organizational Metrics


It was interesting to see how agile works differently in the environments of Creation vs. Competition.

Types of Organizational Culture

Deconstruction of the use cases (above), was followed by a conceptual discussion of “Agile Culture Compass”, where the following four types of Organizational Culture were plotted on the dial:

  • Collaborate Culture
  • Create Culture
  • Control Culture
  • Compete Culture

Then, some additional additional dimensions, were added to the ‘dial’, as illustrated below:orlando_cal-10

Exercise: Graphic Visualization

In the practical exercise that followed, the class was tasked with graphic visualization of the four types of Organizational Culture (click on the thumbnails below to enlarge):

orlando_cal-4 orlando_cal-3
orlando_cal-2 orlando_cal-5

Exercise: “In or Out” Canvas

In the next session, the class was presented with the four “poles” of Agile Culture Compass (four different culture types) and a variety of attributes, that were ad-hoc mapped to the cultures. Attributes used were: values, principles, norms, companies’ names, organizational goals/vision, etc. The class was tasked with properly re-mapping the attributes to the most suitable cultures: some attributes remained “In'”, some had to be moved “Out”.

What is shown below is the final state: after all available attributes were properly mapped to the respective culture  (click on  the thumbnails below to enlarge).

orlando_cal-6 orlando_cal-9
orlando_cal-7 orlando_cal-8

Types of Leadership

orlando_cal-1In this discussion the group took a deep dive into leadership types.  The following three types of leaders were identified:

  • Expert Leader – a person who gets things “done” by actually doing work.  Such leader thinks of himself as a “jack of all trades”, a hero, a super-performer, commander-controller, who wants to be a primary channel of information flow, in all directions. Such person wants to control all communications in 1-on-1 relationships, with his personal presence.

  • Achiever Leader –a person who gets things “done” by delegating work to others, while retaining tight control of everything that takes place.  Such leader, while he micro-manages others, is very competitive and strives to outperform his peers but he knows how to do so by manipulating his subordinates, to do work for him, “his way”. A leader like this, usually has a good grasp of organizational strategy and is focused on others, pushing them to the their performance.  His main message to subordinates is “are you with me or not?”.

  • Catalyst Leader – a person who gets things “done” by empowering others and stepping back.  Such leader prefers de-centralized decision making matrix over centralized control, and creates an environment of safety and trust.  In his vocabulary, the word “we” supersedes the word “I”.  He acts as a coach-enabler and views other people as valuable assets, not as mechanical executioners.  A leader like this has a great vision and is focused on high-level goals.


(click on the thumbnails below to enlarge):

orlando_cal-14 orlando_cal-39 orlando_cal-38

Discovering more System Variables

In this exercise, the group explored additional factors (system variables) that influence organizational agility.  This was done in the form of graphics (click on the thumbnails below to enlarge):

orlando_cal-15 orlando_cal-16 orlando_cal-18

 Reconstructing It back:

This was one of the key “aha” moments in the workshop.  After identifying and thoroughly discussing the three types of leadership (Expert, Achiever and Catalyst) the following important discovery was made:

  • Both, Experts and Achievers mostly operate under conditions of Duality: black OR white/right OR wrong
  • Catalysts, for the most part, operate under conditions of Multiplicity: shades of gray, options (AND). They are also much more collaborative


 Exercise: More System Variables

In this exercise, more factors (system variables) were discovered and related to organizational agility:

  • Economics
  • Complexity vs. Uncertainty
  • Management Trends



 Organizational Challenges: Statistics

In this session, every manager and organizational coach was asked to share some of the most common organizational challenges with agile adoption that they have experienced at work or while serving their clients.

Then, the group reviewed and further discussed industry research statistics on organizational challenges (below):orlando_cal-22

Exercise: What Leaders Need to Understand

In this exercise the class was divided in a few groups, with each group working on graphic representation of the following three areas, where organizational leadership must have expertise, in order to succeed with agile:

  • Organizational Structure
  • Organizational Policies
  • Organizational Metrics

Then, the class discussed why so many organizational attempts to become more agile fail.  Success rates of agile efforts coming from inside vs. outside were discussed (click on thumbnails the below to enlarge):

orlando_cal-23 orlando_cal-28 orlando_cal-29 orlando_cal-30

Change vs. Transition & What’s In-Between?


The group made a very interesting distinction between two frequently overloaded terms: Change vs. Transition.

  • Change = EVENT –  was defined as a more abrupt, binary process that could be metaphorically described as“Lets Go”, coming from very strong and passionate leaders
  • Transition = JOURNEY was defined as a more gradual process, where things happen much slower


The group also identified a number of reasons why organizational changes often fail and how improving values of organizational leaders could bring  more sustainable changes.


 What Should Leaders Focus On?

The class discussed the most important areas of focus for organizational leaders who want to implement agile changes and organizational coaches who want to be successful in assisting their clients in agile transformation journeys. Two main focus areas were identified:


 Exercise: Causal Loop Diagram (CLD) to explore System Dynamics


Causal Loop Diagrams (CLD) the graphic visualization tool that is widely used in Large Scaled Scrum (LeSS) to illustrate system dynamics, was used in this practical exercise (facilitated by me) to discuss the relationship between high levels of  employee engagement and its downstream benefits to an organization.  The use of this light visualization “tool” sparked a lot of interest in class and was used in the following exercise to discover organizational impediments, bottlenecks & friction (see below).

Exercise: Organizational Impediments, Bottlenecks & Friction

This practical session revealed a number of already known system variables, whose relationship and cross-dependencies, however, were not immediately clear. By using CLDs, many of such relationships were discovered. Also, in the course of the discussion, people came to agree that bottlenecks (“soft” obstacles) and impediments (“hard” obstacles) are best not to be split as separate groups, as they, effectively, mean the same thing. A more effective way of distinguishing between “soft” and “hard” obstacles, could be – by ranking them (click on the thumbnails below to enlarge):

orlando_cal-42 orlando_cal-43 orlando_cal-44

Agile Leadership Benefits

By the end of the workshop, the class came up with the list of benefits of agile leadership style. They were also graphically illustrated by using a flavor of CLD approach:


Workshop Feedback (Incremental)

Throughout the workshop, feedback was provided incrementally, and the format used, closely resembled a sprint retrospective.   Questions, suggestions and comments were addressed continuously, in the order of arrival.



This training workshop was a great mind-shaping exercise for everyone.  The sequence and style of content delivery tremendously helped with information absorption and its retention.  Small group break-outs and role-playing helped experimenting with new coaching and facilitation techniques.  For everyone in the room, it was a great opportunity to share every-day challenges and “domestic problems” but in a very safe and uninhibited way.

For me personally, as an organizational coach, this course helped tremendously to systematize my existing knowledge as well as grasp additional concepts that I will be putting to use in a near future.

This course is strongly recommended for managers, senior organizational leaders and organizational coaches that want to learn system dynamics and better understand implications of organizational design and culture on overall system agility.

How to Cultivate T-Shaped Developers?

Scrum Team.  It is a cross-functional group of developers that are able to deliver complete business functionality (“from concept to cash”) to customers in a short time-frame.  The easiest way to make sure that a team is cross-functional is to compose it of developers that are initially multi-skilled and possess both, primary and secondary skills.  Such people are usually referred to as T-shaped, where “…the vertical bar on the T represents the depth of related skills and expertise in a single field, and the horizontal bar is the ability to collaborate across disciplines with experts in other areas…”[wikipedia].

There is a common miss-belief that T-shaped individuals are hard to find.  Here, are some of the most frequently heard concerns that we hear from hiring managers and HR:

  • “Most people we come across do not have enough technical diversity”
  • “It is hard to find individuals with certain skill set in a particular geographic area. Best folks with a required skill set can be found only in a particular area”
  • “We are having difficult time encouraging our team members to learn secondary technologies on the job”

Below are some suggestions for how to acquire or internally cultivate and retain good, multi-skilled, T-shaped developers:

Frame job requirements clearly:

Companies must ensure that their job requirements, clearly state that they are looking for multi-skilled workers.  Jobs must be titled accurately, including the mentioning that people are expected to work on Scrum teams, wear multiple hats, contribute to learning of other their teammates and actively learn themselves.  Still, very commonly, we see job descriptions that are titled in favor of conventional single-specialty roles (e.g. BA, Java back-end Developer, QA or Architect).  While commonly used buzz words, like ‘agile’ and ‘scrum’ are still mentioned in job requirements, proper meaning of these words is not communicated well enough and sometimes is simply misstated.  Also, the importance of having multiple skills is reduced by emphasizing titles of conventional, single-specialty roles.  Therefore, it is not surprising that people that get attracted to such job requirements, rely merely on their original, single skill set, and don’t have much appetite for extended learning and becoming T-shaped.

Assess candidates properly, before hiring, and ask for things that really matter:

Today, in a typical hiring process, many companies still make too much emphasis on things that matter little.  Mainly, due to outdated HR procurement methods and hiring policies, but also, to some extent, because companies rely on inadequately trained recruiting staff (sometimes, external), job candidates get “screened” for wrong things, and under wrong conditions.  Some pre-qualifying, “templated” questions (e.g. “are you able to to work under stress?”, “are you an outstanding performer?”, “can you be a great team player?”, “can you describe a difficult situation and solution that you came up with?”, etc.) have little to do with real job requirements and should be treated as ‘common sense’.

The biggest downside of using such low value qualifiers in screening is that they cost time and shift focus of both, interviewers and candidates, away from things that really matter.  Also, such phone screening by a single person (e.g. HR or hiring manager) are more prone to bias, and misinterpretation.  Phone screening could still serve some purpose if it scope is reduced to something basic, and much less time consuming. For example, determination of a candidate’s legal status and work permission to work or scheduling an in-person interview.

Note: discussing compensation ranges is not advisable by phone, as some strongly qualified candidates, with slightly out-of-range salary expectations, may get disqualified by screening people that don’t have the best understanding of a relationship between “service value and cost of service” and do know know where compensation range should be tweaked for a right candidate.

It is more advisable to reduce time spent on phone screening, in favor in-person interviews with inclusion of practical assessment of individuals’ technical knowledge, their cross-functional capability, and ability to operate in Scrum team settings.  To that end, it makes more sense, to involve an entire Scrum team (future team where a candidate will work for) in multiple steps of an interviewing process, including assessment of social, soft and technical skills, while using simulation techniques that mimic a team’s daily dynamics.

Pay developers well:
  • “Good, cross-functional developers are hard to find”
  • “There are no experienced Java coders in Chennai”
  • “The best architects on East Coast of the US are in Boston”

We hear these arguments a lot.

Truth be told, good developers can be found almost anywhere; companies just need to figure out better ways of attracting them. This includes, and often comes down to, paying people fairly and competitively.

No single geographical place in the world miraculously grows “the best” technologists of a one kind.  Certainly, some trends exist, perhaps, where workers relocate, as they follow large companies that offer jobs. But often statistics that describe these trends taken out of proportion, data is misinterpreted and numbers are exaggerated.  Ability to find best developers of one type, in one geographic area, most likely, hints to another, more likely theory: companies that claim the above “phenomena” are themselves responsible for creating conditions for such disparity in the first place.

Often, in pursuit of cheaper labor, companies consolidate all their developers of more expensive skill set (e.g. Java developer is more expensive than HTML developer) in the cheapest geographic location.  What companies don’t realize is that this decision creates the following challenges for Scrum:

  • Firstly, this goes against key principles of team collocation that are critical in Scrum: consolidation of all developers of the same skill set in one geographic location, makes it hard to co-locate cross-functional teams. Effectively, with this approach, companies create collocated component teams, at expense of co-located feature (a.k.a. scrum) teams – but it is the latter that is best for agile product development.
  • Secondly, being collocated with people of the same exact skill set makes it hard for individuals to learn new skills from one another (condition of technological “in-breeding”).
Ensure that work environment and team dynamics support knowledge sharing between developers:

One of the most critical requirements that ensure that individuals are willing to share knowledge with their teammates while working, is the existence of safe collaborative environment, free of internal competition.  Willingness to cross-pollinate with skill set (and become T-shaped) is much higher on teams and in organizations, where people perceive each other as mutually supportive peers, not as rivals.  This can be achieved by strongly supporting ideas of collective ownership and shared responsibility, by emphasizing  the importance of team performance, while discouraging individual heroics, knowledge withholding and silos.   Organizational cultures, where individual performance is overly empathized and individual performance appraisals drive bonuses and monetary insensitive, employees’ willingness to share knowledge, teach each other and contribute to mutual T-shaping, while delivering work together, is significantly reduced.  Many other undesirable behaviors (e.g. hostility, favoritism, etc) are frequently seen as well.

This fundamental improvement in working conditions requires strong commitment and support of senior leadership.

Provide internal career path for hands-on developers, to ensure long-term engagement:

Today, a typical career path for a successful technologist requires to sacrifice hands-on work, in favor of managing other people.   Developers think that by becoming a manager and getting in charge of more junior workers, will increase their own chance to be promoted, move up a hierarchical ladder and collect more pay.  This is commonly seen in companies with very complex organizational structures and command & control environments but less so, in companies with less hierarchical, flattened structures. This anxious pursuit to become a “manager-in-control”, reduces a number of good developers that can deliver value, by performing hands-on work.  People are reluctant to remain in the role of a developer for too long because it is perceived as stagnation of professional growth.  Also, people feel that it is more difficult to get a decent pay increase by simply remaining in the capacity of a “worker bee”.  Many good developers with already strong primary skill set are reluctant to acquire additional technical skills, because they view this approach as a “low return on investment”, comparatively, to pursuing a management role. To them, becoming a manger is a more certain way to grow in ranks and in compensation.

What can companies do to address individuals’ reluctance of remaining in a role of a hands-on developer?

Arguably, companies have to decouple the process of promotion (gaining seniority, reputation, organizational weight) and compensation increase from acquisition of “power tower” control.  Individual workers must have assurance that by keeping their hands on-technology, deepening their primary technical skills and broadening secondary skills, they will not be missing out on career advancement and ability to make a better living.  People must also be assured that by becoming higher compensated, over time, while still remaining in a capacity of “hands-on doers”, they will not be becoming an easy target for downsize/force reduction, in favor of younger and “cheaper” work force that will come from colleges and universities.  Here, a strong bet is being made on the assumption that senior hands-on workers, with longer industry experience, will have much more technical expertise that is coupled to business domain knowledge – something that shall make their higher pay well justified by employers.

Again, this organizational change is dependent on decisions that come from senior echelons of organizational structures.


November 3 – Mike Beedle on Enterprise Scrum

This was a blasting event, with one of the co-signers of Agile Manifesto: Mike Beedle, being our honorable guest.

Mike’s presentation (outlined below) was followed by comprehensive Q&A.  Some folks were wise enough to have Mike hand-sign Agile Manifesto copy 🙂

Summary of Mike’s talk:
  • Enterprise Scrum (ES) goes much further than Technology alone.  ES grows Unicorns and transforms Dinosaurs.  ES is:
    • Balanced Management
    • Integrated Agility
    • Principles & Techniques
    • Management Framework
  • ES mandates Management of new breed.  Today, most of Management taught at colleges and universities is completely outdated.
  • In 10 years from now, “S&P 500 Membership” will be different than it is today. And companies that don’t become more agile will know it first
  • Conventional performance management is an outdated process that must be redefined
  • The most effective way to ensure a successful agile transformation (especially, at a large organization) is to “spin off” a small internal entity that would be free of certain existing counter-agile organizational laws, mandates, norm and behaviors.  Such organisation should be ‘real’, having its “front-” and “back-end”
  • Financial firms that don’t  also think of themselves as technology firms (worse yet, outsource their technical solutions elsewhere) will have difficult times in years to come
Some Kodak moments below:




meetup_mike_beedle-11meetup_mike_beedle-3 meetup_mike_beedle-4




October 18 – LeSS Talks: LeSS PBR Session Simulation, with User Story Mapping

This was another very exciting and highly collaborative Large Scale Scrum (LeSS) meetup session – took place in NYC this week.

The meetup group simulated LeSS Overall Product Backlog Refinement session, by a few Feature Teams that collaborated with each other and Product Owner, while using Story Mapping technique.

The “Product” in scope was the virtual collaboration tool itself – Nureva Span.  All of its existing (currently, available in-production) functionalities were “reverse-engineered” into “done” use stories (this was done by me, Gene, before the session) that were placed on Story Map canvas.  The purpose of this preliminary exercise was to create a point of reference for the group – to create a point of reference for future product brainstorming.

The role of the product owner was played by one of the facility hosts (Ellen) – she knew the tool very well, from a stand point of existing features and strategic business plans of the company-producer.  Another host facility (Geoff) was asked to pick up the role of a well-informed SME that would be able to provide clarifications to teams’ questions, without dependency on the product owner.

The group of attendees was split into two “feature teams”; skillset and familiarity with the tool itself (some attendees were meetup regulars, whereas others were newbies) were mixed up.

The product owner described to the teams her most important strategic goals (they were based on real-life demands from the company’s sales force and market feedback obtained from existing customers).  She also gave a few examples of possible user stories that she would find most valuable (highest priority).  This primed both teams to engage into a very collaborative discussion: flushing out additional user stories, mapping them and aligning with larger, overarching features that already existed in the product and were displayed on the virtual canvas.

The product owner used the concept of iterative delivery to “schedule” hypothetical releases and provided guidance to the teams, in which order user stories would need to be developed to deliver highest value first.

Both teams also attempted to size user stories, by using Small, Medium and Large scale (there was no time to use Planning Poker).

During the meetup summary the product owner admitted that it would be worthwhile for her and SME to export all created user stories from the canvas and pass them on to the actual product development teams that were responsible for designing and supporting the collaboration tool, hoping that wishes of end-customers (meetup people) would eventually materialize as product features.

P.S.  Before the event, the meetup group was advised to review the following references:


Kodak Moments:

10-18-2016-8 10-18-2016-7 10-18-2016-6 10-18-2016-5 10-18-2016-4 10-18-2016-3 10-18-2016-2


September 13 – LeSS Talks: LeSS Conference in Amsterdam: Lessons Learned

Many thanks to Certified LeSS Practitioner Vicky Morgan for spearheading today’s meet-up and sharing with everyone her experience from LeSS Conference in Amsterdam a few weeks ago (also, please review Vicky’s summary of the conference on this page)

Below are some Kodak moments from last night’s event:


sept_13-2 sept_13-1 sept_13-7 sept_13-6 sept_13-5 sept_13-3

August 30-31st: The 1st Large Scale Scrum Conference in Amsterdam

The first ever Large Scale Scrum (LeSS) Conference took place on August 30th -31st of 2016.  Budgeted to accommodate around 150 people, it was oversubscribed (around 180).

The event took place in the beautiful city of Amsterdam, in the cathedral style audience hall Rode Hoed.

What you will find summarized below, are the topics that were that were most interesting to me (Gene) personally.   But also, my friend and colleague Vicky Morgan made a thorough recap of the entire event at the bottom of this page.  So, please, spend some time reviewing as well.

Also, please check out:

But first, a few entertaining Kodak moments (hover over images to see who got caught in scope):…


day_2_2day_1_1 day_1_2 day_1_3 day_2_1day_2_11day_2_19


Large Scale Scrum Communities Discussion

There was very high interest from many conference attendees in local LeSS communities.  People wanted to learn how the can ensure continuity of learning LeSS, once they leave the conference and return home.   Since NYC LeSS community is the oldest and the biggest at this moment, I (Gene) was called upon share my experiences of creating and supporting the community.   I covered the following aspects of NYC LeSS community:  Birth/Life Span, Count/Composition/Growth/, Venue/Frequency/ RSVP vs. Attendance statistics, Format, benefits for Local Community, potentials of Global Networking, Communications/Announcements, Public vs. Intra-company communities (pros & cons).

Among many other people that attended to the discussion, the folks from Germany/Berlin, UK/London, Italy/Rome and Finland/Helsinki  seemed to have more interest.  As a an immediate result of that, Berlin LeSS Community was born:



day_3_2 day_3_3 day_3_6 day_3_11 day_3_12

LeSS Bazaar

At the beginning of the conference, all participants were split in multiple teams, with each team working throughout the conference to produce something “shippable”. It could be an idea, a concept, a tool…anything.  At the end of the second day, there was LeSS Bazaar, facilitated by Craig Larman, where each team had to present its product to others.  Each conference member was asked to used “LeSS money” to vote for what they felt was the best product.

day_3_25 open_space_7 open_space_12 open_space_11 open_space_10 open_space_8 open_space_


Event Summary by Vicky Morgan


Self Designing Teams Workshop, by Ahmad Fahmy

  • Forming Communities – Facilitation Techniques – Constellations
  • Discussion vs. Dialogue  – Peter Sengue

Story of LeSS, by Bas Vodde

  • We can go really fast un the wrong direction or slowly in the right direction;

LeSS is about focusing on going in the right direction

  • Shu – ha – ri
    • The original books were written at the ha-ri level
    • New book is at the shu level
  • Framework Prescriptiveness
    • add prescription around the points that create transparency – Scrum does this well
    • LeSS is prescriptive on organizational structure as structure has to be changed in order to have an effective transformation
  • LeSS
    • Basic rules – LeSS rules
    • Guides clarify how you adopt the rules
    • LeSS complete picture
    • LeSS principles are retrospectively added
  • More with LeSS
    • Build your method up – don’t tailor it down
    • LeSS is about how you do scrum with multiple teams vs. one of the product teams doing scrum

Port Of Rotterdam, by Rutger Van Dijk

  • Business value – what’s important and how do you measure it?
  • Simple visual reporting to upper management; do not try to force “agile” reporting onto upper management
  • Exploring user stories
    • Analyzing users and their behaviours
    • Gemba – go see
    • Users visit the team
  • Obtaining Management buy-in
    • Stop building features for management, build for customers / end users; PO has biased assumptions
    • Physically delete stories – indicate symbolically that you cannot build everything
  • Distributed team
    • Team bonding activities
  • Culture
    • How are consultants/freelances treated? Are they “resources” / a pair of hands or valued team members?
  • Hire for mindset
    • Learn while doing
    • Lunch sessions with online courses (plurosite)
    • Pair-programming (with expert)
    • Special code camps
  • This worked:
    • Build what you know will be needed, not what you think will be needed
    • People need to be around to explain why something is needed. If not around then do not build or cancel the sprint
  • This did not work:
    • Every team member working on their own stories
      • Less motivated
      • Less productive
      • No project hygiene
      • Complete disarray
    • Reduced involvement of management (and you definitely need them)
  • The Wave
    • There is no sea without waves
    • Everything is changing all the time
    • Experimentation and learning


Owning (versus Renting) Your System, by Craig Larman 

  • We need to own our ideas
    • Employees should be involved with the decisions themselves – leads to employee engagement
    • When you give a person an idea, they are renting the idea and thereby do not own the idea
  • 2014 study: 5 keys to a successful Google team
    • Psychological safety was far & away the most important of the 5 dynamics unearthed
    • The foundation of psychological safety is that team are empowered to ask “why” enabling them to understand “why”, thus enabling teams to own ideas
  • Meaningfulness
    • Connection with real customers
    • Involved In the whole rather than the part (degree that employees are involved in end-to-end
  • Why Feature teams vs. Component teams
    • In LeSS feature teams work directly with real customers
      • This intentionally translates into teams owning the ideas and improving the system
      • In addition to reducing coordination and hand-off waste
  • Local thinking vs. system thinking
    • System Optimizing Goal
      • Although there are many system optimizing goals, what is really important is that the group decides what the system optimizing goal is. This is a very important question
      • Is the current system / team optimized for this goal?
      • What is the behaviour of the organization/system?
    • Why would employees care about the system optimizing goal?
      • Are the team involved in strategy?
      • Are the team directly engaged in owning the idea of the product?
      • Are the team directly engaged with the customer?
      • Are the team just ditch diggers?
  • Owning the answer
    • Why is there 1 and only 1 backlog in LeSS?
      • Team should find the answer themselves


Technical Practices In Less. Why Are They So Important And So Hard?  by Terry Yin

  • Organizational agility is constrained by technical agility
  • Technical agility = people problem
  • Organization
    • Self-leading teams instead of maximizing resource utilization
      • Resource utilization – utilization of what people already know – known-known
        • Delivery culture
        • Prevents learning from happening
      • Focus on known-unknown instead of known-known
  • Education
    • Help people to overcome the CS cliff
    • Be the village
  • Model
    • Adopt the craftsmanship metaphor
      • Craftsman model
        • Apprentice
        • Journeyman
        • Master
    • Don’t cheat too much
  • Technical Excellence
    • Iterations: product > feedback > improve
    • Practice & More Practice
    • If the organization doesn’t promote practicing then you cannot have technical excellence


Impact Mapping with Innovation Games, by Gojko Adzic

  • Squirrel-driven product management
    • Agile at scale – BBC – 75M  spent with no clear definition of benefits
    • Large scale failure – FBI Case delivery system $450M spent before discovering something was wrong
    • Status report was green and occassionally amber for years
    • Analysis: 10000 inefficiencies in the system. Nobody was following any process. The only reporting was reporting on delivered activity
  • Scrum reporting focuses on delivery activity – delivered user stories/ features / burn-up & burn-down charts / velocity / story points
    • velocity reporting = this many people working this many days of the week.
    • Story points = how much money you have spent
  • Underpants gnomes progress reporting (story points)
    • Phase 1: Collect underpants
    • Phase 2: ?
    • Phase 3: profit (lagging indicator)
  • Study: 1/3 of initiatives delivered expected results. 1/3 no visible business impact, 1/3 = damaged the organization
  • Can we find something to report on that is indicative of success? Anton Zadorozhniy.
  • Successful initiatives tend to change somebody’s way of working.
  • Doug Howard – “How to Measure Anything”
    • People measure what they think is easy to measure
  • Impact map  = visualization of the plan.
    • Helps visualize what you are doing and why you are doing it
    • Helps solve underpants gnomes reporting problem – report on achievements instead of delivery reporting
    • Helps with business analysis in general (business analysis often fails as you analyze an option that someone else had already chosen [Tim Brown])
  • Innovation Games: Impact Trump Cards
    • A lot more options to analyze behavioural changes
  • Open Impact Mapping

August 23 – LeSS Talks: Agile Budgeting & Finances: unveiling conventional management mistakes

Last night’s meetup produced an exceptional turn-out of people. There were some guests from the UK: friends and colleagues.

The following key points were covered:

  • Triple Constraint Triangle of Conventional Management
  • Why Agile Community understands Budgeting better than some finance people?
  • Why Management Area is so “untapped” in terms of improvements?
  • Why did Borealis abolish traditional budgeting?
  • Decomposing Budget into: Forecasts, Targets and Resource Allocation
  • Forecasts vs. Targets
  • “Rolling” Forecasts vs. Dynamic Forecasts
  • KPIs: good, bad
  • Balances Scorecards against Budgets – what usually wins?
  • Splitting a bag of cash
  • Does Meeting a Budget Drive Individual Performance?
  • What do Monetary Incentives to do People?
  • Why do we need Partnership between HR and Finance?
  • Frequently ignored scientific evidence
  • How to overcome resistance?
  • Evolution vs. Revolution: what is better?
  • Who is doing “this”
  • Agile budgeting for scaling

Note: a number of folks approached, asking to share the materials presented. Please, use the form at the bottom of this page, to receive the materials.

Some Kodak moments captured:


meetup_aug_23_11meetup_aug_23_7 meetup_aug_23_8 meetup_aug_23_9 meetup_aug_23_5 meetup_aug_23_4 meetup_aug_23_3 meetup_aug_23_2