EppsNet Archive: Scrum

Antipattern: Daily Standup is Too Long

19 Jun 2014 /

Scrum recommends timeboxing daily standup meetings at 15 minutes. If you can’t finish in 15 minutes, there may be something wrong with your format.

Are you actually standing up? What are you talking about? Each person should answer three questions:

  1. What have you accomplished since the last meeting?
  2. What do you plan to accomplish between now and the next meeting?
  3. What, if anything, is impeding your progress?

Focus on accomplishments, not just assigned tasks, i.e., don’t say “I’m working on A and I’m planning to work on B.” Don’t have discussions. Anything coming out at the meeting that needs to be discussed can be discussed after the meeting. Try saying this more often: Let’s talk about that after the meeting. Immediately after the meeting if necessary, without even leaving the room, but not during the meeting.

Anyone in the meeting who is not responsible for accomplishing things during the sprint should not be talking.

Are you clicking through a project management tool to review what each team member is working on? Don’t do that. Anyone who wants or needs that information can click through the project management tool on their own time. Talk about accomplishments and blockers.

Why is this important? Well, you can meet or you can work, but you can’t meet and work at the same time. I recently observed a daily standup with 20 attendees (including remote workers) that was running 30 minutes a day, i.e., 15 minutes too long. They were losing 300 minutes per day (15 minutes x 20 people), 25 hours a week, and 100 hours per 4-week sprint.

Do the math on your own standups and decide if it’s important to you.

Thus spoke The Programmer.

All Projects Should Be Early

12 Dec 2013 /

From a Jeff Sutherland Scrum deck:

All projects should be early

You can maximize the value delivered per unit of time or cost by shipping when the value curve starts to flatten out.

It’s a Seller’s Job Market in IT Right Now, Especially for Agile

31 Aug 2012 /

I recently concluded a 3-month job search. As part of my networking, I met a number of unemployed people in other fields who were having trouble not only getting jobs, but even getting interviews.

I talked to a lot of people and averaged about an interview a day, including phone interviews, mostly for development manager jobs. For every development manager job, there are multiple development jobs, so if you’re a developer, your situation is even better than mine was.

I live in Southern California, but the demand is not just local. I had multiple contacts from companies outside the SoCal area that can’t find qualified candidates.

I’ve been working again for over two months, I no longer have an active résumé on job boards, and I still get emails and calls every day from recruiters all over the country.

Agile and Scrum are in demand

West to Chicago, East to Toledo

The situation with Agile and Scrum right now seems to be that a lot of people are putting it on their résumé but most of them are bluffing.

One hiring manager told me that he’d talked to three dozen candidates who claimed to know Scrum and only one (me) who actually knew it.

Another hiring manager asked me to describe the Scrum process, beginning with a product owner with an idea through the end of the first sprint. It’s a basic question, and when I finished, he thanked me for my answer. “You’d be surprised how many people I ask that question and the answer is a yard sale.”

Actually, you’d be surprised how little I’d be surprised by that.

One recruiter contacted me about a 3-month Scrum Master contract in Toledo, Ohio. A glance at my résumé will tell you that I’ve never worked outside Southern California, so on a list of people likely to take a 3-month contract in Toledo, Ohio, my name would be far, far from the top, but the difficulty of finding a qualified candidate to fill that job is such that the recruiter contacted me anyway.

If you really know Agile and/or Scrum right now, it’s a seller’s market.

Customer Discovery and Customer Validation

24 Jun 2012 /

Ask yourself these questions:

  1. Do these users in your user stories exist and have you ever spoken to them?
  2. How are these features helping your customers achieve their goals?
  3. Are these benefits based on any quantitative or qualitative data?

Jeff Sutherland: Scrum: Why Story Points Are Better Than Hours

Posted by on 28 Oct 2011

The Essence of Scrum

28 Oct 2011 /

Good short article by Tobias Mayer on the principles of empiricism, emergence and self-organization, and the mechanisms of prioritization and timeboxing.

How’s That WBS Working for You?

29 Jul 2011 /
Sample Work Breakdown Structure www.wbs-tool.net

Michael James posted this annotated job listing in the Scrum group on Yahoo . . .

[Redacted] is looking for a dedicated and experienced application developer [blah blah blah] to ensure delivery of high quality artifacts, to adhere and to follow [Redacted]’s SDLC. This is an excellent opportunity [blah blah blah] well-known Fortune 50 company.

Tasks and responsibilities


  • Provide accurate and timely estimates (work breakdown schedules)
  • Must have proven ability to provide project estimates and work-breakdown schedules

And you know these guys are getting great results from their precise WBS and SDLC because of these lines:

  • Must be extremely responsive, able to work under pressure in crisis with a strong sense of urgency
  • 24/7 on call responsibilities on a rotational basis

Agile Manifesto 2.0

3 May 2011 /

I’ll share with you what I do in one of my standard presentations — I play with the class or with the audience a game called “Rewrite the Agile Manifesto (link) with your thoughts and feelings now.”

Here is one of the outcomes:

Beyond individuals and interactions to hyper-productive swarming jelled teams and communities of practice.

Beyond working software to high-quality, well architected and well-tested user-centered software services.

Beyond customer collaboration to user collaboration and user involvement.

Beyond responding to change to prioritizing and optimizing for change.

Kanban, Scrum, User Stories, System Design

24 Apr 2011 /

Kanban and Scrum: Making the Most of Both

21 Apr 2011 /

Free download courtesy of Henrik Kniberg, Mattias Skarin and InfoQ.com.

The book includes:

  • Kanban and Scrum in a nutshell
  • Comparison of Kanban and Scrum and other Agile methods
  • Practical examples and pitfalls
  • Cartoons and diagrams illustrating day-to-day work
  • Detailed case study of a Kanban implementation within a Scrum organization

Customer Engagement

24 Oct 2010 /
Book cover

You want to actively elicit feedback from end users using short development cycles or by using prototypes and models during analysis. A good feedback cycle has the appearance of causing problems. It will cause emergent and latent requirements to surface. That means rework: the value of prototypes is that they push this rework back into analysis, where it has more value. And most important, good end user engagement changes end user expectations. It is only by participating in a feedback loop that’s grounded in reality that customers get the opportunity they need to reflect on what they’re asking for. If your customer changes their expectations in the process, you’ve both learned something. Embracing change doesn’t just mean reacting to it: it means providing the catalysts that accelerate it.

— James O. Coplien and Gertrud Bjørnvig, Lean Architecture for Agile Software Development

Adventures in Agile: The Scrum Board

8 Dec 2009 /

For 3-1/2 months, we’ve been using a scrum board — not the one in the photo, but similar — to track tasks on a development project. Tasks start out on the left side of the board in a Not Started column, then move through In Progress, Code Complete and User Testing on the way to Done.

Today someone said, “We need a list of everything that still needs to be done — like the scrum board, but could you put it in a spreadsheet?”

Ummm, I could, but it wouldn’t contain any additional information than what’s on the board.

That was an eye-opener to me. I like the scrum board format because it keeps things visible. It’s easy to see what all the tasks are and it’s easy to see the status of each task.

It never occurred to me that if you record information on Post-Its and stick them on a wall, rather than recording the same information in an “official” format like Excel or Project, there will be people who assume that you’re just screwing around.

NB: It’s not their fault for not getting it; it’s a communication failure by me because I didn’t anticipate the situation.

Thus spoke The Programmer.

Why Would You Use Agile for Offshore Development?

24 Mar 2009 /

More of my customers have been asking me how to use agile processes, particularly Scrum, to help them manage offshore development. Since offshore development undercuts many of the practices that promote agile productivity, I ask them why they don’t just increase the productivity of their teams by thoroughly introducing agility? It seems that offshore development, with its potential for lower unit costs (dollars per programmer day), offers management hope that their losses can be reduced. Since the project is probably going to fail anyway, let’s minimize our losses by lowering our investment by using lower priced resources. A more optimistic, agile, way of looking at this problem is to fix the problem at home and increase the probability of success.

Essence of Lean

4 Jan 2009 /

From Alan Shalloway:

Essence of Lean for People Doing Scrum

  • Lots of concurrent tasks cause waste
  • Focusing on removing delays will remove waste
  • Adding value and getting feedback quickly is important
  • If you make a mistake and don’t attend to why you made the mistake, it will likely repeat itself
  • Minimizing work in process (WIP) is a way of improving efficiency and minimizing risk

Scrum Doesn’t Do Anything

26 May 2008 /

In the end it doesn’t matter what names you use for your processes, good people will do good work and continuously improve what they do. So much of the discussion around Lean versus Scrum (etc.) is about marketing hype, selling consulting and training services, and cornering the market with new name-brands. . . .

Scrum is not a methodology, it is not a process. It is a simple framework underpinned by some common sense principles. Scrum offers individuals and organizations the opportunity to continuously improve the way they work. It provides a space for people to behave like human beings, with trust, respect and passion. That’s about it. But that is huge.

Scrum Cheat Sheet

9 May 2008 /

Read this doc on Scribd: Scrum Cheat Sheet

Waterfall: The USSR of Software

3 Mar 2008 /

Think of waterfall as being similar in concept to the old USSR central planning of the economy. Think of Scrum as similar to a market economy.

The Customer is NOT Always Right

3 Mar 2008 /

Great sequence of posts on the scrumdevelopment Yahoo group . . .

Person A says the number one rule of business is that the customer is always right.

Person B says the customer is NOT always right, like his customer who wants an auction system like eBay on a budget of $1,500.

Person A says Person B needs to shut up and listen to the customer.

Person B says

I AM listening. They want something like Ebay for $1500. They want me to build a full Ebay clone this weekend and then tweak it until they’re happy over the next two weeks. I have listened carefully and diligently and have confirmed multiple times. This is definitely what they want. They’d also like time travel, but they don’t need that until April.

The point I’m making is that there are many reasons why just listening to your customer and giving them what they ask for is often not a good idea – for you or for the customer.

How Long Should it Take to Define a Project?

25 Jan 2007 /

Project X hit a milestone called Vision/Scope seven months ago, 99 days late. It’s 312 days late on the current milestone, which is called Definition.

To date, the project has consumed 36,000 labor hours — 18 person-years — and $2.5 million.

At this morning’s enterprise-level status meeting, it was decided that Project X will be put on indefinite hold, as it is no longer a strategic priority.

This reminded me a lot of an article I read a few days ago:

What the waterfall does well is to keep useless projects from resulting in useless code that needs to be maintained. I’m not sure if that’s the real purpose, but it’s certainly a great side benefit. It may sound inefficient to pay a lot of engineers to get started on projects, do a bunch of analysis and design, and finally abandon the whole thing when something else becomes a higher priority, but every line of code they don’t write is another line that can’t break!

OK . . . you could make a case that waterfall “worked” here — clearly if, after 18 years of effort, people can’t even define the project, that sounds like a project that has no chance of success and shouldn’t be attempted — but it worked at a cost of $2.5 million.

That doesn’t seem very efficient.

What I find is that if you put the customer, the technical team and other appropriate representatives together for as little as four to eight hours, à la a Sprint Planning Meeting, it should be obvious whether or not anyone understands the problem well enough to go ahead and attempt a software solution.

Thus spoke The Programmer.