I have heard this question being asked a lot of times – do you use agile development methodology? How about scrum, how about spikes? I heard this asked yesterday. To tell you the truth, I have some idea what agile is but to me it sounds very much like the latest buzzword to me. In my product management career spanning 12 years, I have really not paid too much attention to what software development process my team uses. Instead what I have focused on are things like –
1) Is my development team delivering functionality that solves customer problems that customers care about?
2) Are they delivering it on time so that it satisfies my existing customers and can help the business meet the revenue projections for this year?
3) Is the team receptive to iterative input or to customer’s new requirements during the development cycle to change the functionality based on customer feedback during alpha and beta testing – without telling me that “hey it was not in the spec and it is too late to make changes” (I fully realize to meet schedules and quality, there is indeed a point where it is too late to make changes)
4) Does my development team create very frequent and usable builds (not fully tested and hence buggy in some respect) so that QA and product management get to play with it early to ensure that what is being built is what customers want and to provide iterative feedback (Believe me, I do not think there is anything called a complete spec because have written so many functional specs over the years, I consider it difficult to foresee all the different permutations and combinations when writing the initial spec)?
5) Are they delivering functionality of good quality that customers can use?
To me, delivering usable products to customers that help the customer be successful and helps my business to make more money, is all that matters. What you call the process, agile, scrum, spike, non-agile does not matter.
Like anything else, if your development team does not have the right skill set, no development methodology stands a chance to do what is needed to sustain and grow your business. So before one starts using the latest fad in development methodology or starts saying things like – if you are not using agile, you are doing something wrong – it would be better to ask the question – why do I need this new methodology? what current development problems will it solve? What benefits would it bring to my customers or to the business.? Such an assessment would be well grounded in objectivity and reality rather than getting carried away by this hype.
I am not saying “agile” is bad or wrong (I don’t know enough about it) but no process can fix a problem if you don’t know the root cause to the problem.
4 thoughts on “Are you agile?”
Yes – the posts you pointed me to was very informative.
We are trying to get to a quarterly release cycle for some of our key products and I was keen to see (and measure) how the spec quality improves over every quarter. Are there some metrics that I can keep track of? I could think of stuff like how many defects raised by QA were attributable to incorrect requirements, number of times a spec had to be changed after walk-throughs with dev (very difficult to implement)etc. I was looking to pick your mind for stuff that would really make sense in measuring.
Hopefully the following two posts will help you
If not, let me know.
A question that is slightly tangential to the topic.
I recently was conversing with a development manager and the conversation quickly veered to quality of specs coming from Product Management. Now, I don’t know of any practice or methodology that evaluates the quality of specs. I would love to hear your view about this and anything that you may have come across in your experience.
The problem it solves is keeping the big picture from overwhelming an organization. If you specify a small amount of functionality in a certain time (a sprint) then it’s easier for some people to grasp. It’s really just organized common sense. You still have specs and long term requirements, but by breaking them up into tiny deliverables, it’s easier for everyone to stay on track. When you have a world class development team, you can get away with long term goals and waterfall methods because such an organization has people that take account of what they need to do personally (and if you’re in such a shop you’re lucky). But not every shop has the breadth and/or quality of people to depend upon. It doesn’t mean they are bad shops, just that they aren’t the best yet. Such shops tend to function better with agile methods because the people are not overwhelmed with the scope of a large project. Others have high quality people but they have so much work that agile methods help keep things in control. It’s micro-management but at a grass-roots level so nobody feels micro-managed. Anyways, that’s my 2 cents but what do I know, I’ve got bugs to fix.
Great blog by the way 🙂