With the Scrum Gathering fast approaching (don’t forget to check out my two talks) I was recently asked by Dave Prior (The Drunken PM) at ProjectManagement.com to participate once again in his podcast. It reminded me of the interview I did with him at last year’s gathering on my own path from PM to Agility.
When development organizations first consider adopting Scrum, an agile project management approach with clearly-defined roles and processes, there is often confusion about where the use of Scrum is appropriate and where it's not. Jimi Fosdick dispels two pervasive myths regarding where Scrum cannot be used, considers what kind of work is appropriate for Scrum, and describes the keys to Scrum success.
When making the jump from project manager to ScrumMaster, behaviors and techniques that worked well before may work against you in the new paradigm. Here, two experienced project managers and Scrum trainers share their experiences and insights on navigating this challenging transition.
When we are introducing Scrum to a new environment, we often get into debates, sometimes heated, with people who question the validity, truth and/or value of a particular agile or Scrum principle. My general feeling is that any time spent having a philosophical argument with a client/Product Owner is time not spent adding value.
One of the principle practices in Scrum (and in fact most, if not all, agile methods) is the use of “cross-functional” teams. Somewhat surprisingly, there is often resistance at the team level to creating these cross-functional teams, but sometimes this is a result of misunderstanding what we mean when we say that a team is cross-functional.
One of the main myths of traditional project management relates to measurement precision. Traditional project managers have numerous statistical tools in their arsenal. Such measures as earned value or cost performance indicators etc. are touted as providing a precise scientific measure of how we’re doing.
An interesting discussion that frequently crops up when introducing Scrum to certain organizations and individuals is the argument that they don’t have time for backlog grooming because they have “work” to do. I get this argument a lot during coaching engagements when I tell team members they need to spend five percent of their time grooming the backlog.
One of the things we advocate in Scrum (and really most agile proponents do as well) is small cross-functional teams. I discussed what we meant by cross-functional and some of the reasons why in a previous entry. Now I’d like to look at why we recommend small teams.
One question that seems to come up again and again, with unfortunately greater frequency given the realities of lay offs in the current business climate, is: “How do we use Scrum to measure individual performance?” The short, and admittedly unsatisfying, answer is: “We don’t!” The team is a single unit in Scrum that succeeds or fails as a unit.
In case you missed it, I recently gave a talk on the interwebs about, “Agile Certification: Certified ScrumMaster or PMI Agile Certified Practitioner? Which one is right for you?” Since the start of the Agile movement, the only certification that has meant anything has been the Scrum Alliance Certified ScrumMaster (CSM) credential. While it’s still the most widely known and held Agile certification in the world, things started to change earlier this year...
In my public and private Agile and Scrum workshops (click here for a schedule of courses), participants create a parking lot of Agile and Scrum questions. I’m going to make answering those questions a regular feature of this blog. Check back each week to see what questions people are asking. This particular set of questions comes to us from attendees in Dallas, TX.
For today’s “Ask Dear Agilist,” we’re going to do something a little different. Earlier this month I had the opportunity to have a panel discussion with Clint Skelton and Shawna Brown, PMP at the PMI Inland Northwest Chapter’s (www.pmiinw.org) Professional Development Day. The 60 people in attendance generated an enormous number of questions most of which we couldn’t get to during the lunchtime panel.
There has been a lot of interest lately in so-called “Kanban.” While it would greatly alleviate my personal angst to discuss the use of this term, what it really is/means and so forth, that would likely only be interesting to me (and a few other pedantic people who will remain nameless). Instead, I want to talk about taking an Agile approach to what is generally more predictable work than new product development (e.g. for support teams).