An initial problem with Large Scale Scrum (LeSS)

I've noticed a bit of a problem with Scrum: it's comes across as hopelessly idealistic and simplistic for many people hearing about it for the first time. If you work in an organisation of any complexity or size you will have felt this gut reaction to hearing a Scrum expert explain the framework: it seems to ignore the reality of the current organisational complexity, existing roles and management thinking.

I was in Sydney last week attending the Certified LeSS Practitioner training by the wonderful Bas Vodde.

At the training I found LeSS triggered an even worse gut reaction: as a direct application of Scrum at organisational scale LeSS seemed too simplistic to address the challenges across multiple teams, systems and functions. The challenges seem much more difficult at organisational scale compared to adopting Scrum at a team level.

I happy to say that after 3 days of stories, exercises, insights and some hilarious videos from Bas, I feel I got past this initial "it's too simple" gut reaction and gained a new perspective on Scrum and some new ways to think about agility at organisational scale. Here is one of the best bits from the training:

Actually creating real feature teams.  Feature teams done properly are for me the central idea for organisational agility in LeSS. This includes the restructuring into fully cross-functional feature teams that work across components in the architecture and implementing the related changes to reporting lines, job descriptions and engineering practices.

One of my favourite parts of the training was how Bas positioned feature teams as a way of forcing organisational agility through continuous learning. He suggested we welcome the problems that specialisation brings. Forming feature teams allows us to deliberately set up a conflict between specialisation and prioritisation. You could also see this as a conflict between efficiency and agility.

If a Scrum team's purpose is to always work on implementing the highest value customer features then there is often going to be a significant imbalance between skills and features. The current specialisations and systems knowledge available in a given team will often not be suitable to implement the selected highest value customer feature.

Bas suggested we exploit this imbalance by challenging teams to learn new systems, skills and domain knowledge and to use this imbalance to force this learning. On the other hand, when there is an available team that already has the skills to implement a feature we should take maximum advantage of the skills in that team by implementing that feature in the best team possible.

This idea of treating team members as expert learners, not as expert specialists was repeated throughout the training and was a challenging idea with many ramifications.

"I used to be a BA, but now I'm a team member"

Many of us had fears about the willingness of staff to be proactive learners and their willingness to work outside their specialisation. One helpful topic was a review of McGregor's Theory X and Theory Y management beliefs, and a reminder that these beliefs can be diabolically self-reinforcing: if you believe staff need a clearly defined job role to be effective this will create narrow work behaviours in staff. Bas pointed out shifting management beliefs takes lots of time, and probably lots of beer.

There were a lot of other gems coming out of the LeSS training, and I'll save these for a future post: scaling the Product Owner role, the feature team adoption map, differences from SAFe and new perspectives on team level Scrum.

If you are interested in scaling your agile adoption outside a single team feel free to get in touch, I'm happy to give an overview of LeSS or discuss how LeSS might be useful in your context.

Is aiming for "done" within a sprint harmful?

Many of my clients new to Scrum often try to fit everything into a 2 week cycle but find that all the work required doesn't fit! Often the definition of done is too long to get something to "done":

One response to this problem is to blame a lack of upfront analysis, and suggest it would be easier to commit to getting to done if more analysis was done up front, and while we are doing that perhaps testing could be allowed to spill into the following sprint:

Unfortunately this suggestion, to do analysis one sprint ahead and testing one sprint behind, leads to long end to end lead times (six weeks in the above example); It also reduces our planning agility, giving us only one chance to implement and provides limited opportunities to react to feedback or to learn as we go.

At this point I usually advise teams to start by looking at making the stories smaller by splitting stories up so that all activities do fit in the sprint. For new teams this can be difficult especially if we have not done any analysis to meaningfully split the story and does not really address the "one chance to get it right" problem.

Consider splitting the work into three iterations: one to learn, one to get it working, and one to polish for release, with all team roles and activities inculding development, testing and review happening for each iteration. At each point collecting feedback and refining the plan:

The first iteration of the story (v1 above) could start from nothing: analyst, developer and tester could working together through the sprint to discover what is possible, what is useful and how we might build, test and deliver it.  I'd suggest the team aim to demonstrate some working software at this stage, even if only a prototype of part of the story.  In v2 we might aim for a fully implemented and tested version perhaps with some rough edges, and in v3 we might aim for a fully production ready operational version. In this way we are deliberately not getting the story to "done" each sprint, instead emphasising learning and iteration over completeness.

Based on this chain of thinking I would say too much emphasis on getting to "done" (or getting it "right") can get in the way of our ability to learn iteratively and isn't learning fast the reason we are using Scrum in the first place?  I'm suggesting that creating multi iteration stories could be a useful practice in this context. If all else fails you can always increase your sprint length: a 3 or 4 week cycle is still much better than 6 weeks!

This is an early draft post, feedback welcome.