scrum

When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them.

Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members. I don’t advocate this, as I don’t think it demonstrates an appropriate respect for the challenges and significance of the role. In my family, we rotate who... Visit my blog for the full story, links and lots more content on agile development and agile project management...

Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members. I don’t advocate this, as I don’t think it demonstrates an appropriate respect for the challenges and significance of the role. In my family, we rotate who cleans the table and loads the dishwasher. Any of us can do that job. We do not, however, rotate who cooks dinner. My wife is a far better cook than anyone else in the family. We want the cooking to be the best it can be, so we don’t rotate that job. If you want your Scrum team to be the best it can be, I do not recommend that you make a habit of rotating the job of ScrumMaster.

However, there are some occasions when you may want to rotate. The most common is when you want to create learning opportunities. For example, if team members are struggling to understand the duties of the ScrumMaster, they may want to consider rotating each team member through the role. This may allow each to develop an understanding of what it means to be a ScrumMaster. Similarly, if a team identifies four or five good ScrumMaster candidates among their ranks, it may want to rotate among them, giving each a chance to try the role. Then by considering the performance of each, the team will hopefully be able to choose the most appropriate ScrumMaster.

Bob Schatz and Ibrahim Abdelshafi of Primavera Systems point out another reason why rotating might be useful.

With time the team can begin to treat this position as their manager. And the person in that position typically detects and dutifully fills the apparent need. The result is a breakdown in the team’s self-management practice. By rotating the responsibility at the start of each sprint, it diffuses the role and makes it a shared team responsibility and establishes a balance of power. (The Agile Marathon in the Proceedings of Agile 2006)

So, although it is possible to rotate the job of ScrumMaster, I recommend doing it only for specific reasons, such as those just given, and only temporarily. Rotating should not be a permanent practice. There are simply too many problems with it, including the following:

• Someone who has rotated into the role usually has other, non-ScrumMaster tasks to perform during the sprint, and these often take priority.
• It’s hard to train enough people to do the role well.
• Some people will use their time as ScrumMaster to try to push through changes to the process.
• Designating someone as ScrumMaster for a sprint or two does not automatically make someone value the job, which can lead to ScrumMasters who think Scrum is a mistake.

First, many have said that there are a lot of bad managers in the US, and in the world. Peter Drucker worked on this. W. Edwards Deming had his ideas, and worked on this. And many many business gurus have had their say, trying to improve the manager... Visit my blog for the full story, links and lots more content on agile development and agile project management...

Visit my blog for the full story, links and lots more content on agile development and agile project management...

Ken Schwaber, the founder of Scrum, has a blog.  In it, someone mentioned that Scrum is changing.  Ken responded: If you change the Scrum framework you just simply aren’t using Scrum and are probably canceling some of its most important benefits. Thank you Ken!  I wholeheartedly agree.  Every CSM... Visit my blog for the full story, links and lots more content on agile development and agile project management...

The Product Owner is both one of the most important roles in Scrum and often the most difficult to fill. In this post, I will explore a few aspects of successful product ownership that are often done poorly or not at all. Manage Both the Big Vision and... Visit my blog for the full story, links and lots more content on agile development and agile project management...

This is, to me, still a New Year.  And a friend suggested I talk about New Years' resolutions.  Or something like them, Sprint commitments. Henry Ford said: Whether you think you can or you can't, you are usually right. So, let us work bac... Visit my blog for the full story, links and lots more content on agile development and agile project management...

My PMI-ACP Book is coming along nicely and today RMC released some more content including sample questions and walked through explanations of the answers. Visit the RMC Site to access it and also sign up for future previews and special discounts. Now if I could only write this stuff as quickly as they are giving it away, I would be doing OK! 

A widespread myth I've noticed in Agile software development is, No documentation in Agile or Documentation is wasted effort. Particularly during a transition from Waterfall to Agile, we appreciate the benefits of adopting typical Scrum practices, such as short iterations, timeboxing, daily scrums, retrospective, and so on. We also try to get away from the tasks and activities that we found monotonous before Agile adoption documentation, writing proper code comments, etc. But is it really correct to completely stop documentation and code comments?

I was at home a couple of Sundays ago, watching a Chelsea vs. Liverpool football match (soccer, for those Americans reading) a match Liverpool ultimately won. It was during the post-match analysis that I was struck by some parallels between what Chelsea is going through and my own current client engagement to move from Waterfall to Scrum.

I was at home a couple of Sundays ago, watching a Chelsea vs. Liverpool football match (soccer, for those Americans reading) a match Liverpool ultimately won. It was during the post-match analysis that I was struck by some parallels between what Chelsea is going through and my own current client engagement to move from Waterfall to Scrum.

I've always wondered -- not just as a developer but as a human being -- why I needed to follow the orthodox methods of typical hierarchical reporting. There was always some middle man confusing the conversation. You can define many roles in a typical hierarchical organization, and

A question I've heard often is: Is it correct, in Scrum methodology, to track an individual's performance? This question has only one answer: No. Tracking and measuring the productivity of a single member of an Agile team is against the spirit of Scrum. The real question should be...

I’ve published another book! This one’s called “Lean from the Trenches“. It is about how we scaled a 60-person project by combing techniques from Kanban, Scrum, and XP. I chose this title because it really it illustrates how to put Lean principles into practice in a software project, especially the notion of an end-to-end Kanban system, divided into tiers to coordinate multiple teams.

We learned a lot during this project and I’m really happy that I found the time to write about it. The book follows the same style as “Scrum and XP from the Trenches“, with 100% focus on real-life experience rather than theory. Lots of pictures and examples as usual.

You can get a hold of the book here, and also participate in a discussion forum. http://pragprog.com/book/hklean/lean-from-the-trenches

Any feedback is welcome.

If you’ve read the book and feel like adding a review on amazon then that is greatly appreciated

Hi Brazil!

I’m happy to say that I’ll be visiting you in a few weeks.

I’ll be involved in two public events together with Samuel Crescêncio:

• Feb 10: Public seminar about Lean & Agile (in Florianopolis). More info coming soon.
• Feb 13-14:  Certified ScrumMaster course in São Paulo.

Every day, product owners face the challenge of coming up with the correct acceptance criteria to help the team understand the story. During the acceptance testing, you almost never fail to hear from the team that the acceptance criteria were eith...

When someone tells me, A Sprint is mini Waterfall, I quickly respond, No! And I do this often, because time and again I hear this opinion from people who are new to Agile. I even hear it from...

Direct Nokia Store link - http://store.ovi.com/content/214273

I've released the free Daily Wallpaper for Nokia N9 a couple of months ago. Since that time it enjoyed nearly nine thousands of downloads (quite a number for this platform) and was keeping me personally entertained. Once an hour (or once a day or once a month) it is downloading the fresh cool wallpaper from flickr and every time I unlock the phone I can enjoy a new interesting photo.

Since the moment of release, the most popular request (sometimes even causing the low rating in the Nokia Store) was not to rotate the too wide images, but to cut the central part out of it. I do love the rotation, but my opinion is totally irrelevant compared to the customers. So since yesterday, version 1.1 knows how to do both rotation and cutting. Cutting is the default mode. Enjoy and, please, submit more requests or vote on the existing ones.

I am overdue for providing an update on how my work on The PMBOK v5 Guide is going. Well, it is on its way. The process is slow (sometimes painfully slow) but this is because of the number of people involved and the review process used. To give an idea, here is the plan for the next 6 months:

*  17 February – 20 March 2012: the exposure draft PMBOK® Guide – Fifth Edition will be open for comments

*  Late February 2012: team training for our adjudication processes

*  20 March 2012: our exposure draft period closes and comment adjudication begins

*  20 March – 28 April 2012: teams adjudicate exposure draft comments 

*  Early May – mid May 2012: core committee reconciles any comment adjudications that cut across chapters or where consensus has not yet been obtained

*  Mid May – early June 2012: appeals period for adjudication decisions; final draft QC and integration reviews

*  Early June – mid June 2012: appeals adjudication and resolution

*  Mid June – late June 2012: final draft cleanup and incorporation of QC comments

*  28 June 2012: core committee vote on finalized draft

The Exposure Draft process is a great mechanism for allowing members to review and comment on new material, but likely to generate a ton of review work for us. The Fourth Edition update, back in 2008 received over 4,400 comments during its exposure draft.  Since the membership of the PMI has increased significantly since 2008 we could be looking at close to double that figure.

That is a lot of suggested changes to review and I think March and April will be a busy time for me. Of course they will not arrive in one Word document, but I wonder what the PMBOK Guide would look like if we just did an “Accept All”? Right now it is the calm before the storm; I am going to make the most of it.