I recently attended Microsoft Tech Ed in Atlanta, and while there wasn’t much new being announced about SQL Server (I had heard about many of the features for Denali at PASS Summit 2010), I did find myself drawn to several sessions regarding Agile principles and development. My shop has been using the Scrum method for about 2 years now, and it was nice to have a refresher. I also participated in (and overheard) a lot of conversations about Agile methods, and it made me realize two very important things:
- Many people who claimed to be using Agile methods had never read the Agile Manifesto, and
- There are several misconceptions in play regarding Agile development.
The point of this blog post is dual-fold; first I want to encourage you to read the Agile Manifesto. If you’ve read it before, read it again. And then, read it a third time (it’s short, so easy to read). Done that? Good, because here’s the crux of my argument:
If you want to do Agile development, you must adhere to the principles of the Agile Manifesto.
It’s simple, really; you shouldn’t claim to be a SQL Server developer if you’ve never written a T-SQL statement. You can’t call yourself a cubist if you haven’t studied the works of Picasso. You shouldn’t claim to be doing Agile development if you don’t adhere to the principles of the Agile Manifesto.
And, that leads us to the second part of this post; I believe that lots of us think we’re adhering to the methods and principles of Agile development, but there are at least three basic myths about Agile development which keep development teams from being as agile as they can be; here’s my take on them:
Myth 1: Daily meetings with business people are an impediment to rapid development.
I actually got into a fervent discussion with gentleman at TechEd about this subject during a Birds of the Feather Session on Scrum. he claimed to be a Scrum Master for 6 teams (including several overseas), and that he barred business people from entering into the daily standup in order to keep them from dragging the meeting astray. I think that’s wrong, and here’s why (from the Agile Manifesto principles):
Business people and developers must work together daily throughout the project.
While it’s true that the daily standup in Scrum need not be the daily interaction, it makes sense that business people LISTEN (but not INTERACT) in that meeting in order to understand on what issues the development team is working, and how those issues interplay with each other (Note: scrum calls this the chicken and the pig; business people need to know what’s going on across the development team, but shouldn’t be involved at this point. However, the daily standup can spur additional conversations). If your development team chooses to have a daily standup without business people, your team members MUST interact with business people in order to handle changing requirements; they must also communicate at that time what the priorities of the development organization are, and why this particular project is not progressing because some other project takes priority.
Agile development depends on the interaction between developers and business people; to isolate half of the team from the other half of the team will cause disruption to the process. That leads us to our second myth:
Myth 2: Your development team can be agile in a vacuum.
I call this the Agile-Waterfall mindset; your business organization is separate from your development team. Your developers are practicing some form of Agile development, but the organization is used to handing off a set of requirements to the developers, and then having them return a product at periodic intervals. Think of this as the complement to Myth 1; Business people aren’t deemed to be an impediment, but the organization hasn’t endorsed agile development throughout. Daily meetings with developers aren’t deemed to be a priority by the business people; the organization has developed a culture of handing off responsibilities, and expecting them to be fulfilled without daily guidance.
By definition, you can not have an agile team without input from both developers and business people. If you want to respond to changing requirements (as frustrating as that can be to developers), you must have input from business people as soon as those requirements change. Again, you need to handle prioritization, as changing requirements do not necessarily merit immediate priority.
Myth 3: Self-organizing teams self-manage efficiently.
A couple of great principles from the Agile Manifesto deal with communication:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The best architectures, requirements, and designs emerge from self-organizing teams.
While I believe in the wisdom of these two principles, I don’t want to de-emphasize the need for good, basic software design principles. Most enterprise development consists of intertwined projects and resources; in order to minimize maintenance issues, adherence to consistent programming standards is a must. Developers have different naming standards, procedural methodology, and architectural perspectives; a good team has a playbook that ALL members of the development team (regardless of what project team they serve) follow. If you have one database developer that makes heavy use of schemas, and another one that doesn’t, maintaining each other’s code requires some additional effort on their parts. Furthermore, when teams are self-formed of roughly equally-experienced developers, resolution of architectural decisions can be difficult.
Development teams need an enforcer; a good manager goes a long way toward resolving interpersonal conflicts before they get started. Just because teams communicate well (and good communication includes conflict), it does not necessarily mean that those same teams will develop quality code in an efficient manner. Good teams need good direction.
Summing Up.
If you’ve made it this far, I hope I’ve given you some food for thought, as well as encouraged you to go back and revisit the Agile Manifesto, as well as your own organizational processes. Let me sum up with a final thought from the Agile Manifesto:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
