Category Archives: Newsletter-Communication

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.

2018 BUSINESS AGILITY CONFERENCE – NYC

Summary

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 Shout-Out

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”

  1. Recognize that scaling will be critical to your success, demand that your leaders remain in balance
  2. Winning repeatable models demand an iterative process; don’t declare victory after a good prototype
  3. Don’t jump to playbooks; there are different scaling models depending on the degree of tailoring needed
  4. The best scaling models consider the “unit of scaling” to identify resource bottlenecks early
  5. Address bottlenecks and “Everyone wants Brent” problem from Day 1
  6. Don’t underestimate behavioral change required especially across functional hierarchies
  7. Understand the role of the three communities; especially the Scaling Community which acts as a bridge
  8. Scaling well demands dynamic resource allocation; shift resources fast behind a “winner”
  9. Eventually scaling will demand changes to your operating model
  10. 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

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).

How Detailed Should Business Requirements Be? Discovery Through Agile Gaming.


Last week, at New York Scrum User Group (NYSUG) monthly event, co-facilitated by  the agile coaches Dana Pylayeva and Emilie Franchomme, there were multiple agile games presented – all for different purposes and for all types of audience.  Above all, what really stood out was  the “Beautiful Meadow” game that helped with making a revealing discovery about handling business requirements.  Below is the summary:

Game Rules:

Team A and Team B, of 8 people each,  were given the following drawing instructions (click on the image below to enlarge):

Team A Team B

The requirements of Team A were very detailed, whereas the requirements of Team B were rather generic.   Each team was given a set of color markers and a  large flip-chart sheet.  Both teams were allowed to review the requirements in silence – for 30 seconds.  Then both teams were given another 60 seconds to draw a picture, based on given requirements, but they were allowed to collaborate in sign language only.

Observations and Results:

For the first 30 seconds of the exercise both teams’ dynamics were very similar: hurdling around the requirement, trying to understand it, orienting yourselves are around the canvas.   Silently,  some people seemed to volunteer to draw various elements of the picture.  For the second 60 seconds interval, dynamics significantly changed:

At a glace, Team A seemed to be somewhere less organized and more hectic.  People seemed to move around the canvas anxiously, trying to pull markers from each other’s hand.  What also became obvious was that each person was trying maximize their contribution to the picture, by drawing in a silo, without much collaboration with others.

Team B, on the other hand, seemed to be much more organized and focused.  Individual work of each person seemed like a continuity of someone else’s effort.  Markers were effectively passed on from one person to another.  There was much more collaboration and common effort here.

After 60 seconds of drawing, the teams produced two images, illustrated below: Team A  – left canvas, Team B -right canvas (click on the image below to enlarge):

Team A has produced a picture that consisted of multiple disjointed elements that together did not seem to fit well.   Oddly it even produced two suns – in two opposite corners of the canvas, whereas the instructions  clearly asked only for one sun.

On contrary, Team B was able to produce a simple, coherent logical picture, with each element enriching the overall composition with  additional relevant detail.

Conclusion:

This exercise clearly demonstrated that too detailed requirements, passed on to a group of individuals, as one conclusive document, are executed much poorer than light requirements  passed on to a similar group of people.  In case of Team B, there was a request of “WHAT” to draw, not “HOW”.  The team was able to use all of this innovation and artistic skills to produce what was required.   Oppositely, team A was asked to delivery “WHAT & HOW” and the teams’ ability improvise on-the-fly was significantly reduced.

Disclaimer:

There were two sets of teams (two Team A and two Team B) and the results produced by the second set of teams were very similar to the case described above.

Relevant Article: Waterfall Requirements in Agile Product Development

Agile Organization, as a Sushi Roll


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

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

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


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

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

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

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

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

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

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

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


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

Listen to the Webinar: https://vimeo.com/259108134

LeSS “Construction”: What is it like?


[also, cross-posted on less. works]

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

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

Imagine two buildings: Building A and Building B.

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

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

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

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

This is what building A looks like:


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

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

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

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

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

This is what building B looks like:

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


In LeSS:

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

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

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

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

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

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

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

Signed: ____________The Organizational Building Management 😉

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

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

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

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

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

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

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

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

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

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

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

Our game’s purpose was:

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

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

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

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

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

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

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

2017 Agile Maine Day Recap

The 2017 Agile Maine Day event is in the books.  Great event organization. Great energizing crowd. Amazing presenters and speakers.

Below are the summaries of two selected presentations, whose themes were mostly relevant to System Thinking and System Design:

Don Macintyre’s topic “Agile Leadership” was about Radical Management (Steve Denning’s teaching) and covered:

  • Shifting focus from making money for shareholders to focus on delighting customers through continuous innovation
  • Managers focusing on controlling individuals to Managers empowering and supporting self-organizing teams
  • Shifting from controlling work with bureaucracy to guiding innovation with priorities
  • Shifting from predominantly valuing efficiency to valuing Continuous Innovation
  • Shifting from top-down command structures to horizontal communication and collaboration

Don also talked about Agile Leadership Mindset and stressed the importance of the following behavioral transitions:

  • From Directing to Coaching
  • From Hiding Failure to Learning from Failure
  • From Telling to Collaborating
  • From Avoiding Blame to Seeing Feedback

Bob Sarni’s – “Radical Collaboration” delivered the following main message: “Organizations cannot compete externally until they can collaborate internally

Bob referenced the book “Corporate Culture and Performance” by John Kotter and James Heskett: Non-enhancing Cultures vs. Enhancing Cultures, alluding to the fact that sometimes the best way to overcome resistance, is to remove resistors.

The following four quadrants of self-discovery were covered:

  • Who we are (Self-mastery):
    • Self-Awareness
    • Self-Esteem
    • Emotional Intelligence
    • Values
  • Interpersonal (Social Intelligence):
    • Communication
    • Trustworthiness
    • Cooperation
    • Rules of Engagement
  • What we Do:
    • Project
    • Product
    • Task
    • Service
  • How We Do it:
    • Systems/Processes
    • Decision Making
    • Structure
    • Policies

Bob also stressed the point that when it comes to going through organizational changes, companies tend to focus on Practices, instead of focusing on underlining Principles and Values. This results in unsustainable, short-term successes only.
Another great quote from Bob’s session: “Business Analysis have their focus on the outer side of business”, mainly focusing on questions of ‘what should we be doing?‘ and ‘how can we do it better, faster and more efficiently’.  It turns out that the inner side of the business is where the greatest opportunity for radical improvement resides”.  The inner side of the business contains the heart and soul of the business.

Finally, Bob talked about Red Zone vs. Green Zone Behaviors (refernicing work of James Tamm)


Bob also described Pink Zone behavior that usually manifests itself by the following actions: Leave, Quit, Hide, Passively Resist, Appease, Give in

(At closing, a kodak moment with Dan Mezick and Bob Sarni)

 

Agile Flyer – 04-09-2017

 



 

Public Announcement:
Scrum Alliance® Announces Partnership with LeSS Company

 

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

-Read the entire press release…

Join your local LeSS communities today.
(LeSS NYC)

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

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

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

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

-Read more…

 


More Selected Periodicals:
Unspoken Agile Topics

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

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

-Read more…

Be an Educated Consumer

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

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

-Read more…

Fresh Collection of Ad-hoc Agile References:

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



From www.ScrumAlliance.org

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