Some think Agile is all seat-of-your-pants. That’s not true at all. Agile requires knowing where you are right now and what you need to do in the near future; it just doesn’t put a lot of faith in guesses where you’ll be 8 months from now.
The various forms of Agile all contain a set of practices to follow and others to stay away from, each with their strengths and weaknesses. Successful implementation of Agile requires selecting and implementing practices that complement and support each other, covering all required needs without duplication (which is where a good deal of the efficiency comes in). It’s bad enough if you pick a set of practices that don’t support each other, but it’s much worse to chose the right practices but not implement them right. That’s because it can create a false sense of security. Read on…
I mentioned in this post that I got laid off from Metatomix back in October. I just landed a Java/J2EE Software Engineering job at Litle & Co.. I started Monday, but I wanted to wait a few days to “make sure it takes”. But it feels good, I’ve already checked in some code, and have adapted to their pair programming environment. I wrote a bit about them in this post while I was still researching them, and I liked what I found. I already have a taste for their flavor of Kool-Aid, having done Agile and pair programming before, and similar work in similar technologies. This has all the makings of a good, long, run.
First, a little fun. I found this survey asking just that question, but in a humorous way. Here are the results, which were presented at the Agile 2008 conference in Toronto. I also found (through LinkedIn) a post on Peter DeYoe’s blog with a humorous job posting for a Scrum Master.
Now for a real live case study. In my job hunting, I discovered this article by Damon Pool on Litle & Co. The reason I like this story so much is that not only did the push for Agile come from the top, but they started out that way. They didn’t adopt Agile, they were born with it. That eliminates a lot of problems that come along with trying to adopt Agile later on:
Read on…
I fell upon this article on the Methods & Tools website, a free software development magazine on software development and software engineering. The author is Anna Forss. She lives in Sweden, and her English is not perfect, but the article’s content is so strong, it’s worth the read. I recommend this article to anyone who wants to get a feel for what Scrum is, especially if you’re not a Software person.
The article starts out with an overview of the heart of Scrum, and how it doesn’t tell you how to develop your software per se. It tells you how to organize and communicate, but it doesn’t cover anything like unit testing or pair programming. You can combine Scrum with other practices effectively.
The main part of the article is about the roles people play in Scrum, in particular the Product Owner and the Scrum Master. Anna is a Product Owner (she doesn’t do any Software Engineering herself), and this part of the article implores the non-Software people in Scrum-using companies to take the time to learn it better, so they can be more effective in interfacing with the developers. Since I travel mostly with other Software Engineers, I hadn’t really heard about Scrum from the other side very much, and she makes a strong case for selecting the people to fill these two roles very carefully. A good Scrum team can get by with an OK Scrum Master, but a Product Owner that doesn’t do their job right will surely kill a project. She also addresses why the two roles shouldn’t be filled by the same people.
Anna Forss has a blog here (I almost want to publish some articles as RDF Triples). Her own blog has some great posts, like this one on The Business Value Of Boring Stuff and What Can We Learn From Coffee?. She’s also the author of Confessions of a Serial Product Owner. My only complaint is that her blog is on Windows Live, and I’ll be damned if I’m going to get a Windows Live ID so I can post comments on her blog or subscribe to it.
One of the many ways in which I am weird is that I love pair programming (two Software Engineers working together on the same computer). I’m a social animal, and I have the self-confidence to appreciate corrections couched as constructive criticism. But many Software engineers hate it because they feel they’re being judged constantly. And of course a lot of Software Engineers are introverts or have poor social skills. Or just like a little breathing room.
At my last company, I was instrumental at rolling out Agile on selected projects (because I believe in using the right tools for the job, and because Agile was not right for every project). My current employer, alas, is nowhere near ready for Agile. We’re trying to make some major changes to a product that affect the Flex front end, the Java back end, the XML and XSLT documents that hold and transform some of the data, and the databases. All those components need to dance together, or someone’s toes are going to get stepped on. But there’s no one person with all those skills, and certainly not enough time for one resource to do it all.
So here’s what we’ve been doing; My partner in crime (let’s call him E. He hates that.) and I are working physically side by side, but not together on the same thing. While E’s flexing the Flex and pouring the Java it talks to, I’m torturing the data till it sings, and pouring the Java that manages the data. But when either of us has a question on how something should be working (E may have questions about what’s in the data to help determine the expected results, or I may have questions on how a particular query is formed or the results processed), we’re right there to point at things on our screen. The fact that we’re working on two different computers isn’t a problem because we’re both syncing regularly with the version control system.
Clearly this is not pair programming, because we’re both working on different things most of the time. But there’s something different going on than if we were both sitting in our own desks. The barriers to communication are very low, and we can point out stuff right on our screens because they are next to each other. It’s a great balance of supporting each other while still doing our own thing. I don’t know if there’s a real name for what we were doing, so I decided to call it Co-Programming.
Title: Ken Schwaber on “Flaccid Scrum – A New Pandemic?”
When: Thursday, 06/18/09 06:00 PM – 09:00 PM
Where: MIT Building 26, Room 100, Cambridge, MA – Cambridge
Cost: Free
Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects.
Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn’t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint.
Ok, that sounds like like a pretty obscure line. But that’s kinda the point. This article from Agile Observations from the Trenches blog. Yeah, it’s an article about Agile software development. But it’s really about accomplishing any goal.
It’s really worth reading the article, but here’s what that title is about: Sometimes you need to accomplish task Foo, but then you realize you first need to accomplish task Bar, and then before Bar you need to do task Baz, and so on. It’s easy to lose sight of the original goal, and then you’re really in trouble.
I got a link to this post from the Agile Alliance LinkedIn group. Yes, it’s an article about Agile software development. I love Agile (and rolled out Agile practices at my previous employer). It’s about people who go through the motions of Agile without really doing it, let alone understanding it.
If you’re not into Agile, though, the whole cargo cult meme is fascinating, and worth reading about.
Title: A Jet Engine On Your Pinto: When HyperSpeed Agile Teams Pull A Slow Organization
When: May 28 06:00 PM – 08:30 PM
Where: Pizzeria Uno – Newton, MA
Cost: Free, though donation toward food cost is welcome
Parking: Garage (entrance off Bacon St.) parking is free with validation from Uno’s
If you piloted an agile team that was successful, you might start a few more. If they were successful, you might then initiate a push to convert the whole company as soon as possible. One company did just that – started forty agile teams, each one delivering impressive results. But it strained the organization so badly that the whole agile program was scrapped. They are not alone – others have experienced this. It’s like installing a jet engine on an ordinary car; the engine will go fast but will tear the car apart. Unless you add the right support structures! We will examine what these structures are for companies on their agile journey.
Agile Bazaar is an ACM chapter and an Agile Alliance affiliate. If you’re into Agile/Scrum/XP, it’s a great organization that has great meeting topics, and they welcome new ideas and topics. Here’s the info page for the event.
In this post, I talked about the upcoming Deep Agile 2009 event. Apparently there was some confusion about the “hardship discount”:
Are you unemployed? About to be? Hardship discounts are available for Deep Agile 2009 for those who wish to learn about modern embedded software development techniques and to network.
“Due to strong sponsorship and great speakers, our Deep Agile event for April 25-26 has passed the “break even” point. As a community based non-profit professional group we can now afford to help more people attend this first of its kind event. In light of the current economic situation, we are offering discounted hardship tickets, priced at $75.00 for those who are unemployed, about to become unemployed, or who have some similarly difficult circumstance. Don’t wait – it’s first-come-first-served and seats are limited. Please contact us via this link and include “hardship request” in the subject field to request a hardship discount. Continental breakfasts, lunches, and Saturday dinner are included in the price. (Note that Saturday dinner seats are limited and will soon be gone.)“
Just to make it perfectly clear, this means that the entire ticket price is $75. It’s not a $75 discount. Woot!
Sorry for posting so much about this event, but I think it’s going to be a good one, and I’m all about helping the unemployed.