Category Archives: CLP

LeSS Trainer’s Class Experience Report: Product Definition, DoD & Team ‘Blueprint’ Exercise


This summary, is an experience report from the recently conducted online LeSS class (provisional CLP).  Specifically, this writing is about a few discussion topics, accompanied by in-class exercises and homework activities: product definition, definition of done (DoD) and teams (blueprint).

In class, we were lucky to have a few people that were already highly experienced with Scrum and knew fundamentals of LeSS. A few people were also from the same XYZ company (name withheld for privacy) that specializes in global ERP solutions for manufacturers. Among XYZ company people, there was a senior vice president of R&D and a few other senior-ranked technology professionals.  With everyone’s consent and for everyone’s benefit, we were able to discuss the above topics in the context of XYZ case.

It was also made clear to everyone that this exercise is merely a simulation of a much more comprehensive discovery process that takes place during the initial phase of LeSS adoption, with many more people involved, not just a few.

We started, by trying to understand the company’s big picture: vision, revenue steams, cost factors, product partnership (internal business, external customers, R&D), value, competition, innovation.  For that, we used the great facilitation tool, created by E. Gottesdiener – The Product Canvas.

After the first round of exploration (v1.0 below), it became apparent that the product definition was too wide (big), and it would be impossible to support its development by a single LeSS product group (2-8 teams).

Of course, this assumption was not conclusive but for the purpose of this in-class exercise, it was decided to reduce the product definition, by focusing only on one particular area – Sales (v2.0 below).  This was consistent with what is recommended in LeSS: to expand product definition as reasonably possible, but not make it too wide to manage.

In the second phase of product definition, the class focused on identifying user types and actions, as well as various product components: interfaces, data, controls, environments, etc. This further helped validating the assumption, made in the first step of product definition.

Following the product canvas use, to identify the most important (and big) product features, the class proceeded with a story mapping exercise. The following five large features have been identified: New Sales Order Interface, Shipping Dashboard, New Quote Interface, Data Layer. They were then further decomposed into smaller features that were prioritized, on a time scale.  The class had a quick conversation about what a minimal viable feature (MVF) could look like if multiple small features, from various buckets were deployed together (the curvy black line below).  Within a few rounds, many more small features were identified and bucketed under large features (but not prioritized). It was a shared understanding by everyone that all identified items, eventually, should end up in a backlog.

Next, the class tried to envision what Dominion of Done (DoD) could look like for a team that was tasked to deliver any of the above mentioned features. The attempt was made to identify those activities that would be still Undone (impossible to finish in a sprint) at the initial stage of sprinting and how important it would be to gradually expand DoD and shrink Undone, over time. The class further discussed differences between Unfinished work (usually, a team’s problem) and Undone work (usually, organizational problem).

Based on all of the information collected, the class tried to envision what technical skill set and functional domain expertise would be required, for each team, to ensure that each team could take any item from a backlog and get it to Done in one sprint.

Finally, the class (this part was mainly driven by people from XYZ company) tried to hypothesize what a team structure could look like (team ‘blueprint’), given that some developers had one and some – more than one, skill set and domain expertise. Everyone understood that this is just a hypo and the intention is not to assign people to teams prematurily, since managers, leads or anyone else should NOT be making decisions on behalf of on teams. The idea of self-organizing team-building workshop was introduced and discussed (a few published LeSS case studies were reviewed to better understand this event).

 

During the break, one of the class members (XYZ company) tried to blueprint what LeSS Product Group may look like if v1.0 model (illustrated above) was followed to describe the whole product.  It appeared that each Requirement Area, would have only between 2 and 3 teams. It was then discussed that this approach would  NOT be recommended, as very small requirement areas (with very few teams in each area area) would lead to organizational silos, compartmentalizing of work, scattered knowledge and local optimization.
The class further discussed R&D organizational design implications of XYZ company. Many HR aspects were highlighted, such as a developer’s career path, promotions, compensation/incentives, etc. Various HR-related LeSS experiments were  explained.

At this point, the class ended the simulation exercise, with understanding that in real life this process could take from a few weeks, to a few months. It was understood by everyone that before an organization makes a ‘flip’ to LeSS, some additional, very important milestones would have to be achieved:

Team Self-Formation Workshop:

Product Backlog Creation (Initial PBR session):
Preferably, a creation of an organizational impediment backlog – something, to be continuously attend to during Overall Retrospectives, where senior management, would take ownership of problems.

HR-Related LeSS experiments

 

XYZ Company people have demonstrated a lot of determination to implement many aspects of LeSS learning and discoveries ASAP, in real work settings, within their organization.

10/13– LESS TALKS: System Modelling of HR-Related “Nuances”

 

 

Upcoming LeSS Training 

Additional recommended assets:

10/06– LESS TALKS: Growing teaminess – Canvas for self-managing teams

Materials

Say hello to Dhaval Panchal.

Teaminess” is not a dictionary word. Perhaps it should be. Teaminess refers to a feeling of being one in effort, behavior, and communication towards achieving shared purposes. Team growth is a dynamic process that folds and unfolds on interaction with its environment. A team is influenced by and in return also influences its organization. This dynamic is continuous, and the alternative to team growth is stagnation or worse attrition. For teams that are just starting or for seasoned groups who have lost their mojo, the Team Self-Managing Canvas is a practical guide that supports positive engagement with managers unlike working agreements alone which are internally facing, teaminess requires active management of forces outside of team’s control.

Dhaval’s newsletter (please sign up)


Upcoming LeSS Training 

Additional recommended assets:

Agile Poetry In Motion

Lyrics written by: Gene GendelMusical/voice performance by: Erin Perry

LinkedIn feed

-1-

It is time to get serious about agility:
It is best to be viewed as PMO utility.
Scrum and Kanban are agile “methodologies”,
Agile Manifesto – is purists’ ideology.

-2-

Agile KPIs, metrics and RAGs,
PMs – proudly wearing “Agile Coach” name tags.
BAs – are pretending to be “Product Owners”,
Tech Leads – are deciding on a year-end bonus.

-3-

Agile’s the way to advance for promotion!
Don’t miss opportunities: strive with devotion!
Scrum Master – is merely a junior role,
An Enterprise Coach’s your ultimate goal!

-4-

Chief Architects – want a piece of this action,
Lets clearly define their main interaction:
“Dont waste their time, by expecting to code,
Power point creation – is their main working load”.

-5-

“Fixed everything” plans and forecasts to stakeholders,
Lets put all Scrum work in portfolio folders.
Make sure: estimations are very precise,
Our organization can handle all lies.

-6-

BAs – “PO Proxies” – Team Output Owners,
Borrowed resources – capacity donors.
Scrum, Scrum of Scrums and Scrum’s fractal design,
Oh God!, someone get me a bottle of wine!

-7-

Our Enterprise Scaling’s  – a serious matter!
Big, scaling solutions will make things just better.
Lets pay extra fees for every new version,
And be in denial of this brutal extortion!

-8-

Projects and programs. Trains, Streams, Epic Owners,
Shared workers, Brook’s Law and  developers-loaners.
Vertical structures get flipped on their side,
They’re now called Chapters – lets go for a ride!!!

-9-

Those Chapters too big??? – No worries, at all!
With Chapters of Chapters – we’ll all get a role!
But what if that thing got tremendously big?
No worries at all – will add Guild in a gig!

-10-

Portfolio Managers paid a big bribe –
To be guaranteed a sweet spot in a Tribe.
Of course, Tribal Lead is their main aspiration,
They’re now in charge of org. structure creation.

-11-

For staffing, rely on “sweat shops” and recruiters,
They are most ferocious industry looters.
They’ll find and “deliver” the cheapest resources,
While “riding” developers, like smelly horses.

-12-

Don’t do this alone: lets invite “expertise”!,
Expensive consultancies run this striptease!
They lead us through “theater” and masquerade,
And work extra hard for the millions they’ve made.

-13-

If you recognize what’s described in these rhymes,
If you get annoyed with these problems (sometimes),
Don’t remain silent and voice your frustration –
Earn tons of respect and your peers’ admiration.

For graphic irony and satire please visit this page.

JULY 22-24: CERTIFIED LESS BASICS (CLB) COURSES | VIRTUAL

 

Relevant Assets:
Upcoming Virtual LeSS Training:

07/20 – LESS TALKS: Business Agility Aspect of LeSS Adoption: Outcome-Based Backlogs Drive Business

 

by Jurgen De Smet

Synopsis:

“Many organisations are so focused on delivering features that they tend to forget the outcome or business impact one wants to accomplish. The acronym MVP is frequently used in a context of a fully working application or minimal set of features where one forgets to truly validate assumptions. PO’s are writing detailed user stories but not always following up on the business impact of it all. At the same time you see business leaders in the organizations disconnect from the delivery process.

Let’s see how we can do things differently!

A cocktail of different models that put business outcomes at the center. A different way to look at so-called product backlogs, stepping away from a flat list of items. This cocktail is one of many LeSS experiments you could try and some things to avoid.”

Co-Learning Academy by Jurgen De Smet:  Review & Register

Additional Upcoming LeSS Training (group discount: group_disc):

Additional assets recommended:

July 01-03: Certified LeSS Basics (CLB) Courses | Virtual

Class of July 01-03

Relevant Assets:
Next virtual LeSS Training:

07/02 – LESS TALKS: Why Is Independent Teams With Microservices a Bad Idea?

Materials TBA

Additional assets recommended:

Upcoming Training (group discount: group_disc):

06/23 – LESS TALKS: What is “UNDONE” Department And How To Eradicate It?

Materials used

Additional assets recommended:

Upcoming Training (group discount: group_disc):


Synopsis:

What is Undone Department?
“Undone department—This department, ideally, does not exist.
Unfortunately, sometimes the teams are not yet able to create a true shippable increment every Sprint. This is reflected by their “Definition of Done” not being equal to “Potentially Shippable.” The difference between them is called Undone Work. Someone needs to do this Undone Work, and a common “solution” is to create separate groups that pick up the “undone work”—the undone department. More on this in the Definition of Done chapter.
Undone departments such as test, QA, architecture, or business analysis groups should never exist in the smaller LeSS framework groups; rather they should be integrated into the teams from the start. On the other hand, we unfortunately still frequently see an operations or production undone department in LeSS adoptions, as they often cross organizational boundaries.
A goal in every LeSS adoption is to remove the undone department. How long will this take? The answer is highly dependent on how fast the organization improves its capability.” – from the 3rd LeSS book (Large Scale Scrum: More with LeSS)

06/09 – LESS TALKS: Never-ending saga with Estimation. Can LeSS help us debunk this?

 

Materials used

Additional assets recommended:

Upcoming Training (group discount: group_disc):


Synopsis:

For so many companies, inability to estimate -> forecast –> budget –> manage expectations of clients/users/management is a big issue.
This is not surprising.Under assumption that everyone understands
Scrum and has first-hands experience with all of the below:

  • “Our teams cannot accurately estimate work”
  • “Our teams are not stable and not dedicated. Capacity is unpredictable”
  • “Not everyone is cross-functional and everyone does their own work. What is the point of estimating together?”
  • “Our teams get confused with historical Velocity-driven planning vs. Capacity-driven planning. When to use what and why?”
  • “Our teams have hard dependencies on other teams. Some resources are shared. What can we do?”
  • “Our estimation and metrics get so-so fudged, as they roll up through multiple organizational layers to the top”
  • “Our organization is fractal: one PO per one team, each team works in a silo. We cannot “standardize” estimation”

And most of the below:

  • -“Individual teams are more or less OK, with estimation, but how to we ‘normalize’ estimation across multiple teams?”
  • -“How do we ‘scale estimation’, so that our sr. management can get a sense of how much work we have?”
  • -“When is the best time to estimate? How provides estimates?”
  • -“How can we effectively estimate with many developers not be co-located?”
  • -“When and where is knowledge about the estimated work being used?”

Let’s talk about how most of these problems can be addressed in Large Scale Scrum.
Instead of implying that LeSS is a silver bullet or blanket solution to everything, lets focus on specific dynamics of LeSS, with respect to:

  • specifics of LeSS product group design
  • intimate synergy between teams
  • roles & responsibilities, artifacts & events

in order to understand WHY estimation and forecasting by LeSS product group (e.g. 50 developers) would be more reliable than the same, done by e.g. 50 developers of a traditionally-designed organization.