EppsNet Archive: Agile

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.


Risk = Cumulative Cost – Cumulative Value

9 Mar 2014 /

Henrik Kniberg has a presentation online called “What is Agile?” It includes a method of visualizing risk as the gap between cumulative cost and cumulative value, as well as methods of visualizing risk mitigation strategies.

I found it valuable. Here are some representative slides:

Big Bang = Big Risk

Agile = Iterative + Incremental

Improving the Value Curve


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.


Agile, ALM, and Agile 2.0 — Putting the Cart Before the Horse?

1 Aug 2013 /
Cart before horse

Speaking of selling chickens still in shells, an august panel of industry giants laid out their recent improvements and plans for ALM products (Application Lifecycle Management, for those not in the know). These guys dazzled the audience with how they’ve moved far beyond simple source code repositories and testing tools to a complete integration of all modern software practices. Quite a coup, indeed, since most real live software developers I’m seeing out there today still aren’t using the practices automated by the ALM tools. . . .

In other words, many software developers aren’t using practices such as test driven development or source version control. Yet here are HP, Microsoft, and IBM announcing new ALM tools that automate more advanced practice in areas not even in use in the first place. Unbelievable.


Ron Jeffries: Estimation is Evil

Posted by on 16 Mar 2013

Are Daily Stand-Ups Harming Your Team?

3 Jan 2013 /

Woody Zuill: Are Daily Stand-Ups Harming Your Team?


Joshua Kerievsky: Stop Using Story Points

Posted by on 12 Oct 2012

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.


David Anderson: What Kanban Coaches Do and Don’t Do

Posted by on 31 Aug 2012

Tobias Mayer: How to Write an Agile Job Ad

Posted by on 21 Aug 2012

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?

David Anderson: Lean Kanban Southern Europe 2012 keynote

Posted by on 11 May 2012

Ruby on Rails for Rubes

28 Apr 2012 /
Ruby Tuesday

(Photo credit: matt hutchinson)

The biggest headache in software development is that most programmers can’t program and don’t want to learn anything.

I recently finished up a MOOC called Software Engineering for SaaS, offered by UC Berkeley through Coursera. For a modest investment of a few hours a week for five weeks, I learned some Ruby on Rails — a well-designed platform and a lot of fun to work with — as well as tools like GitHub, Cucumber, RSpec, SimpleCov and Heroku.

Over 50,000 students from 150 countries signed up for the class. According to a final email from the professors, about 10,000 students attempted at least one assignment or quiz. Or to look at another way, 80 percent of the students gave up without even trying.

Approximately 2,000 students, or 4 percent, completed all four of the assignments and the three quizzes.

One of the enrollees who gave up without trying is a former colleague of mine, an ASP.NET programmer, who threw in the towel when he realized he wasn’t going to be allowed to do the programming assignments in C#.

Evidently he read under Prerequisites: “Programming proficiency in an object-oriented programming language such as Java, C#, C++, Python, or Ruby” and missed the course description at the top of the page: “This course teaches the engineering fundamentals for long-lived software using the highly-productive Agile development method for Software as a Service (SaaS) using Ruby on Rails.”

“I’m not going to learn Ruby on Rails,” he said, as though it was a silly, irrelevant thing to suggest to a professional programmer, like learning a yo-yo trick.

Thus spoke The Programmer.


Steve Denning: The Best-Kept Management Secret On The Planet: Agile

Posted by on 9 Apr 2012

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.


Agile Training: The Four Levels of Agile Requirements

Posted by on 8 Oct 2011

INVEST in Good Stories

30 Sep 2011 /

What are the characteristics of a good user story?

Bill Wake developed the INVEST acronym:

  • I – Independent
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

For a short description of each attribute, see Wake’s excellent article.


Top 100 Agile Books – A list by Jurgen Appelo

Posted by on 25 Aug 2011

The Simplest Thing That Could Possibly Work

28 Jun 2011 /

I ask people to think about the question, “What is the simplest thing that could possibly work?” I’m not asking you to think about what is too simple to work, just to bias your thinking toward eliminating wasted complexity.


Next Page »