Comments on: Sprints and Compelling Goals http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/ A blog designed to sprint! Fri, 03 Feb 2012 05:45:25 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: francois.beauregard http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/comment-page-1/#comment-2658 francois.beauregard Mon, 14 Mar 2011 23:37:09 +0000 http://urbanturtle.com/blog/?p=366#comment-2658 Thanks Sylvie for your thoughtful comment. ~françois Thanks Sylvie for your thoughtful comment.

~françois

]]> By: Sylvie Trudel http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/comment-page-1/#comment-2656 Sylvie Trudel Mon, 14 Mar 2011 17:56:11 +0000 http://urbanturtle.com/blog/?p=366#comment-2656 It's true, teams tends to focus more on their velocity than the business value they deliver. But why? In my experience, the business value is reraly communicated to teams, if ever measured or estimated. But why? It may be because agility is simply viewed as a software development method rather than a business philosophy of delivering value through software features. So what does the team is seeking for if the business value is not provided? Its own value, measured with a velocity indicator. And they will grasp to it in the absence of a better measure and because it their own measure. Having a time-box container to acheive priority items is fine, they buy that no problem when all backlog items are prioritized by the right product owner. But is that always the case? Not in my experience. Lots of work must be done with business people so they provide necessary ingredients for any team to have a compelling experience with their project: a sense that their work is worth living for. On the other hand, you've got IT management who is responsible for the performance of their organization. When the organization sets a project, it's assumed that there is a positive ROI when not communicated. So IT managers needs to optimize the cost factors when they have little influence on business value of the software. Agile teams make their velocity transparent and IT managers will take that. However, since this indicator can haldly be standardized accros the organization (because the points used as basis for velocity calculation have different meaning from one team to another), it may not be the right indicator for them to use. But when the only tool you have is a hammer, everything looks like a nail. So, when adopting agility, management practices and performance measured must also be reviewed to ensure decisions will be based on reliable and portable measures. It’s true, teams tends to focus more on their velocity than the business value they deliver. But why? In my experience, the business value is reraly communicated to teams, if ever measured or estimated. But why? It may be because agility is simply viewed as a software development method rather than a business philosophy of delivering value through software features. So what does the team is seeking for if the business value is not provided? Its own value, measured with a velocity indicator. And they will grasp to it in the absence of a better measure and because it their own measure.
Having a time-box container to acheive priority items is fine, they buy that no problem when all backlog items are prioritized by the right product owner. But is that always the case? Not in my experience. Lots of work must be done with business people so they provide necessary ingredients for any team to have a compelling experience with their project: a sense that their work is worth living for.

On the other hand, you’ve got IT management who is responsible for the performance of their organization. When the organization sets a project, it’s assumed that there is a positive ROI when not communicated. So IT managers needs to optimize the cost factors when they have little influence on business value of the software. Agile teams make their velocity transparent and IT managers will take that. However, since this indicator can haldly be standardized accros the organization (because the points used as basis for velocity calculation have different meaning from one team to another), it may not be the right indicator for them to use. But when the only tool you have is a hammer, everything looks like a nail. So, when adopting agility, management practices and performance measured must also be reviewed to ensure decisions will be based on reliable and portable measures.

]]> By: non complex stuff | Change is the job of the ScrumMaster http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/comment-page-1/#comment-868 non complex stuff | Change is the job of the ScrumMaster Tue, 19 Oct 2010 18:01:43 +0000 http://urbanturtle.com/blog/?p=366#comment-868 [...] behave and thus work together, which in turn can radically improve performance. François shared a similar view recently on Scrum teams, compelling goals and [...] [...] behave and thus work together, which in turn can radically improve performance. François shared a similar view recently on Scrum teams, compelling goals and [...]

]]> By: Implementing Scrum and Agile … Tools, please disappear! at Urban Turtle's blog http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/comment-page-1/#comment-751 Implementing Scrum and Agile … Tools, please disappear! at Urban Turtle's blog Fri, 08 Oct 2010 13:10:07 +0000 http://urbanturtle.com/blog/?p=366#comment-751 [...] [...] [...] [...]

]]> By: francois.beauregard http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/comment-page-1/#comment-468 francois.beauregard Mon, 16 Aug 2010 17:31:11 +0000 http://urbanturtle.com/blog/?p=366#comment-468 Hi Luc, Thank you very much for your comments. ~françois Hi Luc,
Thank you very much for your comments.

~françois

]]> By: Luc Jeanniard http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/comment-page-1/#comment-289 Luc Jeanniard Wed, 21 Jul 2010 04:27:07 +0000 http://urbanturtle.com/blog/?p=366#comment-289 Some of our teams use Kanban. I've been in two of them for a year. There is no sprint planning and I miss a lot about committing to an increment of potentially shippable product. This impact my motivation negatively. When the TODO Kanban board column is under the fixed limit, "the product owner" add new ones without team discussion. It is far more productive to have a team participate to sprint goals as it maximize the team members commitment. I was member and ScrumMaster of several Scrum Team for 5 years, I've experimented Kanban ... and I choose SCRUM (if I can ;o). Some of our teams use Kanban. I’ve been in two of them for a year. There is no sprint planning and I miss a lot about committing to an increment of potentially shippable product. This impact my motivation negatively. When the TODO Kanban board column is under the fixed limit, “the product owner” add new ones without team discussion. It is far more productive to have a team participate to sprint goals as it maximize the team members commitment.
I was member and ScrumMaster of several Scrum Team for 5 years, I’ve experimented Kanban … and I choose SCRUM (if I can ;o).

]]> By: Effectively Tracking Cost in Scrum at Urban Turtle's blog http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/comment-page-1/#comment-147 Effectively Tracking Cost in Scrum at Urban Turtle's blog Tue, 29 Jun 2010 03:27:29 +0000 http://urbanturtle.com/blog/?p=366#comment-147 [...] When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals) [...] [...] When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals) [...]

]]> By: PIA Blog / Productivity by Design » Notre revue de presse (25/06/2010) http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/comment-page-1/#comment-135 PIA Blog / Productivity by Design » Notre revue de presse (25/06/2010) Fri, 25 Jun 2010 17:09:42 +0000 http://urbanturtle.com/blog/?p=366#comment-135 [...] [...] [...] [...]

]]> By: @EricMinio http://urbanturtle.com/blog/2010/06/14/sprints-and-compelling-goals/comment-page-1/#comment-108 @EricMinio Mon, 14 Jun 2010 15:33:41 +0000 http://urbanturtle.com/blog/?p=366#comment-108 To push this idea in the same direction as you are Frank, I would like to write a few lines about these velocity-driven scrums too. I meet teams whose first concern during a sprint planning is to "fill the sprint". For these teams who, in my opinion, have forgoten the spirit of scrum and who ask for help to get more profit from scrum, I propose to hide estimations during the sprint planning and focus on what increment of potentially shippable software they think they can deliver during this sprint. This leads to very different discussions. For example pushing back high priority items because nobody knows what it is about. Or figuring out how to break down big items and build an incremental strategy to deliver the value. Those are value-driven discussions that keep minds open to an emergent backlog rather than veolicty-driven discussions that most of the time try to deliver a predetermined backlog. To push this idea in the same direction as you are Frank, I would like to write a few lines about these velocity-driven scrums too.

I meet teams whose first concern during a sprint planning is to “fill the sprint”. For these teams who, in my opinion, have forgoten the spirit of scrum and who ask for help to get more profit from scrum, I propose to hide estimations during the sprint planning and focus on what increment of potentially shippable software they think they can deliver during this sprint.

This leads to very different discussions. For example pushing back high priority items because nobody knows what it is about. Or figuring out how to break down big items and build an incremental strategy to deliver the value. Those are value-driven discussions that keep minds open to an emergent backlog rather than veolicty-driven discussions that most of the time try to deliver a predetermined backlog.

]]>