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.