My issue with this, which I asked her about in the Q&A at the end of the talk, was that even if something is a plank road technology and it gets replaced, you can’t skip the plank road and go right to the next step in the evolution of the technology. You need the failures and intermediate steps to learn from and provide the investment for the next step. The lessons learned from the plank roads helped engineer the next roads. The people who invested in that road probably didn’t go invest in farms or something, I’m sure some of them got involved in the next road technology. The plank roads did help immensely and they planted the idea of something better than dirt roads in people’s minds. When I questioned her about this, she seemed to agree with me that you need the intermediate technology which kind of invalidates the plank road metaphor as she used it. To me the plank road is like the dot-com bubble. Yes, people were hurt financially and companies went out of business due to many, many practices I can’t get into. But in the end, some people did get rich and some companies and infrastructure came out of it. A lot of people who made their money in the bubble went on to build really cool things, such as Doug Kaye of IT Conversations and Ev Williams of Twitter. In addition, a lot of people learned a lot in programming and systems design in that time that is now becoming very valuable.

The point of this is that you have to be willing to learn from failures and not just sweep them under the rug. “Fail faster” is one of my favorite sayings. If you invested in a plank road you can’t just ignore it and pretend it didn’t happen. Take what you can from it. Sometimes you won’t even know what you learned until you do the next thing. I don’t think Agile is a plank road no matter how you look at it, but even if it somehow is, we’ve learned a heck of a lot and the practice and profession of programming will never be the same. That’s a success to me.

I’ve published my notes from the Agile2008 conference on Evernote. My handwriting is poor in these notes but the searching of the images that Evernote provides works on some things. If you’re interested in a particular session, try searching for it. Even if you don’t find it, the interface is pretty good for just scrolling through. Hopefully they’re useful!

The other news is that the Idea Propulsion Lab hardware hacker club I founded is going to be featured in the Weekly Alibi paper here in Albuquerque. I think the issue with the club in it is going to be out tomorrow (8/26). A photographer was here yesterday taking pictures of me pretending to solder and of some of the stuff I’ve built. I’m one of the least photogenic humans around so hopefully it’ll turn out okay.

My friends were joking around that I was going to need a PR person to handle my media before too much longer. :)

This is the first of a couple of posts on what I’ve learned about how we’re doing (and not doing, as I’ve learned) Scrum on a big project at my work. Going to the Agile2008 conference and reading Mike Cohn’s Agile Estimating and Planning have really helped me understand how we got into the predicament we’re now in, with a late project and diminished team credibility with our upper management. Like most of the posts on this site, I’m probably going to ramble since I’m really just trying to write this down to help myself think it through. I do hope it’s useful and informative though. I’ll probably have more posts about some of these points later to flesh out my thoughts (including the importance of upper management buy-in, Agile on integration/upgrade projects, and others), As always, I’d love to hear any comments you have below.

We were brought Scrum by the vendor of the new billing system we were integrating. They use it internally and taught us about the practices. Immediately, it was a hit. We all liked the iterations, taking on tasks, demos, etc. Except the day-long planning meetings (we were doing 4 week iterations and have ~10 people on the team so that’s a lot of estimating and assigning) we liked the whole process. I had complaints very early about the seeming lack of involvement from upper management but we dismissed it at the time, thinking they would come on board later. I gave a presentation at one of the demos about Scrum, having been told that some of our senior management team would be there but they weren’t. The project seemed like it was going along fine though, so we just kept going.

The first big non-Scrum thing we did was we had an enforced deadline given to us by senior management based on a planning spreadsheet the vendor did. At the beginning, we thought we could meet that deadline so we didn’t think about it. Bad idea. Since the vendor had brought Scrum to us, and had people in our office working with us, we figured we were doing everything right. The other huge non-Scrum thing we didn’t know about, however, was the practice of looking at our velocity and reexamining the end-point of the project. That, of course, is a big deal and now we’re paying the price. We just kept adding stuff into the project and iterating, without knowing that we should be taking much harder looks at the backlog and the amount of work remaining.

If we had known about using velocity to estimate the amount of work remaining, we would have known how in trouble we were. Our velocity was very consistent month to month but we never used that knowledge for anything. The result is that our deadline came and we had to get an extension but it was another arbitrary number, not based on our velocity or the amount of real work remaining. That deadline also came and went, and we’re about to get another extension. The difference with this last extension is that now I know what we should have been doing all along and I’ll make my voice heard.

Now, I can’t blame the slippage of deadlines on any one thing, which makes looking back much harder. We had to deal with literally the worst software vendor I’ve ever heard of, let alone worked with. The less said about them, the better for my blood pressure. But they did contribute to the slips immensely (and still are, so at least they’re consistent). Another thing is that it turns out converting 15 years worth of financial data from an old system to a modern one is really, really, difficult. So that took longer than expected. And we had to implement a large piece of functionality on our own that the vendor should have done most of. That sucked up probably 4 full months of our most experienced programmer’s time when the vendor told us it would be 2 weeks of work.

But taking that into account, almost certainly would have still taken until now to finish if we had known about the full Scrum processes we weren’t doing. The difference is that our management would have known where we were the whole time and we could have taken a different tack in prioritizing features. (One problem I’ve had is finding help on implementing Agile in integration / upgrade projects. Most of the literature is on new development, which I’m planning a post on for later.) Part of the whole point of Agile is making sure people aren’t surprised and we’ve now surprised our management more than once. And I can’t say it’s all their fault for not coming to the demo either since we didn’t have the data we needed to be showing them. We also didn’t start taking things off the backlog for inclusion in the first release until very recently. Partly because in an upgrade of a billing system there doesn’t seem to be much that can be left out until you really start looking. Since we didn’t think we had to, we weren’t as brutal about taking things out as we clearly should have been.

I’m calling this part of what I think will be a couple of posts on this project Doing 80% because I think we were doing 80% of Scrum. We were doing iterations, estimating hours, assigning tasks, and demos so we thought we were doing just fine. If we had been skipping those fundamentals, we would have known something was wrong. The danger is that since we were doing 80% and we were new to Agile, we thought everything was fine. Now I see that if we had been doing that other 20% of planning and estimating and reexamining the backlog it would have helped tremendously. Now for our next projects I know what we need to be doing so hopefully things will go a lot smoother. Now we have our own knowledge and won’t be reliant on the vendor to tell us if we’re doing things correctly.

More on my first agile project later. Thanks for reading.

There’s a website for CSS and HTML called “Don’t meet your heroes“, which has always been one of my favorite website names. This podcast always makes me think of that phrase. I really like Coding Horror, which is Jeff Atwood’s blog about programming. It’s great, even though I don’t always agree with him. But now he’s doing this podcast about a website he’s building called StackOverflow and listening to him, he keeps losing cred with me. He’s a Windows programmer, which earlier in my life I equated with brain damage. I’m a lot less judgmental now, especially since my wife has done a lot of Windows programming, but I’m still biased against Windows if I’m honest. The problem with Jeff on this podcast, especially this particular episode which is the “Developer Episode” where they talk nuts & bolts about StackOverflow, is that the things he’s discovering are really old hat to anyone who has done development on Linux (or anywhere but Windows I imagine). I can’t tell if the Windows development environment is really stunted from basically having one IDE, Visual Studio, and the related tools from MS, or if he and his team don’t pay much attention to programming practice.

They’re really surprised about continuous integration using Cruise Control versus the MS tool which apparently requires you to install Visual Studio on your server (!!!). They all seem to be new to the very idea of MVC (model, view, controller) programming, which has been pretty standard for years, because MS is just now coming out with their approved MVC product/environment. Jeff talks about LINQ like it’s the only option for not putting SQL directly in your code, despite various ORM tools and similar things being around for quite some time. They do use nUnit, which is the .Net port of jUnit, so they do have that going for them.

But don’t even get me started on Jeff’s decision that writing tests somehow makes you less agile. Yeah, not having tests lets you write crappy code much faster. Great!

Now, I have no doubt that all 3 of the guys on the StackOverflow team are much, much better programmers than I am. Even without seeing their code I would venture to say I know they’re better than me. No slight to them personally, at all. At all. But I can’t tell if the lack of knowledge of what I consider basic standards is them or their environment and that’s bad. I guess if I’m a Windows shop and I come up against somebody who has never heard of MVC, that’ll be fine since I won’t have heard of it either. But if I’m used to people who think MVC and continuous integration and unit tests are given parts of good projects and I come up against people who only have experience with Windows stuff, they won’t seem like they’re as experienced. And I’ll have missed out on good programmers, most likely.

On the other hand, Joel Spolsky is a Windows programmer and well, he’s Joel freaking Spolsky. He and many others are probably existence proofs that I have no idea what I’m talking about.

Are Windows programmers missing out on so much good stuff because they don’t pay attention to the tools used by other programmers? Java has a rich environment of tools by many, many different parties. I have 2 different static code analyzers (just for an example of a totally niche product) in Eclipse (1 of 4 really nice IDEs for Java) telling me about bugs in my code. Does Visual Studio have anything like that? I can think of 3 different continuous integration tools. It seems like if they paid attention to other programmers’ tools, MS would have to provide more than they do or the environment of 3rd party tools would be a lot stronger.

I’m not sure what the point is of this post, I’m just trying to figure out how somebody who obviously knows a ton about programming misses out on so much of what I (and others) would consider very basic ideas. I don’t think it’s just that there’s stuff about .Net programming that I’m missing out on. I read a lot about programming in a lot of different languages and it really just seems like the Windows development ecosystem is missing a lot of things because Microsoft hasn’t put whatever-it-is out in a box with Visual Studio. Jeff even talks about using some 3rd party code diff tool, for pete’s sake. How can you use an editor to work on code with other people without a diff tool and source control built in?! I still like Jeff and Coding Horror and I’m sure I’ll love StackOverflow from what I’ve seen of it. I guess I’m just going to have to accept that different environments can produce different kinds of programmers. Smalltalk people are probably laughing their asses off at my I consider my toolset so it’s all relative.

If you’re a Windows programmer, I’d love to hear more about working in that environment in the comments. Thanks in advance.

• High defect rate
• Distractions that force you out of the zone
• Low focus and discipline
• Low incentive to adhere to common practices
• Slow learning

Pair programming is one of the practices I’ve always had a hard time wrapping my mind around. I’ve been told a bunch of times how great it is, and I’ve even been party to the benefits in small amounts as debug sessions and the like, but I can’t get to the point of accepting that I should be doing it all the time. One of the commentors on the post basically gives all the standard complaints and I hope the author or somebody gives a rebuttal. At the conference a lot of people stated pair programming as a given good, “proven” to work. I haven’t seen that proof but I’d like to find it.

Outside the world of fanboys, people realize that most everything available sucks in one way or another, and most everything has a positive side, too. And while we all have our favorite technologies, most of us don't obsessively troll every thread that discusses them.

For example, Haskell on Linux is my language/platform combination of choice, but I am occasionally called on to write large amounts of Visual Basic at work on Windows systems. And while I don't like doing it, and I could give you a laundry list of things I hate about VB, there are also things about it that don't suck. Having an opinion and a preference doesn't mean that it can't be a nuanced opinion or preference.

I think the rest of reddit is frankly just sick and tired of hearing all about how much you hate technology X. Really, we don't give a shit.

808140 comments on Mono isn’t just for Apes.

One of the most promising things about the Agile2008 conference was the idea that Scrum and XP are really just on a spectrum of Agile methodologies, not completely black-and-white different things. I think what this Reddit user says is true for discussion Agile as well. Both camps need to get over themselves and realize they’re really just one camp.

Kim and I are going to speak on our experiences at Agile2008 at the meeting of the Agile New Mexico group next week and this is one of the topics I’ll be talking about. I think it’s great and since it was a big theme of Bob Martin’s keynote, I think people will actually listen.

Since the email is pretty long, click Read More to read it if you’re interested.

As you might know, I went to the international Agile conference last week and I came back with a bunch of ideas (I can already see some of you rolling your eyes but bear with me J).

One of the things I’ve been thinking about for awhile and about which I had a lot of ideas about at the conference was how we can continue to take advantage of the benefits of the Scrum methodology we used on BillingCenter. So this is my idea and I’d like to open up some discussion about how we can carry on being Agile long-term. Like I say, these are just some ideas and I hope we can all talk this stuff over. I really believe in this stuff and from what I saw at the conference, it’s helped a lot of companies. I’d hate to lose the benefits of this methodology just because we’re not doing BillingCenter any more.

The core of the plan is the idea of having a single backlog for all the work that we need to do as a team (by which I mean the programmers since this style of work fits our stuff best but of course if you guys think it would benefit the administration side there’s no reason why it couldn’t be used). This means everything goes on a single list and gets estimated for difficulty by the team and prioritized. The backlog would be based on Jiras and include new work as well. Then, we do 2-week iterations where we take things from the backlog based on the priority and difficulty estimates and work on that stuff. Anything new gets estimated and prioritized onto the backlog (not including emergency stuff, obviously). This way our customers (the rest of the company) knows what we’re working on right now and has insight into what we will be working on. Obviously everybody thinks their stuff is super important but when everybody can see how much work we think something will take, we can make rational decisions about priority and everything is out in the open. This also prevents us from jumping around on a million different tasks, which has tons of benefits. And since we’re iterating every 2 weeks, we’ll be delivering working stuff into our customers hands and getting feedback much quicker.

Since everything goes onto a single backlog, we can mix projects. One iteration maybe 3 people work on tasks related to Project X and the others work on tasks from Projects A, B, and C. Then if we need everybody on Project X for a time, the iterations are only 2 weeks so people aren’t waiting around forever for their stuff to get done. Or one person can take an iteration break from working on Project X to get something done in Project B. It’s very flexible and since we have so many different types of projects and tasks going on around here, flexibility is key.

I’m looking into a couple of tools (like Scrumworks but much, much better; believe me) that help track projects and tasks. I hope to have something to show everybody soon and see if the tools are something everybody thinks we should use.

All in all, the structure and openness provided by taking on an agile environment has a ton of benefits, not only for IT but for the company who relies on us to get their stuff done. Over and over at the conference I heard not only from programmers but project managers, the business people, and customers who all said going agile was the best thing they could have done. I’d love to talk more about this and if you have questions about it, I’m all ears.

If you’ve made it all the way down here, thanks for reading.

I’m definitely going to try to attend this, should be fun. Maybe I’ll try to present something about my experiences with Agile. hmmm…

For some great writeups on sessions (the kind of writeups I wish I was going to be doing) check out Gojko Adzic’s blog http://gojko.net. I met him at the conference and he’s a very sharp guy with a great blog.

My first big takeaway is the focus on engineering practices. We do Scrum at work which doesn’t set out any specific coding practices. At first I thought this was great, to leave the programmers alone to work as they wanted. And to be sure, I’m not advocating forcing a lot of practices on people where they might not fit. But overall, I’ve come around to thinking that a team should at least talk about doing things like test-first development, pair programming, etc. The benefits have been shown, it’s just a matter now of not doing something just to be doing it, but because it makes a real benefit. We’re going to start talking about these things soon.

The other thing I came away with was that we’re doing a pretty darn good job of being agile on my team. A lot of people I spoke to and heard have big problems with team dynamics and following the agile practices. We’re probably 80% of the way there but I think doing another 10-15% of agile methods would help us big time.

I’m going to have a lot of things to writeup and talk to my work about and I think we’ll be able to do a lot of agile things that will help us and the company out. We’re lucky that our Director is a programmer and knows to let us do things if we think they’ll help. We don’t have the kind of pushback from management that a lot of teams seem to have, which is great.

More later!