During our last planning meeting, we were unpleasantly surprised that very few items were taken into the sprint backlogs (we have three teams in a LeSS model). Now there were good reasons for this (a lot of unfinished work that had to roll over, middle of vacation season) and no one blamed the teams, but it gave us pause.
The other “red flag” was the structure of the backlog. We bucket our backlog items into four tiers: next sprint, next+1 – next+2 sprint, next+3 – next+5 sprint, no timeline. Combined with some statistical data about the number of items completed per sprint, gives us a measure of confidence about being on track. Well the tier 2 bucket had 3 sprints worth of work and since tier 1 did not empty out as expected, we knew that we had more work than we would be able to get through.
There and then we decided to do a quick scrub of the backlog. Very quickly we decided to classify work items into one of three categories: MVP, neutral, fat. The latter category was things that would help us or make the product a bit better, but were far removed from MVP and the product (and team) could live without it.
We were surprised (though probably shouldn’t have been) that a majority of tasks fell into the ‘fat’ category. Now we are faced with a hard discussion about priorities and verifying our opinion of what is “fat”, but it shows that we do have enough bandwidth to deliver what is important.
When is the last time you looked through the backlog for things that aren’t important?
(All references to we mean myself and my manager – we co-manage the engineers doing the work and act as PO).
Last Monday we had our next sprint planning (#13 for those keeping count). It was a Monday, not the usual Friday to avoid missing half the team, who took a day off to celebrate the last day of school. But this strays from my topic…
I really enjoy what we call “turnaround day” – we do our Sprint Review and Sprint Planning on the same day (more on that another time). One of the reasons is that the team feels very energized during and right after the meeting.
So much that we moved up the Planning in the day, because the engineers actually want to start working on the stories that day. We’ve previously thought that planning on a Friday afternoon would allow people to calm down, have time to absorb the work over the weekend (subconsciously!) and start cracking on it on Monday. Well, surprise!
Why do I think they’re so energized:
new shiny things to do! – new stories, means new opportunities, challenges, valuable contributions
we meet as a team – working in a LeSS framework, this is one of the times members of all the teams come together to collaborate
egalitarian meets experts – on one hand, everyone has input into their team’s backlog sprint, including freshly hired interns; on the other – the technical leads and senior engineers get asked about their opinions on key items
playfulness – there is an amount of joking and ribbing that occurs at the meetings:
we have an informal (and unenforced) rule “you touch the story card last, your team has to take it” – ended with someone using tweezers during planning
last time I heard the phrase “I can take these for my team, since I’m going on vacation” (tongue firmly in cheek)
wayward story cards make it into initial backlog piles, before someone notices the sabotage
And in the end, we are surprised how much the team is able to pick up for the next sprint and they do deliver!
Something that bothers me, is when organizations go out to adopt Agile, but try to do it using traditional program management or waterfall methods. “It’s the only thing they know” – you might say. But if it is, how are you doing the adoption? You have to have Agile coaches or Scrum Masters or Agile practitioners. Someone who knows how Agile works. And why wouldn’t you ask them to organize the adoption.
If you see value in adopting Agile, why not do it correctly? And if you don’t, and treat it as a fad – just don’t do it. Or better yet, let those that want to, do it and let it grow and spread organically. Otherwise, you’ll alienate both the practitioners as well as those that don’t want to change.
Is this just an anti-pattern of “those that can’t do, teach”?
(Note: I do say anti-pattern. I’ve had many amazing teachers throughout my life).
A topic that comes back as a boomerang is how to teach Agile. Specifically, how do you strike the balance of teaching the mindset (starting with the manifesto and principles) versus the practices (most often Scrum).
Leading with the former, runs the risk of coming on as a “hippie” (think of the children people) and runs the risk of alienating your audience. Especially if said audience is a group of experienced engineers, who have little patience with mandatory training or new ways of doing things (because the old ones are so successful).
But focusing on the practices leads to “at-best” cargo cult adoption of practices (again – most often Scrum) that either go on forever “the way they were taught” or decline into a mess of anti-patterns, where the best outcome is probably abandoning the adoption.
If my training, I try to follow the fairly popular image that starts with Agile being a mindset and produces a funnel ending with a myriad of practices. But until my last session (an almost impromptu introduction in a 1:1 setting), I’ve always failed to do one thing – circle back from practices to values and principles. I always knew that those aligned, but only by stating this outright did I grok it. Almost shameful to admit that it took me so long.
So how do you approach teaching Agile? How do you balance the mechanics versus Principles and Values?
On a recent visit to San Diego I had the pleasure of touring the USS Midway – a retired 70-year old aircraft carrier that served up to the First Gulf War. The self-guided tour is a great look at not only the hardware, but more importantly the life on board this great vessel.
What really spoke to me was the role of the Command Master Chief. As a petty officer, the hail from the ranks of the enlisted. As such, they seem better equipped to understand the troubles and toils of the enlisted men and women serving. They are a more natural site as they tour the various stations – in comparison to officers that may be feared or mistrusted. t the same time, their experience and rank means they have little qualms about passing on their and the lower grades’s concerns up the chain of command.
I see many comparisons with the role of people in roles such as Scrum Master or Agile Coach. Those of use that have come up from the ranks of engineers, software developers, etc. have the “street cred” and typically not being part of management can be more effective in getting honest feedback from the team members. And in parallel – since the management is the ones that brought us in – they’re likely to listen to us.
It’s also interesting that the CMC uses a form of Gemba to collect this information.
If the US Navy has been practicing this, since the Vietnam War, shouldn’t companies also take heed?
Recently I finished reading Louis J. Prosperi’s book “The Imagineering Pyramid: Using Disney Theme Park Design Principles to Develop and Promote Your Creativity Ideas”. I won’t go much into the book as the title is pretty self-descriptive.
I did want to share one thought that really struck a chord:
When Walt Disney first began planning for Disneyland, he approached his friend and noted Los Angeles architect Welton Becket about working on the project. (…) Becket told Walt that he should use his own people, because they understood the type of storytelling he was looking for with Disneyland.
I’ve seen many situations, where company leadership will forgo listening to their employees – people they apparently hired, because of their skills / knowledge / experience and trust (?) – instead relying on consultants to tell them what to do. As a former consultant, I know that the greatest value-add we provided was listening to the people and echoing their comments / ides / solutions to management for broader adoption. Yes, sometimes we mixed in best practices from other engagements, but most of the work could be done easily, because management didn’t listen to their own people (and we did).
This is also true in the world of Agile coaching. When I’m in that role, I listen to the team’s problems and work with them on devising experiments to resolve the problems or improve the team. In a role of an employee, I’d like the same courtesy from my superiors – listen to what I have to say and use my expertise. If I didn’t want to apply it here, I’d go looking for a different job.