Category Archives: Team Dynamics

May 19-22: Global Scrum Alliance Gathering | AUS-TX

An amazing 2019 Global Scrum Alliance Gathering (May 19-22), organized by SA staff that brought together a record-high number of professionals from around the globe and had countless amazing events – too many to describe them all in one newsletter. 🙂
Here, I would like to  recap what committed to my memory the most:
  • Keynote presentation by Daniel Pink
  • My personal experience from servicing the ‘Fans of LeSS’ booth, attended by hundreds of people
  • Highlights of my own presentation that draw more than 100 people: “How to Stop Deterioration of Coaching Quality: Industrially and Organizationally” and feedback from the room
  • Coaches Clinic and Coaches/Trainers Retreat highlights 

Keynote Presentation by Daniel H. Pink

During his keynote presentation, Daniel H. Pink (the best-selling author, contributing editor and co-executive producer, known world-wide) shared the highlights of his new book: The Scientific Secrets of Perfect Timing.

Pink’s Synopsis: “We all know that timing is everything. Trouble is, we don’t know much about timing itself. Our business and professional lives present a never-ending stream of ‘when’ decisions. But we make them based on intuition and guesswork. Timing, we believe, is an art.  But timing is a really a science – one we can use to make smarter decisions, enhance our productivity, and boost the performance of our organizations.

Some highlights from Pink’s talk:

Scientifically and statistically, both humans and apes, have the lowest well-being at mid-life.

Therefore, D.Pink’s recommendation on how to deal with such unpleasant mid-points, are as follows:

  • Beware [of such mid-points]
  • Use midpoints to wake up rather than roll over
  • Imagine you’re a little behind

Then, D. Pink also stressed that there are hidden patterns of how time-of-day affects our analytic and creative capabilities – and how simple work rearrangements can improve our effectiveness. For example, when a person makes an appointment to a physician, it is best to ask for a morning time slot, instead of afternoon slot, since physicians tend to have more analytical capabilities before lunch.

D. Pink’s next point was that as individuals get older, at the end of each decade, they are more prone to take certain actions that psychologically make them feel younger. As an example, he used statistical data of marathon runners: people are most likely to run their first marathon at the ages that are just at the brink of next decade: e.g. 29 or 49 years old.

“Because the approach of a new decade… functions as a marker of progress through the life span…people are more apt to evaluate their lives as a chronological decade ends, than they are at other times.”- Daniel H. Pink
How about psychological reaction to the fact that something will be GONE and the time when it will happen is coming up shortly?

In one case study (left image), when a person was given one chocolate candy at a time, and was asked to give feedback about its taste, a response was usually consistent, for each subsequent candy. However, as soon as a person was told that it was the last candy to taste, feedback about how a candy tasted became significantly more positive.

In another case study (right image), when a group of people was asked to fill out a survey, in order to receive a certificate, before it expired, responses were different, when conditions were set as “will expire in 3 weeks” vs. “will expire in two months”.  Apparently, proximity of expiration date made people much more responsive to the request to fill out a survey.

D.Pink’s next point was about how half-time checks can shape our behavior and impact final results. According to D. Pink, scientists and researchers really like statistical data from sports because it is ‘clean’.  Here, using an example of basketball teams, when teams play a game, the following can be observed, depending on half-time results:

  • Being significantly behind – usually results in a loss
  • Being significantly ahead – usually results in a victory
  • Being slightly behind – motivates people to step up and put an extra effort, which results ultimate victory
  • Being slightly ahead – makes people relaxed, less focused and less persuasive, which results in ultimate loss

As such, there is a conclusion:

“Being slightly behind (at half-time) significantly increases a team’s chance of winning” –D.Pink

Fans of LeSS Corner
A small group of Certified Scrum Trainers and Certified Enterprise-Team Coaches, supported the Large Scale Scrum (LeSS booth):  Fans of LeSS.

At least a few hundred people has come by the booth, asking for information about LeSS.
The booth servants received the following three biggest take-away points:

  • Unfortunately, still not too many people are aware of LeSS.  This is not to be confused with attempts or successes of adoption.  Rather, this is about general knowledge of what LeSS is. Ironically, the booth was labeled “Area 51” – the world’s best kept secret :).
  • Once being explained what LeSS is, how simple and common-sense it is, for many people, it has become an ‘AHA’ moment. The most awakening moment was understanding the difference between ‘global and local optimization’, ‘deep and narrow, as opposed to broad and shallow’, ‘owning vs. renting’.
  • Amazingly, how many people shared the same, almost standard complain/pain-point: “… we are currently using a very complicated, monolithic and cumbersome process (usually referring to some widely marketed XYZe framework), with multiple organizational layers involved,… and it creates lots of overhead, waste and friction,… practically nothing has changed in our workplace since the time we adopted it…same people, same duties and responsibilities (practically) BUT different terms, labels and roles … We really don’t like what we have to deal with now and our senior management is also frustrated but it seems that there is really nothing we can do to fix it at the moment…“.

“How to Stop Deterioration of Agile Coaching Quality: Organizationally, Industrially?” (my own presentation)

The goal of my presentation (Gene is here) was to discuss with the audience:

  • What is the problems’ origin [as it is derived from the title]?
  • Examples of the problem’s manifestation?
  • How can we solve the problem?

Throughout the course of my presentation I:

  • Exposed some classic systemic dysfunctions that sit upstream to the problem in scope.
  • Gave some examples of the problem, by using cartoons and satire
  • Delineated between the problem aspects, coming from outside organizations vs. siting on inside
  • Described types of internal (organizational) coaching structures that are to be avoided vs. tried
  • Gave some suggestions on what to avoid vs. what to look for in a good coach
  • Gave additional recommendations to companies, coaching-opportunity seekers and companies’ internal recruiters

“Download Presentation as PDF”


…and a some additional highlights from the gathering….
The Coaches Clinic – for 3 days
This traditional ‘free service’ by Scrum Alliance Enterprise and Team coaches and trainers what at the highest ever: 300 people were served in total,  over  course  of  3 consecutive days.


Certified Enterprise & Team Coaches and Scrum Trainers Retreat – Day 0:

This year brought together the biggest ever number of CECs-CTCs and CSTs.  One of the most important themes that was elaborated: how important it is for guide-level agile experts (CECs, CTCs, CSTs) to unite together in a joint effort to change the world of work.

Note: Thanks to Daniel Gullo (CST-CEC), who generously created for each attending Certified Enterprise Coach – colleague a memorable gift: Coach’s Coin with The Coach’s Creed:

  • CARITAS: Charity, giving back, helping others
  • COMMUNITAS: Fostering community and interaction
  • CONSILIARIUM: Counseling, consulting, The art of coaching
2020 Global Scrum Alliance Gathering is in NEW YORK(registration is not open yet)

Tips To Run ‘Big’ Retrospectives

For any team that uses scrum framework, a retrospective is a mandatory event that takes place at the end of each sprint.  It is an opportunity for a team to reflect on their most recent learning, while it is still fresh in everyone’s mind.  There are many tips, techniques and tools for running a retrospective.  They start with very basic guidelines of the Scrum Guide and expand into experiences and experiments of many teams and practitioners.
There are also recommendations on how to run a retrospective in more complex/scaled organizational settings, with multiple teams sprinting together (e.g. Overall Retrospective in Large Scale Scrum), as they work on the same product or service and support the same Product Owner and/or customer journey.
Depending on team(s) maturity, a retrospective could be run with or without assistance of an experienced facilitator (Scrum Master, coach) that possesses guide-level expertise in Scrum.
[Notably, a retrospective format is not unique to Scrum.  For example, Kanban teams can also retrospect, on-demand, whenever they feel there is a need.]

What about other organizational settings, outside of team dynamics? What about situations, when multiple individuals, from different organizational areas need to come together and retro-actively inspect (a.k.a. retrospect) on their work within and across various organizational areas, or across multiple organizations (e.g. internal departments, between partners-companies, vendors), involving communication, collaboration, reporting, managing each other’s expectations? 

Below, are some practical tips on how to organize and run a ‘big retrospective’ (e.g. after multiple sprints and/or completing key deliverable, with people that are not members of development teams).

  1. Most importantly, try having all required parties in the same physical location.  For people that are at remote locations, use video conference rooms, and to the extent possible, cluster people together. For example, if a group is distributed between location A and location B, and there is no way to bring everyone together at either location, don’t settle for letting ‘everyone joining from their desks’, via video phones.  At least, maximize clustering of individuals, at each respective location, by using conference rooms.
  2. For large groups (more than 20 people), try identifying individuals-delegates that represent views and opinions of others.  This is done to reduce noise (too many communication nodes and channels) from people involved in discussions.  Identifying delegates will also help with the first guideline above: collocating fewer people in the same place is more cost-effective.  Be careful, when selecting delegates:line managers, engagement managers, leads etc. – are not the best delegates.  Ideally, delegates should be on-par with people they represent.
  3. Consider bringing an external facilitator – someone who does not represent views or interests of any specific group of people or department.  A facilitator must be neutral and unbiased – a completely impartial person.  If a facilitator understands internal organizational dynamics – this is great but not mandatory.  An experienced facilitator will be able to adjust on-the-fly and leverage to his/her advantage, domain knowledge and subject matter expertise of other participants that are involved in a retrospective. Sometimes, one of the organizational units involved in a retrospective may have their own experienced facilitator available.  Falsely, such person could be perceived by other retrospective participants as someone who is subjective or biased.  Such preconceived notion may create a problem and must be addressed from start.
  4. With many people involved and/or joining from remote locations, consider doing some preparatory work that will help running a face-to-face retrospective more efficiently.  This could be effectively done by a facilitator, by collecting ahead of time, from all future retrospective participants, their preliminary feedback: wishes, concerns, recommendations.  All collected information can be then reviewed and analyzed, to make it more presentable and actionable at a retrospective: duplicates – removed, relevant items – grouped together.
  5. During a retrospective, a facilitator can present all participants with collected and refined information (4 above), in the form of index-cards and leverage one of facilitation techniques (e.g. dot-voting or priority vs. impact plotting) to decide on the order of items to be discussed. Additional, blank index cards should be available on-hand, in case there are last-moment ideas that emerge in a room.
  6. Each discussion point should be time-boxed.  However, since not all discussion points are of equal priority and complexity, time required to spend on each may not be the same.  It is also important to keep a discussion focused/tailored and not let it digress to tangentially relevant (or completely irrelevant) topic.  It is a good practice to spend some extra time at the beginning of a retrospective to not only prioritize discussion points but also estimate, roughly, how much time is each discussion point may take.  This approach of balancing discussion items’ priority vs. complexity, essentially, is identical to what a team does to backlog items during a product backlog refinement session.
  7. Retrospectives that involve people that don’t work on the same team, let alone, individuals from different organizational structures and of different levels of seniority may create a lot of additional tension in a room.  The latter, especially, may force more junior people become very reserved and un-confident in stating their opinions, in front of more senior colleagues (some of whom may also be their line managers).  Allowing privates speak before generals (a.k.a. “military democracy”)” could be one of the ways to ensure that junior people are not anchored to views of more senior people and feel comfortable and safe to speak out openly.
  8. Similar to a single team retrospective, a big retrospective, should culminate on a positive note (friendly, mutually supportive vibe) with at least, a handful of most critical items, becoming immediate actionable.  Since topics that are bought up at big retrospectives are usually more systemic/organizational in nature (as opposed to tactical, team-level), each actionable should be preferably owned by a more senior person.

 

 

 

BABA Meetup – Does Agile Really Work in Sales?

Business Agility is at the top of conversation in the workplace. The Big Apple Business Agility (BABA) MeetUp launched on Monday, March 11, with an interactive presentation, “Does Agile Really Work in Sales?”, by Marina Alex, Business Agility Transformation Coach.
Marina related several of her experiences applying agile to sales, from banks, to an Agile Museum to a chain of dental clinics, Marina shared data that proved improvements in sales were recorded rapidly. In one case 50% in two months, 12 months later 127%. Of course, a shift in culture was at the heart of the process and the biggest challenge, but outstanding results led teams to want to work this way.  A copy of the presentation can be downloaded here.
For the first time, publicly, SWAY Framework guide has been released.  To download a copy please click here.
Some of the steps to success were adopting a backlog that was also qualitative and becoming collaborative through stand-ups, retrospectives and cross-functional teams. One significant hurdle that needed to be overcome was identifying leaders who would take ownership. Marina has adopted an Agile Framework – SWAY, that she shared with the group. One of the highlights of the evening was engaging the participants with the content with the Nureva Wall + Span Workspace. The interactive Wall and collaborative software enabled them to make predictions and add their thoughts to the conversation.
SWAY Framework Guide

[Download Meetup Presentation]

Session Feedback

 

SWAY – Agile Sales Framework 1.0

Meetup-recap.  TBA.

 

Sept 13 -14 | 3rd Global LeSS Conference | NYC


Unforgettable 2 days at the 3rd Global LeSS Conference, at Angel Orensanz Foundation – the historical landmark in NYC.


Conference Space and Our People
Experience Report by Guest-Blogger Ram Srinivasan

Though I have been associated with the Large Scale scrum (LeSS) community for about five years (though the “community” did not exist,  I can think of my association with like minded folks) this is my first LeSS conference. While I used to attend a lot of conferences in the past, I have started focusing more on deep learning (by attending focused workshops) than focusing on conferences. But this year, I had to make an exception for the LeSS conference Why (a) it was the first LeSS conference in North America  (b) It was not very far and (c) I was thinking that I might meet some of the smartest people in the LeSS community whom I may not meet otherwise and (d) I have heard that it is a “team based” conference (unlike other conferences where you are on your own) and I wanted to find out what the heck it was. I was not disappointed.

The venue itself was very different from the conventional Agile conferences  – not a hotel. That definitely caught my attention !! I was pleasantly suprirsed to see both Howard Sublet (the new Chief Product Owner from Scrum Alliance) and Eric Engelmann  (the Chairman of the Board of Director of Scrum Alliance ).  Howard and I had good discussions on LeSS, Scrum Alliance, the marketplace, and scaling
Some sessions that I attended and major takeaways:
  • Day 1 morning keynote –  Nokia LTE  implementation  – Takeaway – Yes, you can do Scrum with more than 5000 engineers
  • Day 2 keynote  by Craig Larman. I always find Craig’s thinking fascinating and learnt quite a few interesting facts about cognitive biases (and strategies to overcome them).
  • LeSS Games – component team and feature team simulation lead by Pierluigi Pugliese – very interesting simulation – I used a variation of this in my CSM class past weekend and people liked it. I hope to write about sometime, in the coming days
  • LeSS roles exercise by Michael James –  I have always been a fan of MJ. Very interesting exercise which reinforces the concept of LeSS roles
  • TDD in a flip chart – Guess I was there again, with MJ. Well, just learned that you do not need a computer to learn about TDD.
  • An open space session with Howard Sublett on LeSS and Scrum Alliance partnership (yours truly was the scribe) – Lot of interesting discussions on market, strategy, and positioning of the LeSS brand.  I personally got some insights from Rafael Sabbagh and Viktor Grgic.
Two days was short !! Time flew away.  It was a great experience !! And  I wish we could have a North American LeSS conference every year !!

Experience Report by Guest-Blogger Mark Uijen de Kleijn

I’ve attended the 2018 LeSS Conference- my first – in the Angela Orensanz Center in New York. I was really inspired by the many great speakers, experiments and experiences and was glad I could help Jurgen de Smet by his workshop on Management 3.0 practices that can complement LeSS with experiments.

A couple of notes on the Conference; it has been the first Conference I attended in years where I actually learned a lot, either from the many speakers, experiments and experiences, but from my ‘team’ as well. As the LeSS Conference is a team-based conference, we reflected on the content and our insights during the Conference, which accelerated my learnings.

As I use many games and practices in organizations or courses, I’ve seen several great new games that I can use myself. The ‘building agile structures’ game of Tomasz Wykowski and Justyna Wykowska was the most outstanding game for me, because it makes the differences between component and feature teams very clear when scaling work, and I will use this for sure in the future. The experiences at Nokia by Tero Peltola were very inspiring and especially the focus on the competences (of everybody) and technical excellence I will take with me.Thoughts that will stick with me the most after the conference: the focus on technical excellence (including e.g. automation, code quality, engineering practices etc.) and the importance of the structure of the organization, following Larman’s fifth law ‘Culture follows structure’. The latter I’m already familiar with, but needs to be reprioritized in my mind again. The former will be my main learning goal the coming period and I will need to dust off my former experiences.

Interesting quote to think about, by Bas Vodde: ‘we should maximize dependencies between teams’ (to increase collaboration between teams).


Games and Team Activities

LeSS Graphic Art


My partner in crime (Ari Tikka) and me  – Presenting on Coaching

Click here to download presentation: Ari’s deck | Gene’s deck.


Personal Memorable Moments


Next LeSS conference (2019) – Munich, Germany

Centralized vs. Decentralized Coaching

Key Takeaways

Read the original post on InfoQ.

  •  There is a frequently seen confusion with respect to the definition of agile coaching: coaching focus (e.g. enterprise vs. team) is confused with coaching alignment (centralized vs. decentralized) within an organization
  • Centralized coaching departments run the risk of turning into a single-specialty organizational silos that are locally optimized for their own expansion and personal success; they are also removed from real action. The reasoning behind: standardization – has its weaknesses.
  • Centralized coaching is often limited to being “responsible for introducing KPIs, documentation of script-style-one-size-fits-all best practices and cookie-cutting approaches”.  This leads to system gaming by other departments and organizational silos that must “meet numbers goals”
  • Centralized Agile coaching makes sense only when it takes place within an organization that is small enough to be effectively managed front-to-back (including its all organizational layers)  and is genuinely supportive of its own coaches, by providing them with “organizational immunity” and operational safety – to enable them perform their challenging duties
  • The main advantage of decentralized coaching approach is that coaches are close to real action: deeply engaged with products/services, and are intimately engaged with senior leadership.  Decentralized coaching is deep & narrow (as opposed to being broad and shallow) and takes time to cause meaningful and sustainable organizational changes.

Read the original post on InfoQ.

Proper Scaling of Scrum and Dynamic Financial Forecasting


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

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

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


Rigid Annual Budgets vs. Dynamic/Rolling-Wave Forecasting

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

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

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

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

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

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

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

 

Proper Scaling vs. “Copy-Paste” Scaling

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

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

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

Based on the above, the following also becomes apparent:

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

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

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

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

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


Conclusion:

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

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


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

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

Course Highlights

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

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

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

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

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

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


Here are some Kodak moments from the event:

Addressing Problems, Caused by AMMS


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

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

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

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

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

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

Note: Translation of the text in red: “(Пере)выполним годовой план за три квартала!!!” = “Will meet/exceed the annual plan in three quarters!!!”

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

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

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

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

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

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


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

Malik’s Summary

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

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

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

Presentation deck is available at  Natoma Consulting website for download.