Category Archives: Scrum

Scrum, Simplifying Business

State of Agile – Survey Results

VersionOne today released the results of their fifth annual “State of Agile Development” survey.  For those of us who have been in the trenches, these results are not surprising, but it’s sure nice to see our anecdotal evidence backed up by a survey that sampled over 4,500 respondents.

As you read the survey results, pay special attention to the question, “How Many Teams Adopted Agile?”  29% of those surveyed work for companies with 10 or mores agile teams, with another 17% reporting between 5 and 10 agile teams.  That’s huge — and it should put rest any lingering doubts about whether or not Agile has gone mainstream.

You can read the survey results online and/or download them as a PDF here: http://www.versionone.com/state_of_agile_development_survey/10/

Scrum, Simplifying Business, Simplifying Software

Prudent/Inadvertent Technical Debt

On the subject of Technical Debt, Martin Fowler identified a TechnicalDebtQuadrant in which technical debt is classified as either Deliberate or Inadvertent and either Prudent or Reckless.  He then makes the case that software projects can reasonably see all four combinations, including Prudent/Inadvertent — even though he can’t think of a real-word analogy that can be used to describe it to management.

How about this? Continue reading Prudent/Inadvertent Technical Debt →

Scrum, Simplifying Business, Tangents and Asides

Team Names – Gotta Have a Slogan

One early, easy win to be had when organizing a new Scrum team is to let the team members name their team.  It takes less than five minutes out of the first Scrum planning meeting, but gets team building and camaraderie off to a great start.

Encourage everyone to come prepared with at least one name suggestion each, along with a slogan for each name.  Winning names always seem to have a catchy slogan.

Continue reading Team Names – Gotta Have a Slogan →

Scrum

The Daily Standup – Sideways

Traditional wisdom says the way to run a daily standup meeting is to go around the room and ask 3 questions: “What did you do yesterday?”  “What do you plan to do today?”  “Do you have any impediments?”

I’ve found a few problems with this approach: First, there’s the deer-in-the-headlights effect.  The three questions are wide open and they call for a certain amount of creativity.  It’s sometimes hard to know what to say to a depth that will be meaningful to the other team members.  So, it’s common to watch someone stutter at first, figuring out what to say and where to begin.  The first person called upon will feel especially under the gun.

A second, related, issue is that by going around the room in order, the team members will anticipate when it’s their time to speak.  So, instead of paying attention to what the others are saying, they’ll tend to be thinking about what they are going to say when it’s their turn.  The big problem here is that, since everyone is given an equal amount of time, it’s too easy to compare one person’s report to the previous, and to the next.  So, everyone feels obligated to not only give a thorough report, but also figure out how to make sure it sounds like they are being personally productive.

The third problem is that this format tends to focus on the facilitator, as if he or she is the only one who cares about the information — collecting status reports — rather than focus on sharing knowledge.

Walking the Board

A better approach is known as “walking the board.”  Continue reading The Daily Standup – Sideways →

Extreme Programming, Scrum, Simplifying Business

Take 5 – A Tip for Running Retrospectives

Quite by accident, I discovered a bit of magic to running a 2-hour retrospective meeting. Halfway in, between the brainstorming part and the planning part, I needed to find a resource on my laptop that was eluding me (a file I had misplaced). So, I called for a 5-min break. I left the conference call phone bridge up and told the distributed team members to just set down their phones and come back in five.

What I discovered is that a few people hung out during the break and started to chat socially across the phone bridge — on the subject of marathons and bike races, in this case. I realized that it was a rare occasion for the distributed team to bond on something other than work. So, I let the conversation continue for a good 10 minutes after the break. I also realized that when we eventually got back into the task of turning our brainstorms into action items, it was with a clean slate and a slightly elevated outlook. I’m positive that the decisions we made during the second half of the meeting were better than they would have been had we gone straight from brainstorming to acting. For one thing, the break allowed everyone to unhook themselves from their particular brainstorm contributions and come back at the whole list with a wider view.

So, from now on, I’m going to find any excuse to take a break, and I’ll be sure to specifically prompt everyone to “chat amongst yourselves while I’m busy doing X.”

Scrum, Simplifying Business, Simplifying Software

User Stories: It’s SMART to INVEST

The basic framework for a good user story has 3 parts: identifying which user/role (or other stakeholder) benefits, what that person wants (the goal), and the payoff (why it’s important).  You’ll often see this framework expressed as the following template: “As a ________, I want ______, so that __________”.   To paraphrase Mary Poppendieck’s quintessential requirements example,

“As the VP of Distribution, I need us to redesign the REAR windshields of our cars to withstand wind-speeds of up to 130 MPH (as our FRONT windshields already do), so that we don’t have any more accidents when our cars are loaded onto transports facing backwards and then hauled at 70 MPH into a hailstorm with headwind gusts of 50 MPH.“

Since the second blank represents a goal, a lot of user-story writers find the SMART mnemonic helpful.  It’s one that’s taught in traditional goal-setting seminars, but as you can see, there’s no consensus on exactly what the mnemonic stands for:

Specific / Significant / Stretching
Measurable / Meaningful
Attainable / Achievable
Realistic / Relevant / Reasonable
Time-bound / Testable / Trackable

So, a better mnemonic that’s especially pertinent to user-stories is INVEST (think “Return-on-INVESTment”): Continue reading User Stories: It’s SMART to INVEST →

Pragmatic Marketing, Scrum

Product Owner is the Most Stressful Role in Scrum

1 Comment

Among other points brought up by Barbara Nelson at the OC APLN meeting last week, she contends that Product Owner is the most stressful role in Scrum, and I don’t doubt that.  I’m sure it’s especially true in organizations that haven’t yet wizened up to the fact that product marketing takes a triad of full-time roles (a Product Strategist, a Technical Product Manager, and a Product Marketing Manager aka. Go-To-Market Manager).  Not only do some organizations try to cram all three roles into a single position, but they often pile on the tasks of a Sales Engineer to boot.

Then, comes along Scrum (or some other form of Agile) and the whole Technical Product Manager role gets turned upside down to become what Scrum calls a Product Owner. About the only good news here is that Mike Cohn shows in his book, Succeeding with Agile, that the time required of a Product Owner while an organization is adopting Agile is not too intense right at the start.  New Scrum development teams place much higher demands on the ScrumMaster than the Product Owner at first, before the ratio flip-flops.  So, there’s a little leeway for the product management organization to figure out how to accommodate Scrum in their day-to-day activities while the development teams are still getting up to speed on Scrum.  That leeway is a small gift that shouldn’t be squandered.

For more about the triad of product marketing roles, be sure to grab Pragmatic Marketing’s free e-book, The Strategic Role of Product Management.

Product Reviews, Scrum, Simplifying Business

pivotaltracker.com, so far, so good

Pivotal Tracker ScreenshotsI started playing with pivotaltracker.com today, which is a free, hosted storyboard tool. It’s free, but not open source, so you do not have the option of hosting it yourself, which means you’ll have to trust Pivotal Labs with your data. This includes: trusting that the service will remain up, trusting that the service will remain free, trusting that Pivotal won’t use your data to compete with you, etc. Some of these issues can be mitigated (e.g. by performing frequent exports of your data.)

Trust issues aside, so far, so good. Continue reading pivotaltracker.com, so far, so good →