I was very happy to see this week that Lulu, where I print my AgileMan books, was able to produce and deliver the print drafts of More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done) and The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile) in less than a week! I ordered them Sunday afternoon and they arrived the following Friday! That's quite impressive and in fact exceeded my expectations by about 50%. (That's the good news; the bad news is that even their cheapest shipping option is now more expensive than it used to be, meaning that they've already started eating into my profit margin before I even sell the first copy!)
After Vicki and I checked over what had arrived, I made a few minor tweaks and then placed an order large enough to cover all of the requests that have come in to-date plus a handful of extra copies of each book. Based on the estimate provided by Lulu on the order, I would think that they might arrive sometime during the week of Dec 15th, or possibly earlier if I get really lucky. It's hard to predict just how much things will slow down in December because of holiday-related activity, though. It's still possible that the books won't arrive until after Christmas, which would be more in line with what I imagined when I planned out the self-publishing schedule leading up to this.
In any event, we're on the last leg of the journey for the 2nd AgileMan book, and those of you out there who are eagerly awaiting it (c'mon! stand up and be recognized, both of you!!) should know that it won't be much longer before you have it in your hot little hands. I still have to figure out, logistically, how I'm going to get copies to all of those people at my former workplace (I can't exactly book a meeting room for it, after all!), but I'm sure that we'll figure something out.
Saturday, November 29, 2008
Thursday, November 27, 2008
New Mike Cohn Agile Book In The Offing
I stumbled across this link to a website where you can download and preview a few draft chapters from Mike Cohn's upcoming book, Succeeding with Agile. I'm not sure which excites me more: the fact that Mike has a new book coming out, or that he's providing the option for interested parties to preview the work and give feedback on it ahead of publication!
Anyway, I definitely encourage other Agile enthusiasts out there to do what I'm about to: visit the site, check out what Mike has to say and help him make the book even better!
Anyway, I definitely encourage other Agile enthusiasts out there to do what I'm about to: visit the site, check out what Mike has to say and help him make the book even better!
Wednesday, November 26, 2008
Let History Be Your Guide
I was asked an interesting question yesterday, thanks to the magic of Instant Messaging. One of my friends at the company that I used to work for (in my capacity as AgileMan) wondered if either my wife or I had ever heard of something called "empirical forecasting." We hadn't, but as he told me more about what he'd been reading (and even shared some of it with me), I realized that it was something that I'd been practicing during the final few months of my employment. It's also a topic that I wrote about briefly in More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), although you'll just have to take my word for that until the book actually comes out! I just hadn't had a fancy name for it, until now!
Basically, that style of forecasting or planning involves using the empirical (or observed) data that you have, and only predicting what can be extrapolated from it. In other words, you only expect to get results that match what you've gotten in the past. That may sound obvious to some, but in my former company, it was rarely the way planning occurred. I sat in countless meetings in which statements like the following would be made:
"Our owners need ______ (some set of features) by ______ (some date in the future) so now we need to figure out how to deliver it."
Put another way, we'd start at a desired outcome and try to work our way backwards from it. I completely understand why we always felt that it was necessary to do things that way, but repeated failures of that approach should have incontrovertibly shown the folly of it at some point. Instead, it continued to happen.
What works much better, I believe, is to base your schedules on what has been proven in the past. For example, our development teams each had a certain average velocity (in Story Points) that they'd worked at for the past N Iterations (where N could reasonably be any integer between 3 and 6, let's say). Realistically, if that's what they did in the past, it's likely going to be close to what they'll do in the future. Therefore, you should expect about the same productivity going forward, and anything beyond that is just wishful thinking. If a team has 100 Story Points of work left, for example, and they work at an average velocity of 15 Story Points each Iteration, then you could reasonably assume they'd finish all of the features in roughly 7 more Iterations, with the caveat that the "remaining work" doesn't change dramatically in the meantime. What would happen all too often in my former workplace were frantic meetings in which endless discussion would ensue as to how to shorten that timeframe down to 3 or 4 Iterations. In the end, of course, it would still take 7 Iterations, or even possibly longer, if enough churn had happened in the process such that it actually made additional work for those involved!
In my conversation yesterday, the other person even talked about using simple line graphs to predict when the work remaining would hit zero, including accounting for features that have been added or removed. I think that sort of graphical representation can certainly help in such matters, as some people relate better to pictures than to words. In either case, though, your expectations are limited to an extrapolation of what's already happened, rather than relying on the time-honoured "... and then a miracle occurs" (as we all used to fall back on for those impossibly-hard university math exam proofs!).
In order to use this sort of technique, of course, you need development teams that can become fairly good at providing relative estimates (such as Story Points). That's no easy challenge, but it's also a big enough topic to warrant a separate blog post, and so I won't tackle it here!
Basically, that style of forecasting or planning involves using the empirical (or observed) data that you have, and only predicting what can be extrapolated from it. In other words, you only expect to get results that match what you've gotten in the past. That may sound obvious to some, but in my former company, it was rarely the way planning occurred. I sat in countless meetings in which statements like the following would be made:
"Our owners need ______ (some set of features) by ______ (some date in the future) so now we need to figure out how to deliver it."
Put another way, we'd start at a desired outcome and try to work our way backwards from it. I completely understand why we always felt that it was necessary to do things that way, but repeated failures of that approach should have incontrovertibly shown the folly of it at some point. Instead, it continued to happen.
What works much better, I believe, is to base your schedules on what has been proven in the past. For example, our development teams each had a certain average velocity (in Story Points) that they'd worked at for the past N Iterations (where N could reasonably be any integer between 3 and 6, let's say). Realistically, if that's what they did in the past, it's likely going to be close to what they'll do in the future. Therefore, you should expect about the same productivity going forward, and anything beyond that is just wishful thinking. If a team has 100 Story Points of work left, for example, and they work at an average velocity of 15 Story Points each Iteration, then you could reasonably assume they'd finish all of the features in roughly 7 more Iterations, with the caveat that the "remaining work" doesn't change dramatically in the meantime. What would happen all too often in my former workplace were frantic meetings in which endless discussion would ensue as to how to shorten that timeframe down to 3 or 4 Iterations. In the end, of course, it would still take 7 Iterations, or even possibly longer, if enough churn had happened in the process such that it actually made additional work for those involved!
In my conversation yesterday, the other person even talked about using simple line graphs to predict when the work remaining would hit zero, including accounting for features that have been added or removed. I think that sort of graphical representation can certainly help in such matters, as some people relate better to pictures than to words. In either case, though, your expectations are limited to an extrapolation of what's already happened, rather than relying on the time-honoured "... and then a miracle occurs" (as we all used to fall back on for those impossibly-hard university math exam proofs!).
In order to use this sort of technique, of course, you need development teams that can become fairly good at providing relative estimates (such as Story Points). That's no easy challenge, but it's also a big enough topic to warrant a separate blog post, and so I won't tackle it here!
Saturday, November 22, 2008
2nd AgileMan Book Nearing Completion
I'm now into the home stretch on More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), as I'm about to embark on a final read-through before beginning the self-publishing process. I'm still awaiting feedback from one of my reviewers, but that seems to be par for the course in this sort of arrangement (the same thing happened with the first book, even though the set of reviewers this time is completely different). Depending upon when it arrives, this final array of comments may - or may not! - end up being reflected in the finished product. As tempting as it might be to hold things up and wait, I'm keenly aware (after 22 years of doing various types of projects) that it could end up being a long delay. So onward and upward we go!
Vicki and I spent some time toward the end of the week (after we'd concluded our Project Management guest lectures) designing the covers for the 2nd book and the collected edition. The former will use a standard Lulu cover image, just like the 1st AgileMan book did, but I'm doing something special for The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile). And yes, that means I finally decided on a name for the collection! I've had 5 pre-orders placed for the bigger volume so far, and I think those generous souls will be amused, and maybe even pleased, to see what their book's cover looks like! I still have one more extra in mind for that edition that I'll probably take care of tomorrow.
If things go well this weekend, I hope to be placing an order for one copy of each of the two new books sometime very early in the week. With the American Thanksgiving holiday looming on the horizon, I imagine it may take more than the (now) standard two-week turnaround to get them, but I'll optimistically say that we might have the first proof copies in hand toward the end of the week of December 8th. If so, that would work out well for having the first big shipment arrive in time for early January distribution (an even luckier outcome would have the books show up before Christmas, but I don't see that as likely at this point).
Vicki and I spent some time toward the end of the week (after we'd concluded our Project Management guest lectures) designing the covers for the 2nd book and the collected edition. The former will use a standard Lulu cover image, just like the 1st AgileMan book did, but I'm doing something special for The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile). And yes, that means I finally decided on a name for the collection! I've had 5 pre-orders placed for the bigger volume so far, and I think those generous souls will be amused, and maybe even pleased, to see what their book's cover looks like! I still have one more extra in mind for that edition that I'll probably take care of tomorrow.
If things go well this weekend, I hope to be placing an order for one copy of each of the two new books sometime very early in the week. With the American Thanksgiving holiday looming on the horizon, I imagine it may take more than the (now) standard two-week turnaround to get them, but I'll optimistically say that we might have the first proof copies in hand toward the end of the week of December 8th. If so, that would work out well for having the first big shipment arrive in time for early January distribution (an even luckier outcome would have the books show up before Christmas, but I don't see that as likely at this point).
Thursday, November 20, 2008
Project Management In An Agile Environment
Last night, my wife Vicki and I traveled to our local university where we'd been invited to provide guest lectures to an evening class made up of third year Computer Science students, all of whom are enrolled in a course on Project Management.
Vicki wanted to go first, and so she took up the first forty-five minutes (of a 3-hour class) describing several of the jobs that she's had over the years that didn't, at first glance, appear to be related to Project Management... and yet were! The overall message of her talk was that there are more types of PM jobs out there than you might think, and the students seemed both interested and encouraged to hear that viewpoint! Although she was nervous going in, you'd never have known it to watch her... and she's now much more confident of her own ability to present on that topic.
My portion of the proceedings ended up taking close to 2 hours, in part because I had more material to cover (more on that in a moment) but also because I got asked a lot of questions! Although a handful of the inquiries were slightly skeptical in nature ("Could you really get a customer to approve spending money if you're not promising to deliver on time?"), most were more obviously related to them beginning to connect the dots. Which leads nicely into what my talk was on.
I broke it into 2 parts: What is Agile?, and What do PMs do in an Agile world? Because I had to assume that they had no knowledge of Agile prior to this (which turned out to be mostly accurate), it seemed critical to me when I was planning my lecture to give them a sufficient grounding in it before moving on to the Project Management angle. Based on how things proceeded, I'd say that was a wise choice.
Because it was a PM course, and I'd taken a look at their curriculum online, I decided that it was appropriate to frame Agile within the context of how common it is (and has been, for decades) for software projects to fail... a topic that I knew they were well familiar with. I provided some ideas of my own as to why the failure rate has always been so high, and then showed how - if done properly - Agile might address some of those factors. An actual PM from my former job was in the audience, and was nice enough to offer up some good observations to the class about areas where Agile had actually helped.
Before I moved into the second half of the material, I decided to get everyone up off their butts in a goofy little move where I had them stand up and give me an enthusiastic "but but but" as I launched into some of the more obvious reasons why Agile, as I'd described it up to that point, might seem like pure poison to a group of project management enthusiasts. You never know how that sort of thing is going to fly, but at least they played along and it kept them having to sit still for the entirety of the 2 hours!
I had 8 aspects of Project Management that I discussed, in turn, showing how a PM would add value in an Agile organization while doing the role in a manner different than what they might expect:
Both of our presentations appeared to go over very well, and we came away feeling as if we'd done a good job. Those of you who know people in the course are free to seek out differing opinions, though!
Vicki wanted to go first, and so she took up the first forty-five minutes (of a 3-hour class) describing several of the jobs that she's had over the years that didn't, at first glance, appear to be related to Project Management... and yet were! The overall message of her talk was that there are more types of PM jobs out there than you might think, and the students seemed both interested and encouraged to hear that viewpoint! Although she was nervous going in, you'd never have known it to watch her... and she's now much more confident of her own ability to present on that topic.
My portion of the proceedings ended up taking close to 2 hours, in part because I had more material to cover (more on that in a moment) but also because I got asked a lot of questions! Although a handful of the inquiries were slightly skeptical in nature ("Could you really get a customer to approve spending money if you're not promising to deliver on time?"), most were more obviously related to them beginning to connect the dots. Which leads nicely into what my talk was on.
I broke it into 2 parts: What is Agile?, and What do PMs do in an Agile world? Because I had to assume that they had no knowledge of Agile prior to this (which turned out to be mostly accurate), it seemed critical to me when I was planning my lecture to give them a sufficient grounding in it before moving on to the Project Management angle. Based on how things proceeded, I'd say that was a wise choice.
Because it was a PM course, and I'd taken a look at their curriculum online, I decided that it was appropriate to frame Agile within the context of how common it is (and has been, for decades) for software projects to fail... a topic that I knew they were well familiar with. I provided some ideas of my own as to why the failure rate has always been so high, and then showed how - if done properly - Agile might address some of those factors. An actual PM from my former job was in the audience, and was nice enough to offer up some good observations to the class about areas where Agile had actually helped.
Before I moved into the second half of the material, I decided to get everyone up off their butts in a goofy little move where I had them stand up and give me an enthusiastic "but but but" as I launched into some of the more obvious reasons why Agile, as I'd described it up to that point, might seem like pure poison to a group of project management enthusiasts. You never know how that sort of thing is going to fly, but at least they played along and it kept them having to sit still for the entirety of the 2 hours!
I had 8 aspects of Project Management that I discussed, in turn, showing how a PM would add value in an Agile organization while doing the role in a manner different than what they might expect:
- Requirements Gathering
- Task Estimation and Tracking
- Project Planning
- Personnel "Management"
- Quality Assurance
- Customer Relations
- Status Reporting & Milestones
- Scope Management
Both of our presentations appeared to go over very well, and we came away feeling as if we'd done a good job. Those of you who know people in the course are free to seek out differing opinions, though!
Monday, November 10, 2008
A Few Updates On The 2nd AgileMan Book
I've begun soliciting pre-orders for More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), starting with the list of people who bought or expressed interest in the 1st book. I've had nearly 20 positive responses so far and that's an encouraging result after just a couple of days!
Since I've decided to produce a collected edition of the two books, I'm also looking for pre-orders on that (I have 2 so far!). I've been working on the bonus material for it recently, making sure that anyone who buys the collection gets a little bit of extra, fun stuff beyond what's in the two regular editions. I'm still noodling over the sub-title for that book, to go along with The Complete Real-Life Adventures of AgileMan. Ideas I've had so far include:
The online prices at Lulu.com will be slightly higher than what I'm about to quote, but for in-person sales I'm expecting to charge $30 for the 2nd book and $45 for the collected edition (the latter of which is compared to $25 and $30, or $55 total, for the 2 books individually). For anyone in my neck of the woods who'd like to get a copy from the author himself on Launch Day (sometime in January 2009), please let me know now so that I can be sure to print enough copies!
While the actual writing of the books could at least conceivably be considered "work," I have to say that doing the various extras for them comes almost entirely under the category of "fun!" I had a great time dreaming up the comic strip captions that I used in The Real-Life Adventures of AgileMan (Lessons Learned in Going Agile), not to mention the minor thrill that I felt in creating the artwork in the first place! While I don't want to give too much away ahead of Launch Day '09, I will say that I'm having every bit as much fun this time around! I also tended to laugh out loud quite a bit as I came up with the contents of "AgileBoy's Glossary of Terms" for the 1st book, and I have an idea for something similar to use in the 2nd one. I really enjoy flexing my creative muscles on things like that, and if the people who buy the books get a kick out of them - as a few readers have told me they did - then all the better!
As for timing, the reviewers have until Nov 21st to get me their feedback (some of which has already come in) and then I hope to be starting the printing/publishing process shortly thereafter. I might manage to have the first print draft in my hands as early as the first week of December, if all of the stars line up and nothing goes wrong (I know: what are the chances?)
And that's where things stand today.
Since I've decided to produce a collected edition of the two books, I'm also looking for pre-orders on that (I have 2 so far!). I've been working on the bonus material for it recently, making sure that anyone who buys the collection gets a little bit of extra, fun stuff beyond what's in the two regular editions. I'm still noodling over the sub-title for that book, to go along with The Complete Real-Life Adventures of AgileMan. Ideas I've had so far include:
- (Two Years of Going Agile)
- (Two Years of Lessons Learned)
- (Two Years of Agile Lessons Learned)
The online prices at Lulu.com will be slightly higher than what I'm about to quote, but for in-person sales I'm expecting to charge $30 for the 2nd book and $45 for the collected edition (the latter of which is compared to $25 and $30, or $55 total, for the 2 books individually). For anyone in my neck of the woods who'd like to get a copy from the author himself on Launch Day (sometime in January 2009), please let me know now so that I can be sure to print enough copies!
While the actual writing of the books could at least conceivably be considered "work," I have to say that doing the various extras for them comes almost entirely under the category of "fun!" I had a great time dreaming up the comic strip captions that I used in The Real-Life Adventures of AgileMan (Lessons Learned in Going Agile), not to mention the minor thrill that I felt in creating the artwork in the first place! While I don't want to give too much away ahead of Launch Day '09, I will say that I'm having every bit as much fun this time around! I also tended to laugh out loud quite a bit as I came up with the contents of "AgileBoy's Glossary of Terms" for the 1st book, and I have an idea for something similar to use in the 2nd one. I really enjoy flexing my creative muscles on things like that, and if the people who buy the books get a kick out of them - as a few readers have told me they did - then all the better!
As for timing, the reviewers have until Nov 21st to get me their feedback (some of which has already come in) and then I hope to be starting the printing/publishing process shortly thereafter. I might manage to have the first print draft in my hands as early as the first week of December, if all of the stars line up and nothing goes wrong (I know: what are the chances?)
And that's where things stand today.
Thursday, November 6, 2008
One Lecture Down, One To Go
So I gave my first of two November Agile-related university lectures today. This was for a 2nd year Computer Science class (I'd mistakenly thought it was a 1st year course but was happy to learn my mistake!) and the goal of the presentation was to introduce about 20 - 30 young minds to the notion of doing development in an Agile organization.
In the fifty minutes that I had available to me, I covered the following:
I also put a push in for my former employer, telling them that they should all apply there when they graduate, if they want to stay and work in the same city where they attended university.
All in all, it was a very enjoyable and rewarding hour for me.
In the fifty minutes that I had available to me, I covered the following:
- Why do most software projects fail?
- Where did Agile come from?
- How are the Agile methodologies different than traditional (Waterfall) ones philosophically?
- How do Agile and Waterfall contrast each other more specifically?
- What does life in an Agile environment look like?
- Where might Waterfall be better, and where would Agile be more appropriate?
I also put a push in for my former employer, telling them that they should all apply there when they graduate, if they want to stay and work in the same city where they attended university.
All in all, it was a very enjoyable and rewarding hour for me.
Subscribe to:
Posts (Atom)
