Monthly Archives: July 2013

The ScrumButt Test (2): Working Software

The second line in the ScrumButt Test says: Software must be tested and working by the end of each iteration. This is the second of three items that confirms the team (project) is “iterative”. There is a series of small tests (within the ScrumButt Test) for whether the team is really doing Scrum (in my […]

Do we need an Impediment List? Yes!

Yes, we need a public impediment list. Every Team does. Why? One argument against is that all impediments should be eliminated immediately.  Yes, if this were possible, this should be done.  But I think that assumes an incorrect view of what impediments are. Yes, it is true some impediments only appear from time to time. […]

Impediments (or symptoms of) – Montreal Class July 2013

Below is a list of ‘failure modes’ for projects, as identified via the experience (in waterfall, whatever, agile or scrum) by the people in the Montreal July 2013 class.  These are not in priority order.  They suggest certain impediments to add to the Public Impediment List for your team. Lack of communication Too many impediments […]

Starting with Scaling

Question: “We are starting Scrum. We have the kind of projects that require scaling. But how do we start with Scrum and have some scaling?” Answer: Maybe the first thing to say is: The basic framework of Scrum does not attempt to answer this question.  It assumes you will use lean-agile-scrum principles and values, and […]

The ScrumButt Test (1): Iterations must be timeboxed

I will be doing a series of posts that discuss each element in the ScrumButt Test (see earlier post). In this first post, I will focus on the first element in the ScrumButt Test: “Iterations must be time-boxed to less than six weeks.” Remember that the first section of the test is to determine whether […]

Achieving the Goal of a Retrospective

Some teams seem to approach Retrospectives without a real drive to succeed.  Or so it seems.  They just use it to ‘talk.’  About the ‘good, the bad, the ugly’ as I sometimes tease. Now, talking can be helpful.  Still, we can usually do better than this. What is the goal of a Retrospective?  Well, I […]

Enabling Specifications

I recommend using the ‘Enabling Specification’ practice. This is NOT part of the bare framework of Scrum. But it is a frequently recommended practice. Typically recommended. This is: Just-enough, just-in-time documentation. Meaning that the implementers in the Scrum Team have enough information to build the user story correctly the first time. Or at least they […]

The Team is primary

There has been a lot of discussion in the community lately about scaling.  With specific discussion of the SAFe and LeSS frameworks. I don’t have a strong opinion on many of the issues. I do think each scaling situation is different.  I do think the music (the values and principles inside the players) is at […]