So I've been getting beat up a bit on the extremeprogramming mailing list. Part of the issue is that I often don't know what the hell I'm talking about; even when I do I don't express it as well as I should.
I post questions or statements about what I want to try, and I get back responses that I'm trying the wrong thing or going about it in the wrong way. And that what I need is to hire a coach, get some assessment, and have some more conversations.
I have to admit it was getting on my nerves. I can read, the practices are not super complex - what the hell?
Anyway, on the theory that if a lot of people that have been in the field are saying the same thing and seem to agree with each other, I should listen, I called Ron Jeffries to talk for a bit this morning. We talked about some of the things I had posted and some other stuff but rather than getting any kind of prescription I got nuggets of wisdom - some of which have been percolating all day.
As an example I had the idea that I should require a set of XP practices and provide training in those practices. On the list I got a lot of feedback that requiring practices is a horrible idea. I was confused by this - I'm talking about having people do the stuff you guys say work and I'm getting a bunch of noise back - again, what the hell? Am I supposed to just hope that people will do the right thing? Who's gonna feed my kids when I get fired?
Ron cleared the whole thing up for me in like one paragraph of talking. I'm paraphrasing here but he essentially said that I could require running software that passes my tests. In other writings he calls that Running Tested Features (RTF.) Anyway, having a requirement for RTF, developers might look for easier ways to satisfy the requirement and the proverbial we could suggest practices and provide training/coaching.
Ding Ding Ding - that makes perfect sense to me. It clears up many of the responses I got on the list, and it completely illustrates why I should indeed sit at the feet of the masters. I could perfect every practice and make people do them, but still not get the RTF I need.
So now I'm going back to see about shaking budget loose to bring Ron and Chet in for a few days of master wisdom - wish me luck
Thanks for reading - Mike
Thursday, September 25, 2008
Saturday, September 20, 2008
Story size - and Motorcycle rides
I ride bikes in three distinct landscapes, and where I'm riding has a lot to do with how I approach the activity.
On a road race track I know the profile of every corner, the available traction, and all the landmarks. I can fully commit to my line and string the curves together so that the exit from one corner sets me up for the entrance to the next. I'm going to see the same sets of corners every minute or two, I know exactly what I'm going to do well in advance, and I can think in big chunks of track - I have to do this to be fast. I can clearly see where I am going and plan every action along the way before I even get on the bike. Then it's just a matter of improving my execution through practice and repetition.
A semi-equivalent software development system is making cookie cutter websites with branding. The customer just chooses from a menu of re-usable functionality and most of the discussion revolves around the branding elements. The analogy with track riding breaks down though because riding a motorcycle at speed around a race track is just a bit more engaging then churning out cookie cutter websites.
Street riding - even on a familiar route is a whole different game. There are cars doing all sorts of seemingly random stuff, gravel on the road that was clean yesterday, driveways, pedestrians, and who knows what else. On the street it makes no sense to commit all your traction to a corner, or to be too attached to the exact path of travel too far in advance. You want to look a far ahead as possible, watching for the telltale signs of trouble so you can adapt your approach to the changing conditions.
This is the sort of environment that most corporate software development takes place in. There are regulatory changes, market conditions, new internal customers with their own ideas for improving things, and always budget constraints. The rules are very similar to riding in traffic. You know where you want to end up and you know pretty much what route to take but you must be ready to adapt to the changing conditions.
Finally there is off road riding. This is incredibly interesting and challenging. Often I don't know where the next bit of trail is going, or what the surface will be like. I can only plan very short intervals of the future and even those plans are subject to change with very little notice when the trail takes an unexpected turn ,or traction disappears in the middle of a challenging hill. I fall down a lot when riding offroad.
New product development is a lot like riding off road - you're always inventing something new and there's no telling where you might be even in the near future. It's also very interesting, a lot of fun, and you might fall down from time to time.
It is exceedingly rare that I fall down on the track or the street and falling in either of those circumstances can be very expensive in financial and human terms because the typical track or street bike is very sophisticated and street bikes in particular are heavy. Off road I fall frequently, and really appreciate the light weight, easy maneuverability, and durability of my dual sport bike. It turns out that the lightweight and simplicity of the dual sport are great on the track and street too.
Agility makes riding on the track more pleasant by requiring less effort to execute my plan, it makes street riding safer by making it almost effortless to adjust to the changes I see ahead, and it's a whole lot easier to pick up when I fall offroad. Similarly, I think agile processes make life more pleasant, safer, and resilient in any area of software development too.
Thanks for reading - Mike
On a road race track I know the profile of every corner, the available traction, and all the landmarks. I can fully commit to my line and string the curves together so that the exit from one corner sets me up for the entrance to the next. I'm going to see the same sets of corners every minute or two, I know exactly what I'm going to do well in advance, and I can think in big chunks of track - I have to do this to be fast. I can clearly see where I am going and plan every action along the way before I even get on the bike. Then it's just a matter of improving my execution through practice and repetition.
A semi-equivalent software development system is making cookie cutter websites with branding. The customer just chooses from a menu of re-usable functionality and most of the discussion revolves around the branding elements. The analogy with track riding breaks down though because riding a motorcycle at speed around a race track is just a bit more engaging then churning out cookie cutter websites.
Street riding - even on a familiar route is a whole different game. There are cars doing all sorts of seemingly random stuff, gravel on the road that was clean yesterday, driveways, pedestrians, and who knows what else. On the street it makes no sense to commit all your traction to a corner, or to be too attached to the exact path of travel too far in advance. You want to look a far ahead as possible, watching for the telltale signs of trouble so you can adapt your approach to the changing conditions.
This is the sort of environment that most corporate software development takes place in. There are regulatory changes, market conditions, new internal customers with their own ideas for improving things, and always budget constraints. The rules are very similar to riding in traffic. You know where you want to end up and you know pretty much what route to take but you must be ready to adapt to the changing conditions.
Finally there is off road riding. This is incredibly interesting and challenging. Often I don't know where the next bit of trail is going, or what the surface will be like. I can only plan very short intervals of the future and even those plans are subject to change with very little notice when the trail takes an unexpected turn ,or traction disappears in the middle of a challenging hill. I fall down a lot when riding offroad.
New product development is a lot like riding off road - you're always inventing something new and there's no telling where you might be even in the near future. It's also very interesting, a lot of fun, and you might fall down from time to time.
It is exceedingly rare that I fall down on the track or the street and falling in either of those circumstances can be very expensive in financial and human terms because the typical track or street bike is very sophisticated and street bikes in particular are heavy. Off road I fall frequently, and really appreciate the light weight, easy maneuverability, and durability of my dual sport bike. It turns out that the lightweight and simplicity of the dual sport are great on the track and street too.
Agility makes riding on the track more pleasant by requiring less effort to execute my plan, it makes street riding safer by making it almost effortless to adjust to the changes I see ahead, and it's a whole lot easier to pick up when I fall offroad. Similarly, I think agile processes make life more pleasant, safer, and resilient in any area of software development too.
Thanks for reading - Mike
Friday, September 19, 2008
A little slow on the uptake
Sometimes we just want to invent stuff for ourselves. We often pay lip service to the idea of learning from the mistakes of others and profiting from lessons learned and work in the can; we might even believe it. But still we do our own thing, make our own mistakes and come to many of the same conclusions of those that have come before.
Over the last few weeks it has really come home to me how much I tend to think I am at least as smart as all those other guys, and that I can surely figure things out for myself. I still think it's true, but why would anybody want to live without delusions - especially delusions of grandeur?
Earlier in the year I wrote some articles on agile development and how great I think it is to be agile, with some examples of how things might be done. You can find them on my old blog if you care to.
The thing is though, I almost completely ignored extreme programming(XP) and Scrum.
XP because when Kent Beck's book first came out, the whole process just seemed kind of flaky and inappropriate for the kind of large organizations I was working in. I could see myself talking to an auditor and handing over stacks of 3x5 cards when asked for system requirements - as if. I was also somewhat turned off by the idea of pair programming - I do not want to sit shoulder to shoulder with anybody all day, not having to is one of the perks of IT work.
Scum because the name is asthetically unattractive, and at first glance it looks like a ripoff of XP without the good engineering practices. What's the point of that?
I was stupid. I should have been paying better attention because over the years while I've been thinking about process improvement, reducing the signal to noise ratio of system docs, and removing friction from people's lives; these guys have too. And they've been doing it in all sorts of settings as consultants and coaches. XP has matured, lessons have been learned, and practices have been improved. They've even done some studies showing gains from pair programming and TDD. It also turns out that Scrum is more than just a subset of XP - though the name still leaves a lot on the table of asthetics if you ask me.
A few weeks back I was invited to join a team of folks at work to explore moving to an iterative development process. We had bought a smaller company that had recently adopted Scrum and did not/does not want to go back. That gave me an opportunity to really look at Scrum which quickly led me to revisit XP as well.
I have been in a total immersion self study course - reading the websites, comparing the variations, joining the mailing lists to ask questions, and watching a bunch of video presentations on infoQ from many of the guys that started XP and Scrum. It turns out that I agree with almost everything with the possible exception of the sales pitch that includes things like 'add joy to the workplace.'
Not that I'm against creating a great place to work; but even I - raised mostly in the west by hippies - can see that the guys writing the checks are not all that concerned, even if they should be. I would rather see a sales pitch that talks about ROI and behaviors that lead to greater ROI in the long term. We all know that happy porogrammers will be productive so let's just talk about the corporate behaviors that lead to happy programmers in terms of the benefit to the bottom line, and leave the happiness argument out of it.
If, like me, you've been kinda ignoring XP and Scrum as something nice for small teams of folks that won't eat a good bar-b-que sandwich with a side of slaw; reconsider. Get out there and watch the videos, read the websites, subscribe to the mailing lists, and ask a lot of questions. I don't think we can tweak the old waterfall (dinosaur) method enough to survive the onslaught of the furry little XP critters.
Thanks for reading - Mike
Over the last few weeks it has really come home to me how much I tend to think I am at least as smart as all those other guys, and that I can surely figure things out for myself. I still think it's true, but why would anybody want to live without delusions - especially delusions of grandeur?
Earlier in the year I wrote some articles on agile development and how great I think it is to be agile, with some examples of how things might be done. You can find them on my old blog if you care to.
The thing is though, I almost completely ignored extreme programming(XP) and Scrum.
XP because when Kent Beck's book first came out, the whole process just seemed kind of flaky and inappropriate for the kind of large organizations I was working in. I could see myself talking to an auditor and handing over stacks of 3x5 cards when asked for system requirements - as if. I was also somewhat turned off by the idea of pair programming - I do not want to sit shoulder to shoulder with anybody all day, not having to is one of the perks of IT work.
Scum because the name is asthetically unattractive, and at first glance it looks like a ripoff of XP without the good engineering practices. What's the point of that?
I was stupid. I should have been paying better attention because over the years while I've been thinking about process improvement, reducing the signal to noise ratio of system docs, and removing friction from people's lives; these guys have too. And they've been doing it in all sorts of settings as consultants and coaches. XP has matured, lessons have been learned, and practices have been improved. They've even done some studies showing gains from pair programming and TDD. It also turns out that Scrum is more than just a subset of XP - though the name still leaves a lot on the table of asthetics if you ask me.
A few weeks back I was invited to join a team of folks at work to explore moving to an iterative development process. We had bought a smaller company that had recently adopted Scrum and did not/does not want to go back. That gave me an opportunity to really look at Scrum which quickly led me to revisit XP as well.
I have been in a total immersion self study course - reading the websites, comparing the variations, joining the mailing lists to ask questions, and watching a bunch of video presentations on infoQ from many of the guys that started XP and Scrum. It turns out that I agree with almost everything with the possible exception of the sales pitch that includes things like 'add joy to the workplace.'
Not that I'm against creating a great place to work; but even I - raised mostly in the west by hippies - can see that the guys writing the checks are not all that concerned, even if they should be. I would rather see a sales pitch that talks about ROI and behaviors that lead to greater ROI in the long term. We all know that happy porogrammers will be productive so let's just talk about the corporate behaviors that lead to happy programmers in terms of the benefit to the bottom line, and leave the happiness argument out of it.
If, like me, you've been kinda ignoring XP and Scrum as something nice for small teams of folks that won't eat a good bar-b-que sandwich with a side of slaw; reconsider. Get out there and watch the videos, read the websites, subscribe to the mailing lists, and ask a lot of questions. I don't think we can tweak the old waterfall (dinosaur) method enough to survive the onslaught of the furry little XP critters.
Thanks for reading - Mike
Tuesday, September 9, 2008
Reset the blog
So I wanted to move to blogger for a variety of reasons but moving all my old stuff over here turns out to be more work than I'm likely to do. But rather than continue my procrastination on writing I figured I would just tell you what's up and start writing again.
There's a lot of interesting - to me at least - stuff rattling around in my head and I'll be letting it run out onto this space much more frequently.
Thanks for reading - Mike
There's a lot of interesting - to me at least - stuff rattling around in my head and I'll be letting it run out onto this space much more frequently.
Thanks for reading - Mike
Subscribe to:
Posts (Atom)
