You adopt practice to “make the team go”. However, every practice you adopt has a cost. The time you spend “making the practice go” is somewhat then a cost of making the team go. I like to talk about the cost of your practices as “Feed the Beast!” But what you really want to make your team go is to “Ride the Beast!” where the practices we have adopted start to carry the team faster than they could go without them.
One thing that happens in every team (and organization) is that practices tend to accrue over time. Sometimes teams adopt practices, but don’t feel comfortable abandoning them when they are not longer valuable. Sometimes “governing structures” mandate practices without considering the cost to each team and whether every team “benefits” the same from mandatory practices. Sometimes teams are “saddled” with the cost of meeting organizational mandates in ways that add practices that slow the team or increase their cost to deliver, but these costs are not reported as “organizational” but feel like a tax on the teams capital burn rate.
Every team should be able to evaluate their practice suite and make the case to eliminate or alter any practices that don’t justify their cost in direct long term value to the team.
Scrum requires you to maintain a backlog, plan sprints, have daily standups, hold retrospectives. Test Driven Development (TDD) requires you to write automated tests for every method and property of every class. User stories require that the customer or business “people” spend time with the team on a regular cadence of story development workshops. Continuous Integration (CI) requires you to stand up a server, and probably incurs a cost to script each code branch to work on that server.
A more phase-gated (waterfall) approach may have different practices with different costs, but in the end, we have the same objectives – get something built. So when you are evaluating your tasks and how you spend your team’s time, it is tremendously useful to think in terms of feed the beast (time spent doing activities that are “serving” the practices) and ride the beast (where the practices help the team go faster).
I think my best example of FTB and RTB is around TDD and CI – TDD has a tremendous initial cost – in that you have to write tests demonstrating that you understand the problem before you write the code that solves the problem. For coders (like me) who start “noodling” around a problem in order to understand this feels very counter intuitive. It is work. But the long term benefit of being able to know when a change you make has some “unexpected” bad impact without manually testing everything already built is a huge time saver, on the next story, or the next release. The value of TDD accrues along with the size of the code base so that the bigger the code base, the bigger the benefit. CI is the same way. For those who remember days when we had to manually build software, and it took a long time (sometime it took so long that we only did it every week or two), and only after we had integrated everyone’s changes could we tell if the software was broken. CI makes this ginormous cost go away, and replaces it with a little cost of setting up your branches as a script on a CI server.
So my best advice is this: When your team is evaluating their current practices or when you are implementing new mandated practices, think about how much the practice costs the team, and where the benefits are realized. If the team does not realize any ability to move faster (Ride the Beast), then the practice should be considered for elimination. If the practice is mandatory, the team should consider who the beneficiary is, and should negotiate with that stakeholder to find a lower cost way to deliver that benefit. One might even consider moving the cost of that practice out of the team (billing the beneficiary), so that the team can offset the cost with additional staff.