Agile evangelism for my own team
February 23, 2008 by homebrutrout
So about once every quarter we try to get our entire geospatial development staff together in the same room for a couple of hours to catch up with everybody. It’s a “dinner-n-learn” type of thing after hours where we might cover new projects and developments within the company, recognize heroic acts by team members, and one member of the team will give a presentation on new technology or some hot topic that they care about. Well it was my turn at the pulpit this week and so I worked up a presentation introducing agile software development approaches focusing on Scrum.
Surley they had to realize that if the guy writes about it on the internet…they’re going to get a whole mouthful of it at some point. Anyhow I’m pretty used to institutional inertia and was pleasantly surprised by the reception the presentation got and my assertion that we should begin moving to a Scrum project management approach for most of our projects. At present, lots of our projects are run in a standard waterfall framework with the occasional spiral approach here and there. And my assertion that our clients would be better served and we would work more effectively as a team by using Scrum seemed to go over well.
One seven person team for one of our larger projects is already making the switch to Scrum and have even gone so far as to use some Scrum tooling (Rally) to make it go. And it looks like another large project I’m currently on will be committing fully to a Scrum approach and involving client personnel in our Scrum team as well to facilitate knowledge transfer for our future development there. I’ve spoken and worked with lots of other developers and architects who have wanted to get away from traditional sequential development processes and PM approaches in the geospatial realm and were met with limited success just simply due to a backlog of fixed-price, fixed-deliverable projects, ingrained attitudes within their own organization, etc. (What Schwaber has called “the tyranny of waterfall”).
Perhaps there will be a happy ending and a shift in thinking for us. I think the key in getting my point across was to outline and describe the process, but to focus more on what it means to all the stake holders in a project. To the product owner or client, it means a lower blood pressure, less contract negotiation and nitpicking, and a lot less posturing about deliverables. For the scrum master, it’s going to mean a life as a servant leader no matter what, but perhaps an enlightened singularity of purpose (removing impediments and blocking issues) is the reward. For the scrum team, it means checking your ego at the door and giving up the 3 hour lunch in exchange for a true team approach where you rise or fall together. It also means turning out good software faster that you may have previously thought. And for me, that’s the biggie that makes me love what I do. Perhaps agile has a future in the geospatial industry after all.
