Agile Thoughts

On a recent scrumdevelopment thread about changing Scrum (here) Dave Barrett wrote:

“I think that [Agile Software Development with Scrum] is just as relevant today as it was when Ken wrote it. We still use 30 day Sprints, an Excel spreadsheet for burndown charts, track in hours and estimate in Ideal Developer days. And it works just fine thank you.

I think I understand why people feel the need to embellish Scrum: it’s just too simple. However, it doesn’t need embellishment, and keeping focused on the basics is probably the key to success.”

There are two ways of “embellishing” Scrum; one is to add things, the other is to remove things.  Both need to be handled with care.  I tend to agree that the simplicity of Scrum is its strength and I’m wary when people say we need to add roles, or define the process more clearly.

One the other hand I am all for seeking out and removing waste, so if I find that certain practices in “original” Scrum don’t add value I will not use them. I found that with hours-tracking.  There are other ways to know if the work is on track for a sprint, simpler ways that require no tracking at all from developers.  Anything that allows a developer to be free to create seems like a valuable thing.  The responsibility of updating work is still there, the commitment to completion is still there, it is just much simpler.

The danger of this “stripping away” approach is that people begin to think along the lines of, Oh the daily Scrum doesn’t add value it’s just a waste of time, let’s drop it.  Which is a very, very bad idea.  So when can a Scrum practice be safely dropped?  I think the simple answer is: when it is not being dropped to mask a dysfunction.  Of course, when people say let’s drop this or that Scrum practice they are not aware that their actions are hiding the real issues.  This is where experience comes into it.  An experienced Scrum practitioner can assess the value of a particular practice, weigh it against any downside, such as loss of transparency, and make an informed choice.  (Every choice of course can be revisited at the next retrospective.)

There is also a big difference between dropping Scrum practices and breaking the Scrum framework, and understanding that difference is also something that comes with experience.  When we remove a practice we can safely do so if we retain the value that practice was providing.  As an example, just dropping IDD and not estimating would be unwise, but replacing it with story points is smart; it retains the value that estimation provides and brings better opportunity for dialog along with it.

I general I am all in favour of simplifying any process, and opposed to making things more complex, or worse, more complicated.  Adding things to Scrum usually results in complication.  Removing things can result in simplicity, but only if it is done wisely and with a good understanding of Scrum principles and values, otherwise the result will be confusion and a return to whatever was in place before Scrum came along (which we can safely assume was not good).

Just a few late-night thoughts, before I head off to New York again.