Comments on: Upsides of Scrum http://lostechies.com/jimmybogard/2011/06/21/upsides-of-scrum/ Strong opinions, weakly held Sun, 19 May 2013 03:22:18 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Anonymous http://lostechies.com/jimmybogard/2011/06/21/upsides-of-scrum/#comment-3533 Anonymous Sun, 26 Jun 2011 20:44:00 +0000 http://lostechies.com/jimmybogard/2011/06/21/upsides-of-scrum/#comment-3533 The places where I've seen it used best is when the weekly planning and retro meetings play a crucial part in communicating with people outside of the dev team.  In this situation, I would not consider these meetings waste, but important communication tools. I scenarios where the team is functioning well and there are no barriers to communication, then a lean / pull model works really well.  Plus you get the added bonus of removing the marathon planning meetings. The places where I’ve seen it used best is when the weekly planning and retro meetings play a crucial part in communicating with people outside of the dev team.  In this situation, I would not consider these meetings waste, but important communication tools.

I scenarios where the team is functioning well and there are no barriers to communication, then a lean / pull model works really well.  Plus you get the added bonus of removing the marathon planning meetings.

]]> By: rhartzog http://lostechies.com/jimmybogard/2011/06/21/upsides-of-scrum/#comment-3488 rhartzog Tue, 21 Jun 2011 13:56:00 +0000 http://lostechies.com/jimmybogard/2011/06/21/upsides-of-scrum/#comment-3488 I'm in  a situation where there are competing product owners who will try anything to get to a developer and have him/her work on the product owners piece.  I am working agile/scrum into the mix and it seems to be well received so far. It does have challenges such as the cultural change of having the product owners decide what the priorities should be as we move all items into a single product backlog.   It really is  a suite of software that the team maintains, and the priorities should not be set by who can put the most pressure on a developer at any given point in time. I like how we are able to provide more visibility into our work and empower the product owners with information needed to make decisions. The common goal is an important piece here and the product owners are requiring some coaching on how we all move together to row the boat in the same direction. It uncovers the blemishes in the system, but just using that information to direct healthy change is very helpful.  I have enjoyed the challenge so far and hope the positives far outweigh the negatives in the long run. I’m in  a situation where there are competing product owners who will try anything to get to a developer and have him/her work on the product owners piece.  I am working agile/scrum into the mix and it seems to be well received so far. It does have challenges such as the cultural change of having the product owners decide what the priorities should be as we move all items into a single product backlog.  

It really is  a suite of software that the team maintains, and the priorities should not be set by who can put the most pressure on a developer at any given point in time. I like how we are able to provide more visibility into our work and empower the product owners with information needed to make decisions. The common goal is an important piece here and the product owners are requiring some coaching on how we all move together to row the boat in the same direction.

It uncovers the blemishes in the system, but just using that information to direct healthy change is very helpful.  I have enjoyed the challenge so far and hope the positives far outweigh the negatives in the long run.

]]>