Episode 4 is out and you can find all the gory details here. I’m involved again, marginally more than last time, so that alone should cause you to listen. Also, even if you don’t listen, please subscribe through iTunes. Help a brotha out, ya know?
This article on the resulting change in a development shop after they adopted Agile popped up on Reddit today and the comments there got me to thinking again about the ramifications of changing the meaning of a term or phrase while still using the term or phrase to describe it.
Last week, we had an internal conversation regarding this Ron Jeffries’ post where he talks about the essence of Agile Software Development as he and others defined in the Agile Manifesto. Leaving aside the idea that the Agile Manifesto is a set of values and not dictates, one of my colleagues made a good point regarding how it was too late to discuss what Agile meant because the term Agile had been bastardized in so many ways as to be irrelevant, poetically paraphrased. A comment on the Reddit thread above made the same point, that in our industry, once you put a name on something, you have essentially relegated it to the dustbin of history because once something has a name, people can latch onto the name while changing the underlying structure of what the name stands for. Many people say that the beauty in agile is its flexibility but when something is so flexible as to have completely different meanings depending on how it is implemented, naming it loses all meaning.
The term agile should be be viewed as a descriptor of a philosophy of programming and not as a concrete implementation of how you develop software. Even Agile Software Development is philosophical in nature and aside from the main tenet of delivering usable, valuable software regularly, it is a term that should be used to light but not build your path. If your team writes a detailed specification at the beginning of a project and then iterates over that specification regularly delivering working, usable software, you are using agile philosophy even if very few agile coaches would teach that way. Having a philosophy guides your decisions but does not dictate your decisions. The failure to not clearly state this is one of the larger failings of the agile community.
Of course, by plastering a name onto something, you practically guarantee that someone will try to make money off of it, especially if it becomes a part of the software culture. However, it would be hard to make money being an agile coach if your coaching totally consisted of Yoda-like platitudes. “Deliver working software sprint 1 you will.” So the term agile became a description of directives and that’s when it started to significantly lose meaning. Saying you do agile software development now means you’re doing something that superficially looks like Scrum or Lean or XP but is so drastically different under the covers that the term “agile software development” has no meaning.
The best agile coaches understand this. They look at a process in a development cycle and try to decide if it fits into the philosophy of agile as opposed to the particular pragmatic implementation of agile that the team is working under. If it does, the process can be kept. If it does not, the process needs to be revamped or eliminated in favor of one that helps the team deliver software. Anything else violates the philosophy of agile software development.
For a monstrously large company, Google keeps its sense of humour.
Improving Enterprises has started a bi-weekly podcast series on a variety of topics. Your humble blogger was included in episode 3 in which he mumbles something about human testers at around 10:20 and then equates Test Driven Development to Color-By-Numbers later in the show. You should listen to it but mostly for the other intelligent people on the podcast and not for me. The episode is “Throw Away Your Unit Tests”. It has to be good with a controversial topic like that.
While you’re there, subscribe using iTunes. It will really help us out.
Npgsql is a .Net data provider for PostgreSQL databases. You can find the relevant information here.
Jay Fields explains how his team uses an extremely low ceremony requirements tracking plan. Their requirement tracking is basically three stacks of cards and the stakeholder is perfectly happy with it. Of course, the team can do this because of the trust the stakeholder has in the team and the trust the team has in each other to follow up and have conversations about the minimum requirements collected. This trust is something that advocates of a “Take what ever parts of agile you want” approach often ignore or fail to understand.
Several of my colleagues and/or readers feel that I must be terribly inexperienced or flat goofy when I advocate for a team new to agile to follow Scrum exactly to the letter. They often talk about teams that they have been on that have just done pieces of agile and they have succeeded. Of course, I’ve never said that ALL teams should ALWAYS follow Scrum exactly. I advocate for those new to agile, especially coming from a high process or high dysfunction environment, follow the process completely because they will not have the experience to understand what does and does not work for them and they will rarely have a coach to help out in that far more difficult endeavor than many people remember.
Would you trust a Cessna pilot to get into the cockpit of a Dreamliner 787 and taker her on up? Of course not. The thing is, writing software well is only marginally less difficult than flying a jumbo jet. There are hundreds of little things that go into doing the job right and teams that are new to agile have no idea what is important and what is just part of the ceremony.
One thing Jay doesn’t mention but that I have written about before and that I feel is critical to successful software production is that trust doesn’t appear on a team that has been together for a long time. Trust comes directly from commitment and discipline. If the team has a track record of disciplined feature releases with requirements met, trust starts to form between the stakeholder and the team. With trust comes the ability (but not the necessity!) to choose pieces of the process that work best for the team and drop out pieces that have become mere ceremony. Doing this in reverse order is almost always counterproductive on anything less than an elite team.
People are often derisive when I mention “scrumbut” as a problem but the reality of the situation is that teams that can successfully modify the agile process to fit their needs are the exception, not the rule. Consultants often forget this because they come into situations where they are the coach and the leader and because they are being paid the big bucks, they have essentially bought the trust from the stakeholder. But in the normal day-to-day world of writing software, teams that adopt agile need the discipline that comes from a strict process to build that trust before they begin to modify their system.
