Blogger's Note: This post is part of an assignment for a digital media class I'm taking this semester. The assignment was meant to elicit our thoughts on the agile approach to programming. That is all. Breckenridge.Going from writing to programming feels like lolloping into uncharted territory – My “programming” knowledge is limited to recognizing HTML structure and being able to interpolate what it means by toggling between a HTML editor and a WYSIWY(don’t necessarily)G box. But I’ll be brave like my eight-year-old when he goes off the diving board into sixteen feet of water because he knows his Dad will be nearby to rescue him if he starts to flounder. (Y’all are my surrogate Dads on this one, of course.)
My initial sources: A Wikipedia entry on agile software development, and “Principles Behind the Agile Manifesto,” from the agilemanifesto.org website, used simply to gain a little background knowledge on the subject. A third source I found rather enlightening from a human performance perspective is a video/slide show presentation by Henrik Kniberg, A Sweden-based programmer and author who presented “Ten Ways to Fail in Scrum” at an agile programming conference in August. (This is, by the way, an excellent demonstration of how the web can produce documents that the outside world can’t. We get the video and in a separate screen beneath it, his slides, a most excellent way to present this information) This can be found at
www.infoq.com/presentations/Fail-Scrum-Henrik-Kniberg.
We’ve seen through our own experimentation that chunking is a tool that can be misused. Kniberg feels the same way about agile programming. I like his example: He depicts a lumberjack eschewing his ax for a chainsaw, because he’s been told it’s a better tool. So he uses it like an ax, chopping at the tree and lamenting that he gave up the ax because this new tool just isn’t working – not realizing, of course, that for the chainsaw to work, it has to be started.
Kniberg, of course, is an advocate of agile programming – preference on scrum. But he realizes, as he goes through his ten points of failure, that, like with any other tool, it’s the human performance that makes things work and makes things fail. Perhaps his presentation was most meaningful to me today because, over the weekend, I and others at a project I’m involved in spent a lot of time working through a massive communication failure and personality conflict that has led one of our team members to quit. Listening to Kniberg’s presentation (it’s an hour and a half long) really brought home the idea that while tools can help people get work done, getting that work done depends on how people use the tools and on if they actually can get along. I can see that, if I’m allowed to remove programming from the picture and apply the waterfall and agile techniques to project development as a whole, that we have team members who are working on one philosophy, while others firmly believe the other is better. I can see that agile’s emphasis on quick deliverables through several iterations would allow measurable progress for those who are impatient, and allow for a plan towards improvement for those who would rather wait longer for perfection. If we had taken this approach with the project I’m involved in, we might have avoided some trouble.
Listening to Kniberg’s presentation on failure made me feel better about my own failures – because I can see what we’re experiencing is not uncommon. Most striking are his discussions of teamwork (inability to escape fixed roles, inability to see past “well, I got my stuff done,” and the inability to implement different facets of a project in parallel) plus his discussion of “Mergophobia” – the inability of team members to define when they’re done, the fallacy that integration takes place at the end, rather than all along. These are the Achilles heels of the project I’m working on.
The biggest Achilles heel I can see in agile programming, though, is the emphasis on co-location. The team I work with is geographically dispersed – from Michigan to Texas to Utah to Idaho. Physically, the closest team members to me are 2 ½ hours away. Yes, everyone is instantly connectible via e-mail and telephone, but the crisis that led up to this weekend’s implosion stems from the misuse of e-mail to the point of name-calling and shrill chastisement to the complete disuse of the telephone. We have two team members who realize that phone communication – the best alternative we have now to face-to-face communication – is critical, but neither is willing to pick up the phone. They’ve also both shown an inability to disagree in an agreeable manner via e-mail.
I know conflict arises in face-to-face communication as well. But people are more apt to be communicative, cooperative and willing to settle differences amicably if they know they have to show up at the same physical office every day, week in, week out. I know some teams are able to accomplish such camaraderie in virtual offices; they accomplish this, I’m sure, by getting to know each other on a very intimate basis, but it ain’t working for us – because we have team members who are very alike but regard each other with enough disdain and derision that they’re blind to their similarities.
But off that tangent. I like the idea of agile programming offering fast deliverables within weeks or months, rather than longer periods of time. I like the pig and chicken notion in scrum – that the “pigs,” team members who are entirely committed to the project – have the most say, while the chickens – those whose input isn’t critical – don’t have as much pull. That, however, does have its own pitfalls, as the team has to clearly define what roles are mission critical and what roles aren’t before conflict arises, or else ka-boom.
The project I’ve mentioned has thusfar worked on the waterfall metaphor – and that has led to impatience and disruption from teams within the project, especially among those who’d like to see a product much sooner than we’re accomplishing now. That difference in production philosophy, combined with the communication breakdown has been highly disruptive.
I suppose the purpose of this post is to say:
1) Tools work as long as those using them agree on their use.
2) Tools don’t matter if team members are committed to any form of dysfunction.
3) The United States of America has the highest doctor-to-daredevil ratio in the world.
I will now sign off and try to think of something useful to say on the subject.
