Before Scrum I believed that agile development meant two developers sit in the same cube, debate programming techniques and implementations for hours, and write 1 line of code together. Then I read Agile Software Development With Scrum. Just like most new-comers to agile I was thrilled to have someone layout the rules for doing agile. Create sprints in a few week intervals, hold daily stand-up meetings, identify chickens and pigs. I loved it. It was the rules to the game that I was missing.

But as we tried to implement it for our projects we immediately ran into the wall of waterfall. The rest of the business was used to doing step 1 before step 2, not concentrating on steps 3 through 8. Frustrated, I discussed the adoption problem with a “Process Consultant” helping us out at the time. He gave me the best advice I’d received about agile: It doesn’t need to be perfect. We went on to talk about how to fit Scrum into our process. Sure, we weren’t going to be able to apply all the rules, but we could apply some to help control the chaos of the business. In the end our projects began hitting their time-lines for the first time in history, quality of code was up, and our estimates were coming in much closer to actual.

I bring this up because I think there’s this feeling that you need to follow all the rules to Scrum to “be agile”. I hear a lot of chatter about clients asking for official Scrum Masters. I can understand if they have a rigid, predefined agile process already in place, but some of these clients haven’t the foggiest idea what agile means or why they need Scrum.

In the end, I worry that by putting up barriers around agile by using Scrum might prove to be a hindrance to the process. Thereby being counterproductive to the desired result of delivering quality products in a respectable time.

12:28:59 PM negatedcoho: Hello…
12:29:13 PM Jason Motylinski: Hey, are you the same guy from yesterday?
12:29:30 PM Jason Motylinski: you owe me 5 bucks!
12:29:40 PM negatedcoho: hi
12:29:48 PM Jason Motylinski: wtf? when do I get my money?
12:30:24 PM negatedcoho: ? what r u talking about
12:30:34 PM Jason Motylinski: whatrutalkingabout?
12:30:49 PM negatedcoho: bye
12:30:55 PM Jason Motylinski: hey, you talked with me.
12:31:03 PM Jason Motylinski: you can’t just leave.
12:31:08 PM negatedcoho: no you immed me first
12:31:13 PM Jason Motylinski: no I didn’t.
12:31:20 PM negatedcoho: whatever
12:31:32 PM Jason Motylinski: nice…real nice.
12:31:34 PM Jason Motylinski: have a good life.

I still continue to receive random messages from “coho”, though. Sometimes it negatedcoho, or weirdcoho, but the IM names always end in “coho”.

I finally came across an explanation for the weird messages on Wikipedia. Apparently it’s a bot which  randomly connects two people on IM called TheGreatHatsby.

From Wikipedia:

Responses from users are forwarded by the bot to another one of the users similarly contacted. These two users are paired up, and any message which one of them sends to the bot will be forwarded to the other. Thus, if neither of the users is aware of TheGreatHatsby, they will each think that the other user contacted them, and that the other user’s screen name is the bot’s screen name.

Interesting concept. I wish it was an opt-in service though. If I had chosen to participate I might appreciate it a bit more. Notice in the article it mentions the ability to opt out using the command “$optout”.

I’ve had the good fortune of working on two stellar projects in the last year. One involved creating a proof-of-concept application using all the bells and whistles in .Net 3.5. It included WCF, WPF, and WF. My second, and current project, is a highly scalable SOA architecture. My job has been to come in and expand it intellegently. In both situations the clients have had extreme desires to push the limits of not only their software but of the .Net framework itself.

Case in point, on my current project I was given the task of interfacing with a printing vendor. We needed to ship them documents on a daily basis. I was told to use an existing pattern/system of windows services to send the documents and web services to receive the documents. This pair of software would be installed on both ends making it easy for us to send and receive documents on demand.

In theory it’s a very simple concept. We failed to anticipate, though, was the complexities of dealing with a third party’s server environment. After struggling through configuration after configuration errors (no errors were in the software, mind you) I asked the printing vendor how they typically receive documents from other businesses. “Oh, FTP, ” they replied. I asked how many of their customers require custom software installations like we were. “Zero”. We re-invented the wheel.

The problem now with having our own “wheel” is now supporting our “wheel”. We are now on the hook for any issues that may come with our process. If we would have gone with their standard process of using FTP we could have gained so much more in managability, logging, exception handling, etc…Which our “wheel” could have if we had the time and money to add such features.