Ken Schwaber, co-developer of Scrum, just gave an interesting talk at the Agile Project Leaders Network. Scrum, he explained, is not a methodology, but a framework for developing complex products.

The thing about complexity is that the more of it we have, the less likely it is that an external entity can dictate our way to success. There are just way too many variables and too many unknowns. Instead, what we need is a safe, supportive environment in which the team can generate ideas to dynamically deal with this complexity.

Scrum serves as a container for this environment. It’s not a methodology, it doesn’t tell us what to do (we still have to figure that part out). Instead, it exposes the weaknesses and, dare I say, failures in how we’re doing it.

Read More…..

Bob Martin’s Craftsmanship and Ethics presentation is now freely available. Think of it as a 45 minute video on the key principles of agile programming. Or, if you’d prefer, a tutorial on how to become a professional developer.

As developers, our main product is our code. And, so, to be considered professionals, we must craft our product (code) in a disciplined manner. We should always, for example, check in the code a little cleaner then we found it so that our systems are always improving (as opposed to degrading). However, in this industry, one of our biggest problems is that we almost always check it in worse then we found it. Uncle Bob jokes,

"It’s difficult to call ourselves professionals when our primary outcome is a huge, stinking mess!"

"How many times have you been significantly slowed down by bad code? Martin asks and we can be sure all programmer hands went up. "Then why did you write it?" he asks. There is laughter because of the truth in his question. We have all been slowed by bad code and yet, we continue to allow bad code to be written on our projects. And why? Because we didn’t have time to write it well?

We fool ourselves into thinking we can defer the problems of bad code until later. But the problem is that the slow down is not something that occurs months from now, it’s immediate. "How many of you have stared at code you wrote 2 hours ago and thought, ‘what the hell does that do?!’"

"Bad code is not something that slows someone else down months from now. It slows us down immediately. We must not write bad code. Period. This is a fundamental issue of professional behavior."

And, so, Uncle Bob presents us with a number of principles we can follow if we want to become professionals. In doing so, he offers justification behind many of the agile practices – iterative development, pair programming, TDD, avoiding Big Up Front Designs (only Uncle Bob likes to call them "Turgid, Viscous Architectures"). And, what I think is arguably one of the most important lessons of agile, which is that "the only way to go fast is to go well."

I went to see Johanna Rothman speak last week at the Software Quality Group of New England. I like Johanna because, as an expert in management, she can spot a line of management B.S. from a mile away.

I don’t have this skill. As a coder, my special power is spotting crappy code. If another developer shows me crappy code, I can describe 7 ways to Sunday why it’s a bad idea and 10 ways to fix it. But management B.S., that’s harder. Kind of like those game shows that turn seemingly intelligent folks into complete idiots… that’s pretty much the effect management B.S. has on me. I will actually sit there, stupefied, trying to reason some sense out of what they tell me. "Well, of course there’s no time for us to do things the right way. BUT, if you can just deliver this 6 month project in a 3 month period, that leaves you a whole 3 extra months to clean things up!" Uhhhhh.

So, I liked Johanna’s presentation, Schedule Games: Recognizing and Avoiding the Games We Play, because it makes me think there might be hope for us managerially-challenged developers yet.

Read More…..

Scott Ambler gave a great workshop yesterday on agile modeling. Agile? Modeling? Yep, you read that right. However, with agile, the emphasis of the models is to think about how the system should be developed, rather than to document how we’re going to develop it. Once you’ve modeled far enough that you know how to develop the system – don’t write about it, go develop it! He made a wonderful comment that I applauded:

Architects who don’t write code are only qualified to fetch coffee for those of us that do."

But, my favorite part of this session was where we each broke into groups to work through 3 development projects – each following a different process: Traditional, Mini-Waterfall (I can only hope by this he didn’t mean poor, misunderstood RUP), and, of course, Agile.

So, project 1 is Traditional. He has us each pick a role (stakeholder, analyst, designer, developer, tester). Analyst gets 1 minute to get the requirements from the stakeholder who then hands the designer and developer the specs. Designer and developer have 1 minute to develop what turns out to be a birthday card for dear old grandma, turning 84 this year, and then turn over to tester. Tester has 1 minute to compare against spec, gives us defects, and we have 1 minute to fix. Our team’s designer has an unnervingly hard time with this one, becoming visibly stressed out as Scott barks out "30 seconds left! 15! Okay, STOP!" Finally, stakeholder ranks us on how well we did. Let’s just call this one bad, very bad. A few teams actually got negative numbers.

Okay, round 2 and this time its mini-waterfalls. Now, analyst gathers requirements in 30 seconds, designer/developer develop, tester tests. Rinse, lather, repeat mini-waterfall 2 more times. It’s very chaotic and hectic , Scott screaming down over us the entire time, stomping his feet for extra emphasis. We barely have enough time to even understand the requirements (a wedding announcement, only, well, not quite – it’s actually a civil union — it mustn’t actually include the word "wedding," and it must include a poem , but… apparently not an offensive one (our team got points off for "there once was a man from nantucket…")), much less get them implemented. At end, stakeholders add up their rankings and we’ve done a little better then the last time, but only just barely.

And now, finally, round 3 and we’re on agile. This time, forget handing things over the wall from one discipline to the next. This time we have 2 minutes to work together as a team, which includes our stakeholder, to develop a card. This one thanking the SD Best Practices conference organizer for a great conference. Well, this card is by far our best one – we actually have time to breath and communicate and so we can come up with some cool details to add and even get them implemented – pictures, borders, a list of what we enjoyed about the conference, personal signatures of attendees. Stakeholder is involved every step of the way helping us understand what will improve it. Needless to say, ratings come in and all of the teams scores spike. Much happier customers.

So, what was interesting here is that we actually got less time to work on each subsequent project (from traditional to mini-waterfalls to agile) and yet, each subsequent project was more successful. Our team’s designer — you remember, the one who had such an adverse reaction to the traditional project — makes what I thought was the most insightful comment of the class (well, okay, maybe 2nd to the coffee fetching architect one):

"The agile project felt less rushed. It was more fun and relaxed"

And it was. We were laughing and having fun and innovating. Scott talked a lot about how our traditional software  development processes have been about how the academics think we should work, rather than how we really do think and work. The agile project definitely felt like it jived with the creative process.