Archive for the ‘ScrumMaster’ Category

• Best Links of the Week – Christmas 2009

  Date: 2009.12.25 | Category: Agile, Coaching, Links of the Week, Product Owner, Scrum, ScrumMaster, Team | Response: 0

  A bag full of Christmas links.

  1. Grooming the Product Backlog – Laura Brandenburg talks about the role of requirements management through the Scrum Product Backlog.
  2. Make the Product Backlog DEEP – more on good practices for maintaining the Product Backlog from Mike Cohn.
  3. Why is Agile so Hard to Sell? – describes some of the issues growing Agile in the enterprise.
  4. Is Scrum for Lazy Project Teams? – looks at the misconception that Scrum does not challenge teams to work their hardest.
  5. When the Scrummaster Becomes the Impediment – different perspectives on how to solve the problem when the Scrummaster becomes a bottleneck.
  6. A Day in the Life of a Scrum Team – a short 6-minute YouTube video of a Scrum Team in their native environment.
  7. Agile Business Analysts – what is the role of the business analyst on an Agile team?
  8. Building trust – five concrete things you can do to build trust on your teams.
  9. Something in Agile Needs Fixing – Rob Bowley summarizes the Open Space discussion on the topic of “Agile isn’t solving our customers problems because they aren’t here.”

• Best Links of the Week – Dec 18th 2009

  Date: 2009.12.18 | Category: Agile, Coaching, Communication, Links of the Week, Product Owner, Scrum, ScrumMaster, Team | Response: 0

  Here are links to the best of the blogs for the week of Dec 18th 2009.

  1. A ScrumMaster’s Checklist – a comprehensive checklist from Michael James offering four areas a ScrumMaster should pay attention when coaching: the Team, the Product Owner, the organization and the technical practices.
  2. Agile Leadership: Methodology Ain’t Enough – the Hacker Chick brings us a blog article about the management beliefs and behaviors which support the growth of Agile teams.
  3. When Should QA be Engaged in an Iteration? – Hiren Doshi PMP discusses the role of QA on a Scrum team and tackles the myth that QA folks “have nothing to do until the end of a Sprint”.
  4. Five Reasons to Hire a Coach for Agile Teams – Ester Derby talks about five pitfalls of DIY (Do-It-Yourself) Agile coaching.
  5. Scrum Doesn’t Do Anything – explanation of how Scrum only comes to life when people are added to the framework and the importance of the following the rules by Tobias Mayer.
  6. Practical Agility: On Estimation – Dave Rooney describes the Agile estimation lessons he learned while undergoing a recent move.
  7. Overcoming Technical Challenges for Adopting Agile Methods in the Enterprise – Vijay Narayanan over at InfoQ discusses the importance of having an development environment which supports your Agile process.
  8. Flipping Out – short description of how Flickr uses Continuous Integration and a Single Code Base to add features to their application without branching.

  There was a lot of great stuff to read this week, unfortunately I can only go with eight or so entries.  Cya next week!!

• My Insights on Distributed Scrum Teams

  Date: 2009.09.28 | Category: Agile SD, Presentations, Scrum, ScrumMaster | Response: 0

  Come to XPSD on October 1st where I will share my ideas and experiences gained while in Shanghai.  I am not sure if I will turn my presentation into a post, but I will give away my key point now: you will have much more impact improving the performance of your Scrum teams by providing soft skill training to the ScrumMasters rather than training on hard skills, i.e. estimation, Planning Poker, Scrum mechanics, etc.

• Importance of the Definition of Done

  Date: 2009.09.04 | Category: Agile, Coaching, Scrum, ScrumMaster, Team | Response: 0

  I was looking back at some old notes of mine from China and I came across a number of questions from the people I worked with about the Definition of Done.  The Definition of Done (DoD) is a very important concept in Scrum and not spending time to construct a DoD is a common mistake with new Scrum teams.

  In my opinion, the DoD provides visibility and alignment on just exactly what it takes to get a user story completed in an organization.  It could almost be seen as a unstructured value-stream map.  We write down the DoD to illuminate any hidden queues in the organization and to make visible the real effort it takes to complete a user story.  It is also there to protect the Team since it cannot be changed during a Sprint.  Nothing irritates me more as a Team member, or a ScrumMaster, to move the goalposts of a Sprint after it has begun, i.e. adding a new auditing requirement to the DoD.

  The DoD is NOT the same as the acceptance criteria for a user story.  The DoD is an engineering checklist for the cross-functional Team.  The acceptance criteria is the checklist Product Owner and stakeholders use to know if a user story is complete.  They assume all the items in the DoD are complete and if they are not (that is called Design Debt), the Team cannot demo the feature at Sprint Review.  You can think of the DoD as the pre-requisites that need to be finished before a story may be shown at Sprint Review.

  Finally, I have found it better for individual Teams to come up with their own DoD rather than be handed one from management.  When first working with a Team, it is normally better to document what the Team is doing and label that it’s DoD and add to it over time rather than forcing some onerous DoD created by some disconnected process people who don’t even do the work onto an uncertain Team.  Of course, there are some basic standards (code reviews, some form of pair programming, unit testing, etc., etc.) that must be in all DoD, but I find most Teams will include them on their own.

  So what to do when your company has 12 versions of the DoD floating around?  Well, that is why you have ScrumMasters.  It is their job to get the various Team DoD in alignment, not the process goons.  The process goons have good stuff to add to the DoD and Scrum is about collaboration, not forcing other people to do your will.  If the process groups want Teams to do extra work, their requests on the Team are made visible just like everyone other.