Scrum, XP, TDD, BDD, ATDD, FDD, DSDM, RAD, etc…
For those who aren’t in the software development industry, the above are names, most of them acronyms, for currently popular software development methodologies. Some deal with the entire product team’s processes, some narrowly focus on how developers should write the code. Fundamentally, they are attempts to put a structure around the process of building software by defining rules that should be followed by a subset or the entire project team while the software is being developed. Adherents of these methodologies claim that following these methodologies result in better software, faster.
For example, Scrum defines a strict workflow that is broken up into “sprints” that is further broken up into “Planning Sessions”, a “Daily Scrum”, the actual coding work, and a “Review and Retrospective”. These various parts of the sprint have very strict rules applied to the communication and responsibilities of the team members. You know a team is a Scrum team when they meet every morning at the same time, all standing (the meeting is called a standup, or the daily scrum), and go around the circle in a methodical way where they answer three specific questions about their status. Ironically, the Scrum methodology is considered a type of “Agile” methodology, which is supposed to lead to better software by, among other things, removing constrictive processes from software development. Seriously.
I’m a firm non-believer in these kinds of methodologies, at least for the types of projects I have been involved in over the last twenty years. I believe these methodologies are commonly used to fix problems we already know how to fix in much simpler ways. Applying a comprehensive methodology to fix these problems often seems like overkill.
Here’s a fictional example of what I imagine could lead to the adoption of Scrum at a company:
Bob: That was such a long meeting. We went in there to discuss [FeatureOfTheDay], and I don’t think we ever even got to talking about it at all!
Alice: I know, it seems like every meeting we have ends up going off on tangents and everyone leaves more confused than when they went in.
Bob: Maybe we should just set up an agenda for these meetings, and make sure everyone sticks to it…?
Alice: That sounds good, but I don’t want to be the one responsible for creating an agenda.
Bob: I don’t either. Hmmm…I read in Wired about this thing called Scrum. They say it keeps everyone on task and focused. Meetings are short because everyone has to remain physically standing the whole time.
Alice: I’m intrigued. That sounds so smart! I hate to stand. Also, our software has bugs, and I’ll bet Scrum will fix that.
Bob: Yep, Scrum has iterative development which catches bugs early. That’s the solution then. I’ll call up [ConsultingAgency] and get a Scrum Master in here to train the team!
Alice: I’ll draw up a budget.
Six months and a hundred thousand dollars in consulting fees later, Bob and Alice are left with a confused and possibly demoralized development team that thinks the process is more important than the product.
But hey, no more long meetings, right?! What if Bob and Alice had just decided to set agendas for their meetings? IE, what if Bob and Alice had just solved the specific problem instead of thinking that there is a silver bullet cookie cutter solution to all their problems?
Many of the development teams I’ve worked with were talented, productive teams that made great software. Our projects typically finished on time and on budget, and thus made management extremely happy. The one common denominator in these successful teams was they were mostly made up of very technically proficient, motivated developers. If you’ve worked in software development for a while, you know who these people are. They are the ones that get the real work done, and care deeply about their work and the success of the project they are working on. They take ownership of their creations and pride in their craft. Accountability is never an issue with these developers. In other lines of work, these people would be referred to as “professionals.” In software development, they are called “rock stars” or “ninjas”, for some reason that I have yet to figure out. From here on I will refer to these people as “professional developers.” I have never encountered a project where a team of these professional developers would benefit from a prescribed, named development process such as Scrum. That’s my experience, anyway.
Because acronyms seem to catch decision-maker’s eyes in the IT world, I propose a brand-new development methodology called MP. This is short for “Minimal Process” (yes, this is a bit tongue-in-cheek). The doctrine of MP is made up of three rules:
- Only allow professional developers on the dev team.
- Encourage face to face communication as much as possible. Next best is phone calls, followed by instant messaging and email. If it comes down to email, never attempt a full conversation over email, just wait until you can talk face to face.
- When encountering a problem with development, analyze the problem, discuss possible solutions with the team, and pick the simplest, most non-intrusive solution possible. Strive for solutions that do not create additional process.
Obviously, this leaves out a lot of detail, such as how to gather requirements, perform testing, report progress, etc. However, this is the point! These details should be left to the team to decide based on the situation they are in. Professional developers will know what works in what situations and will adapt accordingly. If there is uncertainty, talk about it as a team (see rule #3). Software goes through phases where sometimes testing is more important, sometimes requirements gathering is more important, or sometimes just sitting in a room all day talking is more important. Professional developers know this. Trust them to do their job.
Every software project is different. The requirements are different, the timeline is different, the personalities are different, and the development tools are different. Different situations call for different approaches, and a good development team will adapt to what works. In my experience, home-grown methodologies and processes that fit the situation combined with good people will always beat an off-the-shelf methodology artificially forced on the same group.
The Water Sage team is an excellent team, in fact the best I have worked with. Everyone on the team is a professional, and I’m not just referring to the developers. When we detect a problem, we fix the problem with as simple a solution as possible. Open communication is always encouraged, and strict rules for the development cycle are only used as a last resort, when they solve a specific problem that we have already seen happen and is making life miserable. We follow “Minimal Process,” and it works. Following these basic principles has left our team with the flexibility to use their talents to create a game-changing product in the world of water and land data, and I couldn’t be prouder of what we’ve accomplished.