Additional recommended assets:
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)
Additional recommended assets:
Lyrics written by: Gene Gendel | Musical/voice performance by: Erin Perry
-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.
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:
Additional assets recommended:
Upcoming Training (group discount: group_disc):
Additional assets recommended:
Upcoming Training (group discount: group_disc):
Synopsis:
Additional assets recommended:
Upcoming Training (group discount: group_disc):
Synopsis:
And most of the below:
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:
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.
