Comments on: How Do You Get from Here to Agile? Iterate. http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate Succeeding With Agile® Fri, 10 Feb 2012 03:51:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Curious Cat Management Improvement Blog » Management Improvement Carnival #84 http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-61189 Curious Cat Management Improvement Blog » Management Improvement Carnival #84 Sat, 12 Dec 2009 18:59:47 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-61189 [...] How Do You Get from Here to Agile? Iterate. by Mike Cohn – “…following an iterative transition process. Making small changes on a continual basis is a logical way to adopt a development process that is itself iterative.” [...] [...] How Do You Get from Here to Agile? Iterate. by Mike Cohn – “…following an iterative transition process. Making small changes on a continual basis is a logical way to adopt a development process that is itself iterative.” [...]

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-59033 Mike Cohn Sun, 22 Nov 2009 09:08:45 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-59033 Hi Peter--It's good to hear from you. You're right that things will get easier as you begin to get some top-down help. Bottom up transitions are great, but they inevitably hit a level where those above do not support the change and will try to stop it. Top-level support helps break down that middle layer of resistance. Good luck! Hi Peter–It’s good to hear from you. You’re right that things will get easier as you begin to get some top-down help. Bottom up transitions are great, but they inevitably hit a level where those above do not support the change and will try to stop it. Top-level support helps break down that middle layer of resistance. Good luck!

]]> By: Peter Green http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-59020 Peter Green Sun, 22 Nov 2009 07:01:46 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-59020 I like the idea of this. I'm working at a company where the scrum adoption is completely grass roots, bottom up, and in this situation one of the challenges we've faced with an improvement backlog is that there is often no "scrum team" responsible for executing on it. One of the indicators of a successful scrum team is that they are 100% dedicated to their scrum team's work, at least for the length of the sprint, and so can fully focus on their commitments for the sprint. With organizational change in a bottoms up org, this is rarely the case, where there is a team of people fully responsible for it, and rarely a true "product owner" of the organizational change to whom the team can commit and demo to at the end. In this situation, we've had to be a lot more flexible with the rules than some of us would like to be, until we can more fully establish and prove scrum's worth at our company. We're starting to see some top-down support and goal setting, so I anticipate that this will really help and we can get much closer to the ideal change management process you describe. I like the idea of this. I’m working at a company where the scrum adoption is completely grass roots, bottom up, and in this situation one of the challenges we’ve faced with an improvement backlog is that there is often no “scrum team” responsible for executing on it. One of the indicators of a successful scrum team is that they are 100% dedicated to their scrum team’s work, at least for the length of the sprint, and so can fully focus on their commitments for the sprint. With organizational change in a bottoms up org, this is rarely the case, where there is a team of people fully responsible for it, and rarely a true “product owner” of the organizational change to whom the team can commit and demo to at the end.

In this situation, we’ve had to be a lot more flexible with the rules than some of us would like to be, until we can more fully establish and prove scrum’s worth at our company. We’re starting to see some top-down support and goal setting, so I anticipate that this will really help and we can get much closer to the ideal change management process you describe.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-58814 Mike Cohn Fri, 20 Nov 2009 13:40:43 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-58814 Good luck, Ådne. Please let me know how it works for you. Good luck, Ådne. Please let me know how it works for you.

]]> By: Ådne Brunborg http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-58798 Ådne Brunborg Fri, 20 Nov 2009 09:43:12 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-58798 Good blog post! Especially since I already had an idea called the "Scrum Process Backlog" I was going to bring to our next retrospective (on monday). :) The idea basically means to establish a heading on the Product Backlog where the team members can write down their ideas, questions, etc regarding the Scrum Process. For example, under the user story "As a developer, I would like a better dialouge with Customer Support" the team members could write ideas like " appoint a designated customer support person that can take time off his normal tasks to help us". These tasks are then to be brought up at the next retrospective, and action is taken. I'm really looking forward to find out if it will work as intended and how the idea will develop in the upcoming sprints! Good blog post! Especially since I already had an idea called the “Scrum Process Backlog” I was going to bring to our next retrospective (on monday). :)

The idea basically means to establish a heading on the Product Backlog where the team members can write down their ideas, questions, etc regarding the Scrum Process. For example, under the user story “As a developer, I would like a better dialouge with Customer Support” the team members could write ideas like ” appoint a designated customer support person that can take time off his normal tasks to help us”. These tasks are then to be brought up at the next retrospective, and action is taken.

I’m really looking forward to find out if it will work as intended and how the idea will develop in the upcoming sprints!

]]> By: Sameh http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-58783 Sameh Fri, 20 Nov 2009 03:57:41 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-58783 For the improvement backlog, I found a useful article at http://bit.ly/24Cnd4. It might be useful to use as Epics for the initial backlog to start with. For the improvement backlog, I found a useful article at http://bit.ly/24Cnd4. It might be useful to use as Epics for the initial backlog to start with.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-58778 Mike Cohn Fri, 20 Nov 2009 02:39:34 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-58778 Hi John- Absolutely, and I've written in previous books that developing knowledge is second in importance only to developing functionality. However, what I'm referring to in the example in my comment is the case where an organization tries something (say 6-week sprints) and learns that it is a bad idea (at least in the organization's current context). Absolutely we have learned something but in a case like this it is almost universal in my experience that if we had it to do over, we wouldn't have made that particular change. Hi John-
Absolutely, and I’ve written in previous books that developing knowledge is second in importance only to developing functionality. However, what I’m referring to in the example in my comment is the case where an organization tries something (say 6-week sprints) and learns that it is a bad idea (at least in the organization’s current context). Absolutely we have learned something but in a case like this it is almost universal in my experience that if we had it to do over, we wouldn’t have made that particular change.

]]> By: John McCoy http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-58760 John McCoy Thu, 19 Nov 2009 22:18:00 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-58760 Mike, Per your comment about the organization not being incrementally improved at the end of each organizational change iteration, I humbly submit that the organization -knowing- more at the end of an organizational change iteration -is- an incremental improvement, even if what they know is that what they tried during that iteration doesn't work in their context. Of course, you allude to that at the end of your comment, but I think it should be more prominent than a trailing parenthetical calling it "good enough". :) We are knowledge workers doing something (software dev) that is extremely knowledge-oriented. Knowing more is better than "good enough", it's the difference between winning and losing. (Rapid learning is also IMHO one of the key reasons why agile is more successful than waterfall/batch and queue models.) Thanks for the blog. This is a great strategy for organizational change. Mike,

Per your comment about the organization not being incrementally improved at the end of each organizational change iteration, I humbly submit that the organization -knowing- more at the end of an organizational change iteration -is- an incremental improvement, even if what they know is that what they tried during that iteration doesn’t work in their context. Of course, you allude to that at the end of your comment, but I think it should be more prominent than a trailing parenthetical calling it “good enough”. :) We are knowledge workers doing something (software dev) that is extremely knowledge-oriented. Knowing more is better than “good enough”, it’s the difference between winning and losing. (Rapid learning is also IMHO one of the key reasons why agile is more successful than waterfall/batch and queue models.)

Thanks for the blog. This is a great strategy for organizational change.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-58753 Mike Cohn Thu, 19 Nov 2009 21:23:01 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-58753 Thanks, John. It's always good to see your name. While I can see and have witnessed how a sprintless approach can work for some development projects, I agree that the timeboxes and focus on a deliverable by and endpoint will be necessary for a transition project. Without the focus and intensity created by the sprint, there are too many competing demands in most companies and attention would get pulled away from the transition effort, I think. Thanks, John. It’s always good to see your name. While I can see and have witnessed how a sprintless approach can work for some development projects, I agree that the timeboxes and focus on a deliverable by and endpoint will be necessary for a transition project. Without the focus and intensity created by the sprint, there are too many competing demands in most companies and attention would get pulled away from the transition effort, I think.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate/comment-page-1#comment-58752 Mike Cohn Thu, 19 Nov 2009 21:20:42 +0000 http://blog.mountaingoatsoftware.com/?p=387#comment-58752 Hi Dan- Thanks for sharing the link to your blog on the value of using Scrum to become agile. You've got some good examples of organizational user stories there so hopefully Juan sees them as well. Perhaps not surprisingly, I have seen two companies who had Gantt charts showing how they would adopt Scrum in one case and XP in another. Now admittedly the activities were high-level but still there's a fundamental incompatibility to assuming we can become agile with a waterfall transition process. Fortunately that type of transition process has begun to fall out of favor in general, anyway, not just among agilists. Hi Dan-
Thanks for sharing the link to your blog on the value of using Scrum to become agile. You’ve got some good examples of organizational user stories there so hopefully Juan sees them as well.

Perhaps not surprisingly, I have seen two companies who had Gantt charts showing how they would adopt Scrum in one case and XP in another. Now admittedly the activities were high-level but still there’s a fundamental incompatibility to assuming we can become agile with a waterfall transition process. Fortunately that type of transition process has begun to fall out of favor in general, anyway, not just among agilists.

]]>