Comments on: Scrum vs. Waterfall: The Fight Continues http://www.watermarklearning.com/blog/scrum-vs-waterfall-pt2/ For Business Analysts and Project Managers Thu, 26 Jan 2012 16:13:54 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: ElizabethLarson http://www.watermarklearning.com/blog/scrum-vs-waterfall-pt2/comment-page-1/#comment-370 ElizabethLarson Fri, 16 Jul 2010 18:18:05 +0000 http://www.watermarklearning.com/blog/?p=609#comment-370 Martin, You pose an interesting and important question: what happens when you don't have high-performance team member(s) on your Scrum project. I have seen some teams that are not uniformly high-performing start off OK, get frustrated, and then look to the Scrum Master to resolve conflicts, which is iffy at best. When the Scrum Master remains neutral and doesn't try to take on a leadership role, a leader often emerges who ironically is not the one who talks the most or has the most experience. My preference is for a strong product owners to get the team members motivated because forgetting chickens and pigs,if the project goes awry, the organization (represented by the product owner) doesn't get what it needs. Martin,
You pose an interesting and important question: what happens when you don’t have high-performance team member(s) on your Scrum project. I have seen some teams that are not uniformly high-performing start off OK, get frustrated, and then look to the Scrum Master to resolve conflicts, which is iffy at best. When the Scrum Master remains neutral and doesn’t try to take on a leadership role, a leader often emerges who ironically is not the one who talks the most or has the most experience. My preference is for a strong product owners to get the team members motivated because forgetting chickens and pigs,if the project goes awry, the organization (represented by the product owner) doesn’t get what it needs.

]]> By: ElizabethLarson http://www.watermarklearning.com/blog/scrum-vs-waterfall-pt2/comment-page-1/#comment-368 ElizabethLarson Fri, 16 Jul 2010 17:50:44 +0000 http://www.watermarklearning.com/blog/?p=609#comment-368 Jeff, Great ideas for successful projects, regardless of whether the approach taken is Waterfall or Agile! Thanks so much for writing in! I, too as a PM have found your tips invaluable. The one I should have used more was feedback. Respectful feedback among the team and stakeholders throughout the project would have been a benefit to us all. Again, great tips and thanks! Elizabeth Jeff,
Great ideas for successful projects, regardless of whether the approach taken is Waterfall or Agile! Thanks so much for writing in! I, too as a PM have found your tips invaluable. The one I should have used more was feedback. Respectful feedback among the team and stakeholders throughout the project would have been a benefit to us all. Again, great tips and thanks!
Elizabeth

]]> By: Martin Schedlbauer http://www.watermarklearning.com/blog/scrum-vs-waterfall-pt2/comment-page-1/#comment-346 Martin Schedlbauer Wed, 14 Jul 2010 15:42:46 +0000 http://www.watermarklearning.com/blog/?p=609#comment-346 The issue is not where Scrum and Waterfall are similar, but how they accomplish their tasks and how likely they will succeed in that. Of course, both approaches need to prioritize requirements. The question really is: which ones is likely going to be successful. The waterfall approach of asking stakeholders to prioritize most of their requirements early in the project lifecycle often does not work in practice. The Scrum approach of doing the prioritization at the beginning of each spring is more likely to succeed. Scrum plans "in the small" which is more tangible, whereas waterfall tends to plan "in the large" which is often too abstract for many stakeholders. Jeff's comments on "team health" is also important to consider. Good Scrum teams are those that are relatively small and consist of high performance individuals. An interesting question is the following: what happens when you have to staff a Scrum project with "mediocre" resources either because that is what your company has or because those are the only resource left. Now, those individuals may need more guidance, hand-holding, and "management" -- the hallmark of traditional project management. Scrum requires "willing and able" resources (as well as co-location, strong product owners, etc.) if you don't have those, Scrum is less likely to succeed and more traditional "performance management" may have to be brought to bear. The issue is not where Scrum and Waterfall are similar, but how they accomplish their tasks and how likely they will succeed in that. Of course, both approaches need to prioritize requirements. The question really is: which ones is likely going to be successful. The waterfall approach of asking stakeholders to prioritize most of their requirements early in the project lifecycle often does not work in practice. The Scrum approach of doing the prioritization at the beginning of each spring is more likely to succeed. Scrum plans “in the small” which is more tangible, whereas waterfall tends to plan “in the large” which is often too abstract for many stakeholders.

Jeff’s comments on “team health” is also important to consider. Good Scrum teams are those that are relatively small and consist of high performance individuals. An interesting question is the following: what happens when you have to staff a Scrum project with “mediocre” resources either because that is what your company has or because those are the only resource left. Now, those individuals may need more guidance, hand-holding, and “management” — the hallmark of traditional project management.

Scrum requires “willing and able” resources (as well as co-location, strong product owners, etc.) if you don’t have those, Scrum is less likely to succeed and more traditional “performance management” may have to be brought to bear.

]]> By: Jeff Gordon http://www.watermarklearning.com/blog/scrum-vs-waterfall-pt2/comment-page-1/#comment-295 Jeff Gordon Tue, 06 Jul 2010 18:26:29 +0000 http://www.watermarklearning.com/blog/?p=609#comment-295 I believe there is a fundamental differences which even the heavy hitters of agile never put their fingers on. This viewpoint was extracted from the writings of the early agile folks. In earlier years I developed high performance teams. What we found is that the relative "health" of the team was critical to our success. That health was dependent on a high degree of openness, trust, and recognition for each other's ideas as well as confidence that we were pursuing mutually benefical objectives. Recognition of each other's ideas was an indicator of how much openness and trust existed. Follow through and successful completion of assigned activities is another. A common understanding of the current state, baseline and shared vision of the future state was also most critical to the success of the group. Use of vehicles like sharepoint or a common area on a network for team materials in ongoing development for real time discussion and update is essential. We used meetings only when the group process was needed to resolve issues or make decisions. Everyone was trained in tools and techniques for systematic problem solving. Lastly; and most importantly, intensive feedback among all stakeholders, project members and users throughout the project. Treating each other's work with the utmost respect and the end user as the customer. What I am saying is that good old "Performance Management" avoids a ton of wasted time and gets a team to high quality results every time. Defining the Baseline and Future State. Setting measurable objectives and tasks, giving feedback throughout, and recognizing behaviors and results that contribute to project progress will get the team to success every time! I believe there is a fundamental differences which even the heavy hitters of agile never put their fingers on. This viewpoint was extracted from the writings of the early agile folks. In earlier years I developed high performance teams. What we found is that the relative “health” of the team was critical to our success. That health was dependent on a high degree of openness, trust, and recognition for each other’s ideas as well as confidence that we were pursuing mutually benefical objectives. Recognition of each other’s ideas was an indicator of how much openness and trust existed. Follow through and successful completion of assigned activities is another. A common understanding of the current state, baseline and shared vision of the future state was also most critical to the success of the group. Use of vehicles like sharepoint or a common area on a network for team materials in ongoing development for real time discussion and update is essential. We used meetings only when the group process was needed to resolve issues or make decisions. Everyone was trained in tools and techniques for systematic problem solving. Lastly; and most importantly, intensive feedback among all stakeholders, project members and users throughout the project. Treating each other’s work with the utmost respect and the end user as the customer. What I am saying is that good old “Performance Management” avoids a ton of wasted time and gets a team to high quality results every time. Defining the Baseline and Future State. Setting measurable objectives and tasks, giving feedback throughout, and recognizing behaviors and results that contribute to project progress will get the team to success every time!

]]>