What does the Kanban Guide for Scrum Teams (at https://www.scrum.org/resources/kanban-guide-scrum-teams) say about work in progress limits?
I enjoyed sitting around Fountain Square, the day before Bengals beat Buffalo Bills in American football. I skipped that game as Tropical Storm Nate sent heavy rain our way. Besides, it gave me time to go over my first one-off Ted-style talks – very few words, symbolic pictures, everything in 3s, facts mixed with some stories, being myself, staying in my lane, being relaxed.
Greetings from my trip from London to Cincinnati, where I'll talk about scaling/descaling, growing good sustainable agility and so on. If you're around the Cincinnati area, you'd be crazy to miss the conference. There are some rockstar keynotes. There are some great speakers, Ellen Gottesdiener is likely to steal my thunder as Ellen is on stage at the same time as me in another room. Ellen rocked at the LeSS conference :). There are still a few tickets left for Agile Cincinnati.
"Retrospective: A coach and a framework are just guides. The ownership and accountability for the transformation sits with the leadership of the organization. Do not shift accountability to a consultant, framework, or methodology."
Never a truer set of words, words from the the LeSS Case Study for Antartica Investment Bank .
Aside, consider in the above chart, if a journey is a long standing cross-component cross-functional large group of say 300 people to deliver a services, these journeys tend to get blocked when they still have more component teams to integrate work with. More structure change would be needed in that case, supported by leaders.
I liked the way the prioritization of improvements had leadership focus in the Cash in Comfort LeSS case study. I loved the organizational impediment focus ion the Agfa healthcare LeSS case study. The focus on feature team adoption for the entire system at Thales Surface Radar looks very impressive to me; a case of a LeSS Adoption for multiple products/a product line and leaders as coaches.
I colloborated with colleagues on causal loop diagrams for the current state and the potential future state of a huge organization. The interesting thing is I learnt about causal loop diagrams from the 1st LeSS book . As a result of the exercise, it transpired in our case that f ramework alone didn't look like it would materially move any dials. We needed leaders who were serious about busting organizational impediments and proactively supporting enablers such as structure change for a customer-oriented product/service organization. And the leaders needed to allow teams to use whatever methods & frameworks work for them.
Whether or not it's ok to have a super-structure/framework at a huge scale, I say don't make the mistake of forcing everyone to use that same lowest common denominator framework at every level. Figure out a way to interface to the mother ship framework while keeping autonomy and alignment. Ideally use LeSS at all levels, if you're serious about blowing away silos and exorcising fake agility. But let people own their system, let's not just copy & paste from some other successful company. Products are well handled by LeSS, LeSS Huge, and huge LeSS Huge.
Check out the annual LeSS conference, in London 13-14 Sep to see the LeSS inventors, LeSS trainers and LeSS practitioners in action.
Have more than one product? First of all check that your product is customer oriented, e.g. mortages. If your product is something a customer still doesn't understand you might need to abstract up another level. Consider one of the adoption tools, a Feature Team adoption map. By using Feature Team Adoption Maps, one can extend LeSS Huge beyond the product to the system, as was the case for Thales Surface Radar.
If you really are dealing with multiple products and you're not quite ready for system level feature teams, my personal suggestion is to consider Discovery Kanban and Beyond Budgeting at super-portfolio and portfolio levels; portfolios of products/services as opposed to super-batches of requirements like program portfolios. Discovery Kanban is great for managing options across products and reducing batch sizes. Beyond Budgeting changes the way we finance our work so we avoid project based financing and instead embrace long term stable teams.
Views are personal.
The annual LeSS conference is in London, UK this year. This is so nice for me, as I live in London, and I am in the early days of a LeSS adoption. It will be so cool to hang out with the thought leaders of LeSS. As far as I can tell, there are only 10 certified LeSS trainers in the world and most if not all of them will be at this conference, not to mention the candidate LeSS trainers and people with real-life experience & case-studies of LeSS and LeSS Huge. You can even see and feel a self-designing teams workshop - that will be so cool.
Most people have an idea what value an Agile/agility coach offers. We see loads of debate about mentoring versus coaching and let’s not add to that debate.
In many ways, the journey to Large Scale Scrum is as colossal as the scale of the Golden Gate Bridge.
This post is a supplement to my general post on Nexus and Nexus+. See also Nexus at a European bank. The Nexus format is essentially the same, with additions of Kanban or The Lean Startup in "sprints". The Nexus Integration Team is accountable for
How did I come to this pattern? Well, I had a number of teams per product that wanted a choice of Scrum, Kanban as per the 2016 Essential Kanban Condensed Guide, or the Lean Startup. The teams wanted a pattern. I wasn't aware of a pattern for those methods. So I modified Nexus as above. I added the Architecture Owner role to reduce
I negotiated a design using Nexus+ with some products potentially on LeSS, but most products on Nexus, per product.
The goal for the first 6-12 months of the change was faster delivery (while still focusing on the customer where we had opportunity) all the while deprecating WaterScrumFall, promoting good sustainable purposeful agility, transitioning the organization design to agility, with DevOps 1st and Lean Finance 2nd. The goal in each case was later to focus on the customer and innovation.
We were all for creative tension, but said to ourselves "why start a >70% chance of failing on a bad footing?". Our Boston Consulting Group DICE scores for change readiness only went green/amber if we either diluted our 6-month goal or limited the scope of the organization we attacked so to speak.
"Why promise lots when you've got delivery plumbing problems" was the rationale. When DICE scores were poor, it didn't take long to decide to :
- go narrow and deep where there is "strong pull", or
- simply aim for better lead times, delivery rates and failure demand, with a view to chasing more customer in the follow-up 6-12 month wave
Spend in scope, in our sphere of infuence, was in tens of millions of USD in the payments company. We avoided metrics and went for measures and trends; we even influenced CxO objectives.