"You Ain't Gonna Need It" - for me, one of the most completely misused pieces of jargon in the Agile lexicon.
More than anything else, this has been responsible for the misapprehension that agile processes are nothing more than hack-n-fix. The fact is, in many places it's not a misapprehension!
Don't fancy writing any technical documentation for the development you're doing?
"You Ain't Gonna Need It" - it's not like anyone ever reads spec's anyway
Don't feel like writing any user documentation?
"You Ain't Gonna Need It" - the functionality will probably change loads before you release it
Code comments?
"You Ain't Gonna Need It" - not with your brilliantly clear declarative coding style
Architectural design for complex system?
"You Ain't Gonna Need It" - make it do what it needs to do for the story you're on. We can't possibly know what we'll need in the future, so we'll just refactor it when we need to next year / sprint / week / tomorrow...?
Wellllll - yeah. But that's rubbish, isn't it? Sometimes you DO know what you're going to need.
What about the guy who's got to support the product or teach people how to use it?
What about the guy who's got to fix the bug or add the new feature in a year's time, who can't follow your brilliant style (and who will probably be you!)
What about the time you'll waste retro-fitting the architecture you could have got right in the first place?
Like any rule applied blindly and without thinking, YAGNI can get you into all sorts of trouble. Maybe more so.
Of course you shouldn't waste time writing complex technical documentation that no-one's ever going to read (although you should probably find out what it is they DO want, before doing nothing)
Of course you shouldn't comment your code like a first year under-grad and proudly tell everyone you're incrementing counter "i" by 1
And of course you shouldn't develop a powerful, flexible, reusable library for something you don't have any particular plans to do again
But you should at least think about what you do know.
Unless you don't need to do that either...
Thursday 3 February 2011
Tuesday 1 February 2011
What's in a Name?
In response to some comments in another interesting post on Stuart Lynn's blog I asked if we could stop using "Waterfall" as a generic term for "non-Agile" processes.
Guy Letts then asked me the rather obvious question via Twitter:
Here's the long-winded version!
Waterfall was originally (at least according to wikipedia <ahem> <poor research>) described by Dr. Winston W. Royce as an example of a deliberately flawed and broken system.
In my own university days, it was used as a teaching method to identify the stages of the software project life-cycle, but even then it was made clear that this wasn't a practical approach to use in the real world.
The problem with using the term "Waterfall" like this is that the flaws of the method are obvious. This invites the straw-man attack from those pushing an Agile agenda - "Waterfall is bad, therefore all similar approaches are also bad".
This is just as divisive and unproductive as the "it's all code-and-hack-and-fix" claims of the Agile-skeptics.
As it happens, and as I'll discuss in a future post, I think that the differences between the two approaches aren't as great as some people would have us believe. I think that applying generalised labels can create mind-sets which inform thinking and lead people to believe they have to take "sides". This is potentially harmful and benefits no-one but the guys with books to sell!
We should be able to look at all the tools available to use and choose the appropriate set for the job we have to do and the people who will be doing it.
That said, I started this, so...
A term that's commonly used in Agile circles is "Big Design Up-Front".
That's nice and descriptive, but has several drawbacks:
Again, there's an implicit assumption that Agile approaches are inherently better and that it's "wrong" to use anything else. That might be great if your audience is already in the club, but it's not an approach likely to win hearts and minds!
So why do I like the term "Traditional"?
What I really like is that it balances the positive and negative implications nicely:
Introducing new approaches, we need to be certain that we understand the value of existing practices and ensure we're not losing anything.
We need to be aware that logical arguments aren't effective for addressing opinions based on long experience or emotion.
And we need to understand that insulting people doesn't help!
Guy Letts then asked me the rather obvious question via Twitter:
Your suggestions for a better term...?The short answer, that I gave Guy, was "Traditional".
Here's the long-winded version!
Waterfall was originally (at least according to wikipedia <ahem> <poor research>) described by Dr. Winston W. Royce as an example of a deliberately flawed and broken system.
In my own university days, it was used as a teaching method to identify the stages of the software project life-cycle, but even then it was made clear that this wasn't a practical approach to use in the real world.
The problem with using the term "Waterfall" like this is that the flaws of the method are obvious. This invites the straw-man attack from those pushing an Agile agenda - "Waterfall is bad, therefore all similar approaches are also bad".
This is just as divisive and unproductive as the "it's all code-and-hack-and-fix" claims of the Agile-skeptics.
As it happens, and as I'll discuss in a future post, I think that the differences between the two approaches aren't as great as some people would have us believe. I think that applying generalised labels can create mind-sets which inform thinking and lead people to believe they have to take "sides". This is potentially harmful and benefits no-one but the guys with books to sell!
We should be able to look at all the tools available to use and choose the appropriate set for the job we have to do and the people who will be doing it.
That said, I started this, so...
A term that's commonly used in Agile circles is "Big Design Up-Front".
That's nice and descriptive, but has several drawbacks:
- It's a bit of a mouthful
- It tends to be used in scathing tones that imply all up-front design is wasteful. Which is ludicrous
- It abbreviates to "BDUF", which sounds vaguely insulting
Again, there's an implicit assumption that Agile approaches are inherently better and that it's "wrong" to use anything else. That might be great if your audience is already in the club, but it's not an approach likely to win hearts and minds!
So why do I like the term "Traditional"?
What I really like is that it balances the positive and negative implications nicely:
- It recognises that there may be newer alternatives that may have advantages
- It doesn't imply an assumption that newer is always better. These methods have been used successfully for many years; they have been refined over time and many people are attached to them.
Introducing new approaches, we need to be certain that we understand the value of existing practices and ensure we're not losing anything.
We need to be aware that logical arguments aren't effective for addressing opinions based on long experience or emotion.
And we need to understand that insulting people doesn't help!
Agile Consultants
Time for a bit of disclosure - before it becomes too obvious from my other posts:
I've had some poor experiences of "Agile Consultants"
Don't get me wrong, there are some good people out there - guys who can come in and genuinely have a positive impact on your business.
The problem is the other kind - the kind who:
I've had some poor experiences of "Agile Consultants"
Don't get me wrong, there are some good people out there - guys who can come in and genuinely have a positive impact on your business.
The problem is the other kind - the kind who:
- is a hacker who's never delivered a large-scale solution
- who sees process discussions as an argument to be won
- who can convince senior management to part with a pile of cash then blame the failure on the development team who "just don't get it"
- who was in the right place at the right time, and wrote his/her meal-ticket because of who they were standing next to
Yes, I'm being overly cynical - but there are a lot of consultants on the band-wagon and there are people like this out there. If you are looking to bring someone in, do your research properly:
- Talk to their previous clients
- Find out what their ROI was 6 months later... 2 years later
- Talk to the developers and find out what they thought
- And be wary of promises that sound too good to be true...
And if you think I've been too cynical, then read this anonymous, satirical, blog written by someone (not me) with similar experiences and a better sense of comic timing!
Wednesday 26 January 2011
Guaranteed Endpoints
Stuart Lynn gave a good answer to what I thought was a pretty weak question on Quora the other day: What's the "right" method of project management in IT? Stu noted that "its not always clear from Scrum what the guaranteed endpoint will be" and I wanted to pick up on that.
I would actually go further than Stu and say that it's never (or at least very rarely) clear what the guaranteed endpoint will be. In fact, that's kind of the point!
Scrum - and other agile processes - assume that you won't/can't have a full and correct understanding of the requirements at the outset. They assume that requirements will change: new requirements will appear, understanding will improve. The idea is to have a good, clear, visible picture at all times of what you expect the end-point to be... but "guaranteed"? Nope.
Does that matter? Scrum favours the ability to change your mind over the ability to predict exactly what you'll deliver. For the vast majority of projects, certainly all those I've ever worked on, this is appropriate. There ARE projects where this may not be the case - ATC software, missile guidance systems, for example - where a precise endpoint can and must be guaranteed. For these, the ethos of Scrum is inappropriate (although some of the practices may still be useful).
In the world of shrink-wrapped commercial software, I personally don't believe this is the case. Yes, there can be absolutely iron-clad requirements that cannot deviate, but I've never seen a full project progress from start to finish without change.
Of course, this can make life very difficult for Product Managers and Marketing Departments, but no-one ever claimed Scrum was easy (well, maybe some disingenuous consultants...). At the end of the day it all comes down to a simple question:
Is it more important to build the right product, or to know exactly what you're going to deliver?
That's NOT a rhetorical question, but if you're going to go with the second option you better be sure you meant it!
Of course, real life isn't always clear cut; the line from agility to certainty is a continuous spectrum and you have to make the appropriate choices depending your needs and preferences. Which is why my own answer to the original question would, like Stu's, have amounted to "it depends" - but unless you're a long way over towards the extreme then Scrum may be a good fit.
I would actually go further than Stu and say that it's never (or at least very rarely) clear what the guaranteed endpoint will be. In fact, that's kind of the point!
Scrum - and other agile processes - assume that you won't/can't have a full and correct understanding of the requirements at the outset. They assume that requirements will change: new requirements will appear, understanding will improve. The idea is to have a good, clear, visible picture at all times of what you expect the end-point to be... but "guaranteed"? Nope.
Does that matter? Scrum favours the ability to change your mind over the ability to predict exactly what you'll deliver. For the vast majority of projects, certainly all those I've ever worked on, this is appropriate. There ARE projects where this may not be the case - ATC software, missile guidance systems, for example - where a precise endpoint can and must be guaranteed. For these, the ethos of Scrum is inappropriate (although some of the practices may still be useful).
In the world of shrink-wrapped commercial software, I personally don't believe this is the case. Yes, there can be absolutely iron-clad requirements that cannot deviate, but I've never seen a full project progress from start to finish without change.
Of course, this can make life very difficult for Product Managers and Marketing Departments, but no-one ever claimed Scrum was easy (well, maybe some disingenuous consultants...). At the end of the day it all comes down to a simple question:
Is it more important to build the right product, or to know exactly what you're going to deliver?
That's NOT a rhetorical question, but if you're going to go with the second option you better be sure you meant it!
Of course, real life isn't always clear cut; the line from agility to certainty is a continuous spectrum and you have to make the appropriate choices depending your needs and preferences. Which is why my own answer to the original question would, like Stu's, have amounted to "it depends" - but unless you're a long way over towards the extreme then Scrum may be a good fit.
Sunday 23 January 2011
"agile" versus "Agile"
I am a big fan of agile project management.
Scrum - or something very like it - is my default approach.
There can be huge benefit to eliminating waste.
eXtreme Programming, Test Driven Development and other development practices definitely have their place.
What I don't like, what I do not believe is ever the right or appropriate thing, is dogmatic adherence to any particular process, approach or manifesto.
In this blog, if I say "agile" with a lower-case "a" then I mean the good and valuable attribute of being able to react with agility. If I use the upper-case "A" - "Agile" - then I'm likely being ironic or scathing of the idiots who stick blindly to the words of the over-paid Agilista consultants, and are therefore anything but.
Scrum - or something very like it - is my default approach.
There can be huge benefit to eliminating waste.
eXtreme Programming, Test Driven Development and other development practices definitely have their place.
What I don't like, what I do not believe is ever the right or appropriate thing, is dogmatic adherence to any particular process, approach or manifesto.
In this blog, if I say "agile" with a lower-case "a" then I mean the good and valuable attribute of being able to react with agility. If I use the upper-case "A" - "Agile" - then I'm likely being ironic or scathing of the idiots who stick blindly to the words of the over-paid Agilista consultants, and are therefore anything but.
First Post
Well. A first post titled "first post". That's original!
Last time I had a blog was back in the days when you had to provide your own hosting and upload all the files with FTP - and I spent more timepratting about with learning about CSS, JavaScript and cookies than I did writing content.
Many things have changed since then - I'm writing this using a wifi connection on a touchscreen phone - but my ability to write amusing and informative content probably isn't one of them.
So I don't really expect to keep this up for long; but many times recently I've found myself wanting to comment on things that are too geeky for facebook or too complex for twitter's 140 characters. Maybe I'll write them here and maybe I won't...
(And in case you're wondering about the title, my name is an anagram of "Damn Fathomless Prattler" and I like the nod to incomprehensibility and lack of depth!)
Last time I had a blog was back in the days when you had to provide your own hosting and upload all the files with FTP - and I spent more time
Many things have changed since then - I'm writing this using a wifi connection on a touchscreen phone - but my ability to write amusing and informative content probably isn't one of them.
So I don't really expect to keep this up for long; but many times recently I've found myself wanting to comment on things that are too geeky for facebook or too complex for twitter's 140 characters. Maybe I'll write them here and maybe I won't...
(And in case you're wondering about the title, my name is an anagram of "Damn Fathomless Prattler" and I like the nod to incomprehensibility and lack of depth!)
Subscribe to:
Posts (Atom)