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.