I’ve just finished reading this article http://www.leadingagile.com/2015/04/making-sure-they-do-it-the-right-way/.
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 “Trusting teams to find the best solution”
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 “Scaling Agility with Klaus Leopold”
This would be a great tool to use with new teams, or a team who needs re-energizing.
Crisp’s Blog » The Agile Meetings Cube
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 “I read this breakdown of the agile manifesto and I think it’s awesome”
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 “New Kanban book”
Over the last few months my team have been using BDD in our scrum. We have been trying to appreciate the full “conversation” sense as well as defining scenarios for automation. We’re getting a lot of value from 3 amigos sessions in the sprint and have found that this has increased communication and collaboration, as well as assuaging the fear of under refining stories up front.
Liz Keogh posted today about BDD and Cynefin. I thought the practical advice and application was interesting.
Continue reading “Scrum, BDD and Cynefin”
I’m a bit of a bookaholic. My reading list is always far too long, (you can see it here if you’re interested) and I’ve generally got about 10 books started. This makes posts like Johanna Rothman’s Minimum Reading List for an Agile Transition catnip for me.
I’m interested in what other people read and what they’d recommend other’s read so I asked around work to see what my colleagues believe to be on an essential agile reading list. Continue reading “An Agile reading list”
Martin Fowler reposted a good blog post on Strangler Applications a couple of days ago: Strangler Application.
This is a practice of replacing legacy platforms peice by peice rather than all at once in a rewrite. His discussion centers around using this method to in order to mitigate risk, which is of course a massive advantage.
Continue reading “Agile delivery when replacing legacy systems”
I read this: 2 Times to Play Planning Poker and 1 Time Not To this morning.
The last part in particular is interesting and has taught me something; I’ve sometimes encouraged teams to validate estimates in sprint planning, but Mike’s point seems solid as to why this is a bit pointless; these estimates are supposed to be rough.
Continue reading “Lessons leant from Mike Cohn: 2 Times to Play Planning Poker and 1 Time Not To”