The trouble with Tribbles…

One thing I have noticed working with developers over the years is that they are very helpful people. So helpful, in fact, that sometimes they help themselves right into a corner. And in a modern organization, they have infinite possibilities to get in just such a bind and find themselves with no one to help them out of it!! This is only one of many ways people have found to work with Agile to be able to change the scope of the story/project/program they are working on. In this case, it is the face of friendship that can cause issues – in other cases; it is not quite as benign.

When an organization starts using almost any Agile process, the thought is to use User Stories as the new requirement type. Before we get this, discussion should be had about the previous process that was used, and attention should be paid in particular about schedule padding, estimation padding and requirements overreach. What am I talking about? Well, let’s see – it is human nature of all of us to want to get as much as possible for as little as possible in almost all economic transactions. When we work in an environment where we develop software, we tend to try to get as much development for as little time/money and effort as we possibly can. On the technical side, this is manifested with code re-use and other less than ideal ways. On the business side, we tend to try to compress features, add developers, and shorten timelines. Indeed, one of the most common patterns is to “ask for more than what I need, because I know I’ll only get X%”. Couple that with the “these guys are padding the schedule anyways” and now we have a very destructive way of trying to structure how we work together! Usually, when these two concepts are tightly coupled, we get the “we need ALL the features as you promised” paradigm, with a one BIG release philosophy from the organization as a whole.

I guess that is an extremely long way to say – Check how TRUST and TRANSPARENCY is doing before you start an Agile transition!! Because no requirement type can mitigate your need to trust each other and work together! But, moving right along, I have seen a few creative and interesting ways that organizations within the agile umbrella, and within the story paradigm have found to stretch the scope of the sprint. I characterize these as “creative” because they come, not surprisingly from both sides of the isle. And they usually begin innocuously enough – with what I call “the favor”

The favor starts with a minor event. Usually the development team, who failed to task things out perfectly or had a critical technical task in the story will ask for a small “favor” from the PO to add the work to the sprint. Normally, if they have a decent ScrumMaster, this will happen when the team has a reasonable expectation of success. The favor is granted, and all is well in the world. Sometimes, the team will get a kudos for the favor, maybe some credit in points etc. It will be good all around. Then, in a couple of sprints, well the PO will need a small favor too. Nothing big or crazy, maybe some text edits came in a bit later than they should have, or functionality that was needed was modified by a Veep somewhere. Something the team could easily do, whether we can expect success or not. The team remembers their favor, and does it “just this one time”. Again, if the SM was worth his salt, he would have reminded the team AND the PO that this is a slippery slope at best and should be avoided – but with successful sprints, all is well and the SM is just a ninny cry baby. This continues, but suddenly, the technical and small BV favors come in bunches, and changes to the AC are reviewed and accepted as a normal course of sprint process. And then – the favor causes the sprint to fail. Usually at a critical time. And really, it’s no one person’s fault. Because we were communicating, and collaborating and…

The thing with this pattern is that it uses some concepts within the Agile toolset while ignoring others. It seems ok because we are communicating, but usually for this to be pulled off the communication works around the SM. With success, there really is not much to speak about in the retro – unless the team is paying attention. I have had at least a couple of team members hold me accountable for “allowing” this during an active sprint. Even though I did NOT know it was going on. That was great for me! Because I became aware of the pattern early, and the team felt empowered to now observe and police themselves in order not to fail. And they understood why it was a unnecessary risk to do things this way.

The less benign ways of modifying scope are usually carryovers of the company culture, and need to be addressed quickly. I have seen PO’s that “build in” flexibility to their stories by NOT putting solid acceptance criteria within the requirement, when they could not do this previously in use cases. Since the new teams don’t want to be on another meeting, and “requirements are not what I do, I only develop” when the story gets to them it is hard to spot what the PO wants. But after a few sprints with moving goal posts, they become angry and frustrated. The PO is equally frustrated, but unwilling to firm up the AC so he can” really get what he needs”. These are cultural issues that keep a team from maturity.

Lack of respect for the timebox is a very common approach; with additions being forced into sprints wither with the team’s approval “we just need to do it, man. There is no more time for this” or without “this is business critical. If I can’t get this in, the sprint is useless and a failure”.  This is just silly, because again BOTH sides get hurt and in the end no one gets the delivery they need. The bigger players in this tend to be management, in the very human quest of “faster, better, cheaper” that was mentioned above. With pressure brought to bear against them, the “command and control” booklet says you put pressure on those “below” them. Just because you are trying to be agile does not mean you, the manager, are not still in charge after all!! And these are your people, and you know better what the protect/infrastructure and department need… Scope creep is never as destructive or harmful as when it comes from within the organization, be it the team or the manager.

The simplest way to prevent scope creep in your projects is open and honest communication with ALL parties. Understanding why the request is being made, what we as a team are trying to achieve, what the environment we are working with is and finally what we can and cannot do all play a role in determining when a change can be made successfully and how to address the reality of constant, competing priorities. Usually, when one or tow parties in a team try to address these issues alone they end up getting everyone on the team in a bind. This not only causes pain, but potentially compromises the whole goal. It can also, if handled correctly give the team an new direction and opportunity for some challenges to be overcome. Trust and transparency, with open and honest involvement is extremely difficult to achieve in a large organization. But although it is hard, it CAN be done for a small cross-functional team. And with just those few people on board, a multitude of troubles can be avoided.