Unforgettable 2 days at the 3rd Global LeSS Conference, at Angel Orensanz Foundation – the historical landmark in NYC.
Experience Report of Guest-Blogger Ram Srinivasan
Experience Report of Guest-Blogger Mark Uijen de Kleijn
LeSS Graphic Art
Personal Memorable Moments
Next LeSS conference (2019) – Munich, Germany
- Wrote Extreme Programming Installed (also with Ann Anderson)
In 2009, developed for Scrum Alliance the Certified Scrum Developer program
- Taught the first Certified Scrum Developer (CSD) course
- Have been curating the Scrum Alliance’s Agile Atlas website
- Created the SA’s official Scrum description, Core Scrum
- Speak at conferences, bringing an interesting mix of humor and deep knowledge, and the odd cat picture.
This is what Chet had to say about the course:
“Chet Went to Craig’s LeSS Course”
Many years ago, I wrote an article entitled “Inside every 100-person project is a 10-person project trying to get out.” That pretty much sums up my feelings about Agile at scale.
Craig’s organizing principle for the course is that in order to successfully use these ideas, you must own them. Having an instructor, no matter how good they are, no matter the depth of their experience, teach you something is no where as good as discovering the answers yourself. To this end, we spent most the the course learning and practicing organizational modeling to derive the practices and structures that align with our goals.
Some more Kodak moments from the event are below:
- 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.
2018 Business Agility Conference @ NYC is in the books. More than 300 people attended – they came from all over the world: to listen to selected speakers, on great topics. Evan Leybourn (the main organizer) also announced the birth of Business Agility Institute.
On impulse, and with a lot of excitement, NYC-based meet-up was created: Big Apple Business Agility (BABA)
Special thanks to Stuart Young (on right, below) from the UK – the legendary professional Business Visualiser who has perpetuated many agile events with his amazing graphic art:
Speakers’ Quotes & Main Take-Away Points
Below are some highlights of the most memorable quotes, from selected presenters. (Note: some notes are captured verbatim, others are transcribed from presenters’ slides, yet others – closely paraphrased. What is underlined – really resonated especially strong. Please forgive any potential omissions and if you find any, please request correction)
>>> Nancy Taylor of IBM
- “Beware of people that say: I am a coach but i really never coached anyone.”
- [There are too many ]”box-checking” agile transformation by companies, out there”
>>> Jonathan Smart of Barclays
- “Business agility is the future”
- “Descale work, descale org, DONT scale”
- “Substitute agile for nimble (without capital A)” [too see is meaning remains the same]
- Change your language from “hi, I am John i will enforce agile on you” to “hi i am John, i will deliver better products for you“.
- [Chasing] “increased productivity leads to churning and faking. Instead, focus on better value and safer environment”
- “You need enterprise agility, not just [agility for] IT”
- “The better your brakes, the faster you can go”
- [Move from] “task-based definition of success” to “outcome definition of success”
- [You should be ] “moving from hard/fixed budgets to rolling scorecards”
Irony in some of his Jonathan’s slides:
- “Our people are not suited for self-organizing, we’ve got the wrong ones…”
- “We want best of both worlds”
- “Easy job. Just fire the managers and tell the teams the are in charge now”
- “It can be done without restructuring the back office.”
“It won’t work, it is just a hype.”
>>>Andy Cepio of Target
- “Don’t crush the chips”: the smallest and most impact-ful innovation NOT to crush fragile chips at the bottom of a box was to make two holes on both sides of a box, as hand grips
>>>Steve Deming of Learning Consortium
- [There is] “lots of agile faking. In Learning Consortium companies have safely, and this is where they can share their experiences.”
Jimmy Allen of Bain & Company
- “The purpose of good organizational design is to create conflicts”
- “When you get to a certain organizational size, any initiative takes about 18 months…to fail“
- “Micro teams MUST report directly into senior Leadership, periodically. Otherwise, mid-level management will kill agility, as they hate agile teams”
- “Jumping to playbooks is silly.”
- “[You have to] create a vocabulary that describes misery [of your people],so you can speak about it
- “The biggest problem of failed agile efforts is distance b/w sr. leadership and doers”
- “Modern organizations must flatten”
- “Only 1 in 11 companies grow sustain-ably – and yet in only 15% of cases do those that fail to grow blame the market”
“Scaling as a capability: 10 lessons from the Masters”
- Recognize that scaling will be critical to your success, demand that your leaders remain in balance
- Winning repeatable models demand an iterative process; don’t declare victory after a good prototype
- Don’t jump to playbooks; there are different scaling models depending on the degree of tailoring needed
- The best scaling models consider the “unit of scaling” to identify resource bottlenecks early
- Address bottlenecks and “Everyone wants Brent” problem from Day 1
- Don’t underestimate behavioral change required especially across functional hierarchies
- Understand the role of the three communities; especially the Scaling Community which acts as a bridge
- Scaling well demands dynamic resource allocation; shift resources fast behind a “winner”
- Eventually scaling will demand changes to your operating model
- Use Engine 2 to build specific capabilities
Jutta Eckstein and John Buck of The Cociocracy Group
- “Every company is a software development company but some dont know it yet
- “There is no such thing as “Spotify model”. If you take their model, inspect and adapt, then maybe it is OK….So they say.”
- “Always use lower case A in “agile” (substitute for ‘nimble’, whenever your can)
- “Fixed budgets will kill organizational agility (refer to Beyond Budgetting)”
Laurence Jourdain of BNP Paribas Fortis
-[You should] “keep a small group of internal coaches but hire many professional coaches from” [reputable places]
Joshua Seckel of Sevatec
- “I don’t have a power point today. –> I may not have any power but I do have a point to make.”
Sudhir Nelvagal of General Electric
- [The company] “is transforming and it is over 125 years old into a lean start up”
- [You have to make] “huge focus on Senior Leadership coaching”
- Using burn-down charts with Senior Management has pluses and minuses. (E.g. velocity policing [is a big minus])
Susan Courtney of Blue Cross Blue Shield
- Problem statement: “Leadership did not know how to reward talent”
- [Had to] bring in Leadership Development coach
- “Culture change is not negotiable”
- Lessons Learned:
- “Build critical mass around the journey – find like minded people”
- “Right people – in the right roles (nice does not = good fit)”
- “Identify and remove toxic people, especially leaders”
- “Value culture fit as much as functional skills”
- “Clarity & co-creation of road-maps”
- “Do this WITH OR in-spite of HR”
- “CULTURE-CULTURE-CULTURE…if you say it’s who you are, you have to mean it (actions not just words)”
David Horowitz & Matias Nino of REI Systems
- “We should stop thinking that ‘everything that what happens in retros stays in retros. We should produce a lot of retrospective radiators.”
Melissa Boggs of Agile42
- “Your have to change organizational culture as a barrier to agile success”
- “It makes sense to focus on principles not on practices”
Jason Tice of World Wide Technology
“If you want to be able to speak to HR, you have to learn how to speak their language”
Amanda Bellwood of Sky Betting and Gaming
- “Embed HR people onto teams”
- “Have HR run their own daily stand-ups and have them come and see what other teams are doing at their stand-ups”
Some personal Kodak moments at the conference:
- 1st row (Left to Right): w/ Steve Denning, w/Mike Beedle
- 2nd row (Left to Right): w/Zuzi Sochova, w/Jeff Suit Lopez-Stuit
This page is being gradually developed towards May, 2018 Big Apple Scrum Day Coaching Clinic.
For similar past events please visit:
Below are some basic guidelines for participating coaches on how to run a coaching clinic during Big Apple Scrum Day. Experience and working models of previous clinics (Scrum Alliance, Agile Alliance) have being used. If you have other recommendations or additional ideas, please suggest 🙂 .
General Coaching Guidelines:
- Wear a coaching hat – we shall try to get some from Scrum Alliance folks (their ‘station’ should near the clinic)
- Walk-ins are OK if we have capacity
- Each session is limited to 15 min, unless there is no line – then you can attend to another person
- Appointments get priority over walk-ins
- It is OK to offer a business card for future consultation but Do NOT sell services or proactively solicit business, while coaching
- Paired coaching is OK if we have capacity (one coach works, another observes; then– debrief).
- Always, start off with understanding what brought a person to the clinic (e.g. “What brought you here?” or “How I can help?”)
- We can briefly retrospect at the end of the day or, if not possible, later via email
Participating Coaches (BOARD view):
This is us – the clinicians:
|Coach’s Name||Home base|
|Gene Gendel||New York, USA|
|Jeff Patton||Salt Lake City, UT|
|David Liebman||New York, USA|
|Jim York||Leesburg, VA|
|Alexandr Kizhner||New York, USA|
|Amitai Schleier||New York, USA|
|Mariya Breytner||New York, USA|
|Ross Hughes||Burlington, Vermont|
|Diane Zajac||Erie, Pennsylvania|
Coaches’ Availability (BOARD view):
In the morning, we shall put up a board in our working area. On this board, each coach will put his name (on a sticky), in a time slot when he/she is willing/able to offer service. Example below:
|Time Slot||Available Coach|
|8:00 – 8:30|
|8:30 – 9:00|
|9:00 – 9:30|
|9:30 – 10:00|
|10:00 – 10:30|
|10:30 – 11:00|
|11:00 – 11:30|
|11:30 – 12:00|
|12:00 – 12:30|
|12:30 – 1:00|
|1:00 – 1:30|
|1:30 – 2:00|
|2:00 – 2:30|
|2:30 – 3:00|
|3:00 – 3:30|
|3:30 – 4:00|
|4:00 – 4:30|
|4:30 – 5:00|
Note: Time slots should correlate to the Event’s Main Schedule
Appointment Schedule (BOARD view):
On this board, each attendee will put his/her name/discussion topic (on a sticky), into a time slot when they are planning to attend the clinic. Attendees may request multiple time slots, within reasonable limits. Each request = one sticky note. Example:
15-min Time Slot During
Attendee Name/Discussion Topic
|Morning Session Part 1|
|Morning Session Part 2|
|Afternoon Session Part 1|
|Afternoon Session Part 2|
Note: Time slots should correlate to the Event’s Main Schedule
BOARD: Coachee’s Response:
On this board, every clinic attendee will be asked to write a brief feedback on a sticky note (example from Orlando). They may or may not provide the name of a coach that offered assistance – it is up to them. We, the coaches, don’t have to watch them doing this. Once we are done with a coaching session, they can self-manage.
BOARD: Appointment Counter
On this board, we shall be collecting all sticky notes that were served. Attendees will be asked to post them there, after they attended the clinic.
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:
- Moving from rigid annual budgets to rolling forecasts (super important! in agile/adaptive product development environments)
- 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:
- Budgets represent a retrospective look at past situation and conditions that may not be applicable in a future
- Assumptions made as a part of a budgeting process, even if somewhere accurate at the beginning, get quickly outdated
- Budgeting, in general, is very time-consuming process, and it adds additional, financial overhead to organizations
- Rigid budgets, can prevent important, value adding-activities, and often lead to fear of experimenting, researching and innovating (crucial for incremental development)
- 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)
- 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)|
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.
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).
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.
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: