I think Markham makes a good contrast between Agile with a capital 'a' invoking the marketing masses and high book sales, and agile with a lowercase 'a' alluding to simply quick and coordinated movement by a team. Markham would agree agile is different for every company, but I'd like to point out that if you want to implement agile for a student team of developers working on a software product, your timeboxes are stretched out--so you're still using agile but you make it work for your developers.
Agile, whether big or little 'a', is about some kind of stressors and some kind of adapting to meet those stressors. I described those stressors in general terms as "business value" -- making something quickly that people want -- but you can fit a lot of things into "business value"
For instance, on a student project, those stressors can be incremental timeboxes (if you have 3 months, why not have 2-week or 1-week cycles with a demo to one of your peer groups? After all, there's a difference between a build/demo iteration and a release iteration)
What I'm getting at is that you're always making some kind of sub-optimal trade-off for the greater good. That's why agile is so tough in schools and large organizations -- the lack of stressors means a lack of impetus to adapt. Many times the first sprint looks just like the last one, or you stretch your sprints to meet the class deadline, or you slipping schedules is routine, etc.
Nice point. But I would argue that the stressors are the same kinds of deadlines as you would see in any professional organization. From my experience working on a student developer team (attempting to use agile), the reason it doesn't work in a school setting is the lack of daily updates and meetings among team members since it's hard to coordinate the schedules any decent-sized team of students and to convince them to reorganize their workload to meet the weekly or bi-monthly deadlines. The worst case scenario is a lower grade on your project, rather than the stressor of losing your bonus or worse--getting fired.
I think I was unclear. Student agile and big-corp agile can have a lot in common.
In really large organizations, developers can be multi-allocated to several different development teams and be working on 5 or 6 projects at the same time. In addition, slipping schedules is the norm. And you can have multiple channels of managers, making accountability problematic. So the stressors don't always apply at big companies either.
That's why I use the startup metaphor. In the startup world, you produce value or you die.
There are techniques to use, of course. You can insist on daily stand-ups and an hour or two of co-located time per day -- to the point of refusing to be on the team if it's not done. But that gets into a whole other area of courage and agile teams which is probably another thread.
The agile manifesto is a marketing tool used to sell consulting services and books. Those who adhere to it quote it like it was some sort of revelation from on high. A new ten commandments. A great religious insight.
Nope, I'm not a fan, although I agree with the items. Software development does not need manifestos any more than it needs new methodologies. What it needs -- what it has always needed -- is pragmatism. Where the application of the manifesto is pragmatic, it is good. Where it is dogmatic, it is bad.
So I respectfully disagree. I'm just not a platitude kind of guy.
I'm all for pragmatism, but a manifesto is a concrete way to tell the guy who just ate a pound of flour and salt that that's no reason to hate chocolate cake.
If agile means "iterative and incremental projects", it is just a new name for what has long been put forward as a good way to develop software.
In 1996, the Jolt award winning book was Rapid Development by Steve McConnell. Some of the practices that the advocates are evolutionary delivery, designing for change, and timebox development. These are the same practices that appear to be what some here believe are what is called agile.
As far as I know, the term agile really only became associated with software development in 2001 because of the agile manifesto. Because the manifesto itself is the origin and source for the whole agile movement it seems logical to me that it should be taken as the defining basis for what it means to be agile.
To me, agile doesn't mean the same thing as good - therefore I don't feel like I need to some how remake agile in my image. I am reasonably comfortable being closer to being a duct-tape programmer than I am to being an agileista.
Allowing the leaders of the agile movement to define what agile is, doesn't have to mean that you agree with everything, or even anything they are saying or doing. There is a difference between talking about what the definition of something is, and talking about whether you agree with that something.
How is your comment any less platitudinous than the agile manifesto?
You could call it the Pragmatic Manifesto:
* What software development needs, is what it has always needed: pragmatism!
* Where it is pragmatic, it is good!
* Where it is not-pragmatic (dogmatic), it is bad!
Making a stand for pragmatism, and against dogmatism is basically saying nothing because what you define as pragmatic can be called dogmatic by others and vice versa. It's politician speak, using a vague word with inherent positive connotations to describe your own actions, and one with negative connotations for anything you dislike.
LOL -- the new slogan is that there are no slogans!
I see your point, but pragmatism has a lot more depth than simply being an adjective and the opposite of something else. "How to do stuff" is a philosophical exercise (sorry to go long here) and like all philosophical exercises, there are many schools of thought. After looking at all the camps, I'll go with Peirce and Dewey, who, looking at the field, said basically "so what?" "What's it mean to me right now?"
Now maybe the pragmatic school of philosophy has been a con job all along -- if so, hey, the money is good -- but I think there's a bit more to it than simply substituting one slogan for another.
12 comments
[ 0.26 ms ] story [ 29.9 ms ] threadAgile, whether big or little 'a', is about some kind of stressors and some kind of adapting to meet those stressors. I described those stressors in general terms as "business value" -- making something quickly that people want -- but you can fit a lot of things into "business value"
For instance, on a student project, those stressors can be incremental timeboxes (if you have 3 months, why not have 2-week or 1-week cycles with a demo to one of your peer groups? After all, there's a difference between a build/demo iteration and a release iteration)
What I'm getting at is that you're always making some kind of sub-optimal trade-off for the greater good. That's why agile is so tough in schools and large organizations -- the lack of stressors means a lack of impetus to adapt. Many times the first sprint looks just like the last one, or you stretch your sprints to meet the class deadline, or you slipping schedules is routine, etc.
In really large organizations, developers can be multi-allocated to several different development teams and be working on 5 or 6 projects at the same time. In addition, slipping schedules is the norm. And you can have multiple channels of managers, making accountability problematic. So the stressors don't always apply at big companies either.
That's why I use the startup metaphor. In the startup world, you produce value or you die.
There are techniques to use, of course. You can insist on daily stand-ups and an hour or two of co-located time per day -- to the point of refusing to be on the team if it's not done. But that gets into a whole other area of courage and agile teams which is probably another thread.
Nope, I'm not a fan, although I agree with the items. Software development does not need manifestos any more than it needs new methodologies. What it needs -- what it has always needed -- is pragmatism. Where the application of the manifesto is pragmatic, it is good. Where it is dogmatic, it is bad.
So I respectfully disagree. I'm just not a platitude kind of guy.
In 1996, the Jolt award winning book was Rapid Development by Steve McConnell. Some of the practices that the advocates are evolutionary delivery, designing for change, and timebox development. These are the same practices that appear to be what some here believe are what is called agile.
As far as I know, the term agile really only became associated with software development in 2001 because of the agile manifesto. Because the manifesto itself is the origin and source for the whole agile movement it seems logical to me that it should be taken as the defining basis for what it means to be agile.
To me, agile doesn't mean the same thing as good - therefore I don't feel like I need to some how remake agile in my image. I am reasonably comfortable being closer to being a duct-tape programmer than I am to being an agileista.
Allowing the leaders of the agile movement to define what agile is, doesn't have to mean that you agree with everything, or even anything they are saying or doing. There is a difference between talking about what the definition of something is, and talking about whether you agree with that something.
You could call it the Pragmatic Manifesto:
* What software development needs, is what it has always needed: pragmatism!
* Where it is pragmatic, it is good!
* Where it is not-pragmatic (dogmatic), it is bad!
Making a stand for pragmatism, and against dogmatism is basically saying nothing because what you define as pragmatic can be called dogmatic by others and vice versa. It's politician speak, using a vague word with inherent positive connotations to describe your own actions, and one with negative connotations for anything you dislike.
I see your point, but pragmatism has a lot more depth than simply being an adjective and the opposite of something else. "How to do stuff" is a philosophical exercise (sorry to go long here) and like all philosophical exercises, there are many schools of thought. After looking at all the camps, I'll go with Peirce and Dewey, who, looking at the field, said basically "so what?" "What's it mean to me right now?"
Now maybe the pragmatic school of philosophy has been a con job all along -- if so, hey, the money is good -- but I think there's a bit more to it than simply substituting one slogan for another.
But I loved your comment!
http://en.wikipedia.org/wiki/Charles_Sanders_Peirce
http://en.wikipedia.org/wiki/John_Dewey