Interesting post by Yuval Yeret http://yuvalyeret.com/2011/10/13/scrum-sprint-commitment-rant/
There's a lot in there, but what resonates with me is the danger in commitment becoming at best a "comfort blanket" for product owners, at worst a stick to beat teams with.
Developers seem to be a willing bunch, and often (in my experience) are too eager to please. Now that shouldn't be a bad thing, but it is when you commit to something that you cannot deliver. It easy to skip over the risks in any piece of development work when estimating, and risk is a very hard sell to the business. "Why are you asking me to invest in anticipating problems that might not occur?". Tricky one that.
So, we settle on the "Best Case" scenario as the likeliest outcome. Inevitably, the team will soon be trapped on the "Hamster Wheel of Death", never able to meet the "commitment".
What really matters to me is prioritisation. What gives the business most value, and how can the team best use their resources to ensure swift delivery of that value?
Rather than committing to a fixed number of points, commit to delivering the highest priority item as quickly as possible. Then do the same for the next item. Focus on rapid and continuous delivery of value, and you will feel the love.
Showing posts with label Scrum. Show all posts
Showing posts with label Scrum. Show all posts
Thursday, 24 November 2011
Monday, 14 November 2011
Putting the agility back in Agile
Ok, I don't get around to writing much here, but I have been on a bit of a journey. Having been working with Scrum for many years, I have, over the last 18 months or so, begun to question it's effectiveness. No, let's re-phrase ... Scrum IS effective. It will (if done anything near properly, which isn't usually the case I'm afraid)surface the issues that you have with delivering software. Whether you choose to do anything about those issues seems to be optional with many teams, which makes the exercise a bit pointless. This is the where many then start complaining that Scrum doesn't work.
Scrum does work. It will get you from delivering sod all, to delivering something. That is an achievement, so don't knock it!
However, it is possible to deliver more, and that is where you begin to run in to it's limitations.
What if I want to deliver more often than every 2-4 weeks?
What if my business priorities change weekly or daily?
What if I am spending too long in planning sessions?
Dan North gave a talk which captured many of the reservations I've been having, and offered some possibilities. Have a look and listen.
http://vimeo.com/channels/rootsconf#24681032
Scrum does work. It will get you from delivering sod all, to delivering something. That is an achievement, so don't knock it!
However, it is possible to deliver more, and that is where you begin to run in to it's limitations.
What if I want to deliver more often than every 2-4 weeks?
What if my business priorities change weekly or daily?
What if I am spending too long in planning sessions?
Dan North gave a talk which captured many of the reservations I've been having, and offered some possibilities. Have a look and listen.
http://vimeo.com/channels/rootsconf#24681032
Friday, 7 January 2011
Heads up!
Wow, it's been a while, but I finally have a bit of time to get back to this stuttering attempt at blogging.
Something that I have come across with teams and maybe others have experience of this, is the need for teams to make sure that they are aware of where they are in terms of the sprint.
Scrum, for example has the basic mechanisms for informing us how we are progressing. The burndown should be on a nice angle downwards, and our stand up questions should indicate if anyone is having issues. But does the team, as a whole, have a good feel for how the sprint is panning out?
I ask this because as an ex-developer, I know how easy it is to immerse oneself in the coding and become a little island.
One thing I like to do is get the team to take a step back and take a good look at the the Scrum board. After a stand up, once you're in to the sprint (but not so it's too late to fix things!) have a look at where the cards are. Do things look ok? Are the top priority items getting done? Will there be time to test and fix?
If not, the team can think about how to deal with things. Maybe switching themselves around a bit to help with blockages.
Now - before you tell me this should automatically happen with the stand ups etc, what I find is that you can sometimes surface things that the 3 question format may have missed.
I also like to remind everyone to lift their heads up occasionally and see how evryone else is doing.
Agile development should be collaborative, but sometimes, as individuals, we drift in to isolation. All I am saying is that it doesn't do any harm to say, "heads up!" now and then.
Something that I have come across with teams and maybe others have experience of this, is the need for teams to make sure that they are aware of where they are in terms of the sprint.
Scrum, for example has the basic mechanisms for informing us how we are progressing. The burndown should be on a nice angle downwards, and our stand up questions should indicate if anyone is having issues. But does the team, as a whole, have a good feel for how the sprint is panning out?
I ask this because as an ex-developer, I know how easy it is to immerse oneself in the coding and become a little island.
One thing I like to do is get the team to take a step back and take a good look at the the Scrum board. After a stand up, once you're in to the sprint (but not so it's too late to fix things!) have a look at where the cards are. Do things look ok? Are the top priority items getting done? Will there be time to test and fix?
If not, the team can think about how to deal with things. Maybe switching themselves around a bit to help with blockages.
Now - before you tell me this should automatically happen with the stand ups etc, what I find is that you can sometimes surface things that the 3 question format may have missed.
I also like to remind everyone to lift their heads up occasionally and see how evryone else is doing.
Agile development should be collaborative, but sometimes, as individuals, we drift in to isolation. All I am saying is that it doesn't do any harm to say, "heads up!" now and then.
Tuesday, 20 October 2009
Scrum doesn't work with fixed cost projects!
I have heard many project managers say "Scrum doesn't work with fixed cost projects!" when discussing approaches to software delivery.
I have pondered this and found that it is a difficult issue to solve.
My current thinking, is that the statement is kind of true.
But before you all jump up and down and protest... I think that the statement is true (in a way), but perhaps the "fixed cost" bit is actually what is wrong. Not Scrum.
Why do projects have to have a fixed cost? In order to "fix" cost, you have to estimate the project down to the finest detail up front. Trouble is, such estimates are always wrong. So you will end up either running over budget, or working late for free, or reducing functionality, or even quality.
So why insist on a fixed price? Why not get a clear set of high level goals, with an approximate release plan, with milestones as guides.
Get a rough cost, and release funding in small chunks, re-assessing at every milestone. You can react to changes in scope & requirements with out storing it all up and fighting the fire at the end of the project.
Am I being too simplistic?
I have pondered this and found that it is a difficult issue to solve.
My current thinking, is that the statement is kind of true.
But before you all jump up and down and protest... I think that the statement is true (in a way), but perhaps the "fixed cost" bit is actually what is wrong. Not Scrum.
Why do projects have to have a fixed cost? In order to "fix" cost, you have to estimate the project down to the finest detail up front. Trouble is, such estimates are always wrong. So you will end up either running over budget, or working late for free, or reducing functionality, or even quality.
So why insist on a fixed price? Why not get a clear set of high level goals, with an approximate release plan, with milestones as guides.
Get a rough cost, and release funding in small chunks, re-assessing at every milestone. You can react to changes in scope & requirements with out storing it all up and fighting the fire at the end of the project.
Am I being too simplistic?
Thursday, 14 August 2008
Tools?
Someone has recently posted a question on a Scrum forum, asking about the best software tools to enable the use of Scrum. Ok, they have some issues with remote teams, but they kind of missed the point.
Fortunately, plenty of subscribers have replied with the basic recommendations:
Index Cards (lots)
Post-its
A whiteboard (but a wall will do)
and, if you like the finer things in life, a spreadsheet for generating the burn down graph.
That's what I like about Scrum. It's about doing the simple things (A.K.A "the bleeding obvious") well.
That's not to say I don't like tools though.
I have been trialling some pretty heavy duty tools, and I like them. As a company, we build on a Microsoft platform, and Microsoft have something call Team Foundation Server. It's a pretty nice collaborative development tool that can be used for source control and work item tracking. What's even nicer, is that lots of people are developing tools that sit on top of TFS, that provide templates for managing Scrum. My favourite tool is a "virtual whiteboard" with "virtual cards" that we can move across as we progress. We like this tool so much, we are even considering ditching the physical whiteboard.
But the really important thing is, that we can do this ONLY because we know our process works. The software doesn't make us good at Scrum. It just saves trees and allows us to keep all our information in one place.
The trouble with really neat tools, is that they can easily distract us from the really important thing, which is the process underneath. Don't buy a tool because the packet says that it will cure all your ills. It won't. But if your existing processes are sound, then by all means get something that saves you a bit of time.
Be warned!
Fortunately, plenty of subscribers have replied with the basic recommendations:
Index Cards (lots)
Post-its
A whiteboard (but a wall will do)
and, if you like the finer things in life, a spreadsheet for generating the burn down graph.
That's what I like about Scrum. It's about doing the simple things (A.K.A "the bleeding obvious") well.
That's not to say I don't like tools though.
I have been trialling some pretty heavy duty tools, and I like them. As a company, we build on a Microsoft platform, and Microsoft have something call Team Foundation Server. It's a pretty nice collaborative development tool that can be used for source control and work item tracking. What's even nicer, is that lots of people are developing tools that sit on top of TFS, that provide templates for managing Scrum. My favourite tool is a "virtual whiteboard" with "virtual cards" that we can move across as we progress. We like this tool so much, we are even considering ditching the physical whiteboard.
But the really important thing is, that we can do this ONLY because we know our process works. The software doesn't make us good at Scrum. It just saves trees and allows us to keep all our information in one place.
The trouble with really neat tools, is that they can easily distract us from the really important thing, which is the process underneath. Don't buy a tool because the packet says that it will cure all your ills. It won't. But if your existing processes are sound, then by all means get something that saves you a bit of time.
Be warned!
Subscribe to:
Posts (Atom)