Trusting teams to find the best solution

I’ve just finished reading this article

The article is about how difficult it can be for people transitioning into a product owner role to accept that they only need to specify what they want solved, not how to solve it.

The conclusion is that they need to trust the team to find the ‘correct’ solution, as the team are the best people to do this for a number of reasons. The article is well worth a read as it makes you think about one of the fundamental principles underlying the way we work.

This really got me thinking so I’ve added a few things below that I thought were important as well…

Not trusting the team is a lost opportunity: This isn’t about empowering teams because that’s what the process says to do. This is about giving the team the blank slate and seeing what happens. Continue reading

Scaling Agility with Klaus Leopold

InfoQ published a good interview last week, Can You Scale Kanban?, with Klaus Leopold; one of the founding members of the Lean Kanban University.

One of my fellow ScrumMasters at Macmillan, Rosie Curran, and I were very lucky to see him in December at the Holtzbrinck Agile Day in Hamburg with the a very similar talk: Lean and Agile at Scale. He talks about using Kanban’s inherent principles and practices to look at scaling issues; to find ways to improve your processes across teams and departments; and to raise coordination levels between teams.

One quote really struck me:

“If all teams use agile, you don’t get an agile organisation… you get a lot of teams doing agile”

The whole talk was very good and so I dug around and found a video of the same talk from Lean Kanban Central Europe 2014: Continue reading

Using narrative to explain technical work

As a ScrumMaster one of the tasks I’ve found hardest in the past is helping my team in making a case for technical tasks, and then after they’ve done the work helping them present the results & benefits of technical work to stakeholders. I’ve also sometimes felt like there must be a more engaging way to clearly explain to people outside the team how we’re: constantly trying new things, changing the way we work, and changing the way we deploy code.

Last week I found a really interesting slide deck from Martin Fowler & Thoughtworks on the The Architecture of Morrisons OrderPad amongst the 50 odd tabs I perpetually have open, I think it’s brilliant.

Continue reading

I read this breakdown of the agile manifesto and I think it’s awesome

I just read an article I’ve had open a couple of days. It’s a breakdown phrase by phrase of the agile manifesto and I think it’s awesome.

The author says:

Without a culture that embraces Agile, the application of any framework will not reach its full potential…. To build a culture around the Manifesto, we must first explore the meaning behind those 68 words. So let’s follow Lewis Carroll’s advice and “Begin at the beginning, and go on till you come to the end: then stop.”

Continue reading

New Kanban book

I’m a Scrum Master but I like to have a good grounding in other Agile practices so I read up a lot on Lean, Kanban, XP, etc.

However, I’ve been in two minds whether I need a copy of the new Kanban Book: Kanban from the Inside:Mike Burrows. I already have “the blue book“, and I have a lot on my reading list. This interview: Q&A with Mike Burrows about the book Kanban from the Inside has tipped the balance I think.

Continue reading