Tuesday, March 9, 2010

The truth about the '7 truths about Agile and Scrum that people don't want to hear' that people don't want to hear :)

I was reading through the intro and first two parts of Kai Gilb's seven part series entitled "7 truths about Agile and Scrum that people don't want to hear" and I had a strange sensation of yes-but-no.

The yes feeling comes from the very general underlying theme of the articles.  I'm a big proponent of having specific, measurable features to deliver in a software product and I agree that it is important to ensure stakeholders are getting a good value for the cost.  Further, I believe strongly in developer creativity and that software development is in general a creative social process.

So in general I agree with all the stuff that Kai seems to be saying is important and that we should be doing.  So where did my but-no feeling come from?  It's the blaming of agile for these shortcomings.

Before going on, I'll state some of my opinions about agile and scrum.  I see agile as a general philosophy or a mindset for developing software .  The agile manifesto (also referenced by Kai) lays this  out using four values and twelve principles, but at the end of the day its about programming in code to create a deliverables.  As for Scrum, I believe it is merely a framework that gives a team the ability to adhere to agile values and principles, but again, Scrum is about actually programming within a controlled context to create a given product or feature set.

I guess the key here is that neither agile nor scrum addresses much if anything about gathering or defining requirements, only what to do once the requirements are obtained.  Perhaps this is Kai's point, but is this a truth people don't want to hear?  I don't think so.  It's true that requirements gathering and definition is still important, just as much now as they always have been, but I believe agile doesn't address these issues because it was not intended to.

This assertion to me would be akin to claiming that agile and scrum don't ensure developers write clean code, use best practices, or have appropriate architectures.  Well of course they don't!  The principle "Continuous attention to technical excellence and good design enhances agility." doesn't explicitly define clean code or writing tests first or any other best practice, nor should it.  

By the same token, the princple "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." doesn't explicitly define valuable or how to determine value and, again, it shouldn't.  Please do not misunderstand that I don't think this is important.

I do agree with Kai's claim that use-cases are not the same as specific functional requirements, but again I would say they were never meant to be.  I do like the small examples of what I assume is the Gilbs' Planguage tool to define requirements, but that would be an example of a tool used for the job it was intended, not a shortcoming of agile or Scrum.

After reading and thinking about Kai's articles, I felt like I was missing something; like I didn't get the title or many of the claims (maybe I am as I've only read 2/7 of the series, but at this point that's all there is).  Was it just intended to be a blog to attract attention?  I wasn't sure because to me Kai was stating a lot of the obvious.  Perhaps a better title would be "Dont forget to gather and define the requirements for your software project before implementing it with scrum"? (probably too long)

No comments:

Post a Comment