May

24

I’m happy to announce the availability of the first two courses in my series of agile training courses, a one-day agile overview course, and a two-day course called Agile for Data Professionals. There are a number of other courses in the works, but if you find yourself with a burning need for one of my courses, just let me know and I’ll see what I can do to move it to the top of the queue.

For information on the classes visit the new Training Page!

May

13

Project managers will sometimes refer to the “iron triangle” of time, resources and scope for a project. The idea here is that each of these facets of a project are the leg of some theoretical triangle, and you can adjust your project by making one of the legs shorter if you need to.  How does that relate to software projects? Read more

Mar

1

It’s amazing to me the lengths people will go to in order to have something “useful” to do at work.  The problem is, in their quest to have something to do, they tend to make more work for, and slow down, the rest of us. Read more

Jan

26

Is it Agile, or Chaos?

January 26, 2010 | 4 Comments

Every so often I’ll run  into a product owner, project manager or other stakeholder who thinks that “agile” is the best thing since sliced bread. But it’s not really for the reasons you’d consider healthy. “We can change what we want at any time, because we’re being Agile!” they say. Read more

Jan

5

Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

Sometimes teams get too enthusiastic, and while enthusiasm is a good thing, it can get out of hand. The temptation to add additional bells and whistles to a story in the sprint backlog can be a temptation that’s hard to resist, but resist we should. Why, you ask? Read more

Dec

14

Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

It’s surprising to me that making the sprint longer is such a temptation to a project, but it is. There are lots of reasons that people give for wanting longer sprints, usually it boils down to “we can’t get our work done in two weeks, but if we had three, we could get it finished.”  When questioned about why two weeks isn’t enough, testing seems to be a common sticking point. “We got all the development done, but couldn’t get it tested in time.” Read more

Oct

14

Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

We’re going to talk today about the product backlog. For those unfamiliar, the backlog is the list of functions or features that the product owner or business want in the eventual product. On a Scrum project, these are usually user stories, a sentence in what I call “Cohn Normal Form” is:

I as type of user, want to perform some function so I can receive some benefit.

For instance: “I, as a customer of the bank, want to withdraw money from the ATM, so I can buy a cup of coffee.”

Read more

Aug

31

I’ve recently been working on a project that is making a very determined try to use Test Driven Development (TDD). For those who are unfamiliar with the practice, rather than writing your unit tests after you write your code, you write the tests first.  I’ve known about the practice for years, but this is the first time I’ve worked on a team that’s really doing it, and I’m no less puzzled than I used to be. Well, we should probably talk about first things first. Read more

May

6

It’s no secret how to write a good user story, you just need to keep focused on the outcome you want to see. Cohen’s formula, “I, as a , want to so I can ,” does a good job keeping us focused on that. Still it seems like people want to throw all kinds of things into the backlog as a user story.

I’ve started to notice, however, that there’s another interesting thing out there, which we’ll call User Story Factories. (I was calling them “story generators,” Lowell Lindstrom, a Certified Scrum Trainer, suggested that maybe “factory” was a more appropriate term, which seemed like a sensible suggestion.)

Sometimes someone will suggest a story along the lines of “we need to educate the organization on our new product.” It’s a pretty sensible suggestion, it’s something that the project needs to do, and it has a business value. It presents some interesting challenges when you consider how you get to “done” with that story.

How do you say you’re “done” with educating the organization? You can’t, because there’s always something else you could do.  You can pull specific stories out of this factory, however. You can decide to offer a lunch-and-learn, schedule training, or visit with teams using the current version of your product. All of these have pretty clear criteria as to what “done” means, but the factory itself doesn’t.

I think this is an interesting tool to keep around. When you’re planning iterations/sprints, you can look at these factories and decide if you need to make some progress in the area they describe.  If so, you pull some stories out of the factory, decide on how you’ll be “done,” and put them into the backlog.

Some of the purists might say “that’s not a good story,” but I think it helps keep your customer/product owner engaged with the project if you can speak in their terms. They’re worried about “organizational education,” then cool, keep it around and decide how to get good stories out of that factory.

Mar

10

Something’s been on my mind, and I need to speak up a bit.  I’ve grown increasingly annoyed by agile practitioners who are slavishly devoted to their favorite agile author.   It doesn’t matter if it’s Uncle Bob, Ken Schwaber or Kent Beck, I think there’s something a little unhealthy in some people attitudes.   I’ve seen trained professionals claim that they can’t do something because “Scrum doesn’t say they can.”  I’ve heard them take umbrage with questioning what their favorite author’s written, as though we were questioning the word of God himself.   How dare we question the word of Schwaber?!? Read more

keep looking »

Blogroll

WP Themes