May
24
New Agile Training Courses
May 24, 2010 | Leave a Comment
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
Time, Resources, Scope… and Quality.
May 13, 2010 | 1 Comment
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
Just Enough vs. Just In Case
March 1, 2010 | 7 Comments
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
Temptations of an Agile Project: But that’s Easy! Can’t we just do it?
January 5, 2010 | Leave a Comment
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
Temptations of an Agile Project: Let’s Make the Sprint Longer
December 14, 2009 | 2 Comments
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
Temptations of an Agile Project: Too Many Stories
October 14, 2009 | 5 Comments
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.”
Aug
31
What’s Wrong with Test Driven Development?
August 31, 2009 | 2 Comments
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
User Story Factories
May 6, 2009 | Leave a Comment
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
Process as Religion or How Agile Will Fail
March 10, 2009 | Leave a Comment
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
- Ars Technica
- Dark Reading - IT Security
- Help Net Security
- InformIT
- SANS Internet Storm Center
- Schneier on Security - Dr. Bruce Schieier’s blog
- Security Info Watch
- What to Fix - Daniel Markham, fellow consultant
- Wired Gadget Lab
- Wordpress Documentation
- WordPress Planet
- Wordpress Support Forum
