SmoothProjectManager put up a short post about his disbelief on whether waterfall is dead or dying. You can hear his disgust between the lines about how strongly people are stating that waterfall is dead when, in fact, it is not.
I totally agree. Waterfall is not dead. BUT, those who have experienced successful Agile/Lean approaches have decided that they aren't turning back to waterfall because of their new level of job satisfaction.
Waterfall works well in projects where scope and deadline issues are minimal. The military uses PMI very well to build things like aircraft carriers. But, you also don't see them changing the length of the ship hull by 40 feet in the middle of the project like people change requirements on software projects. Change can't be tolerated in that type of project so the PMI/waterfall approach is very relevant.
A fundamental difference between the two is "fight change" vs. "embrace change".
Agile is growing much quicker than waterfall for many reasons including:
- when done properly... it works, and well
- it handles change much better than waterfall
- it reduces finger pointing which increases morale and job happiness
And unfortunately, it is a well-misunderstood buzzword that is being overused and misapplied (which shouldn't count as growth).
So, neither has won... and neither will conquer the other. As members of the agile community, we have to be careful about what we say to people in the non-agile world about our beliefs. If we come across as evangelists, we may turn people off from even listening to something that they might greatly benefit from.
Anyway, their are still people clinging to OS/2 warp machines somewhere out there... nothing ever dies in the tech community.
Random comments on interesting posts within the agile software development community...
Tuesday, October 7, 2008
Thursday, October 2, 2008
Agile Practices as a gateway drug...
The agile community needs to recognize that not everyone can jump in with both feet.
We seem to be going through an identity crisis where we are declaring what is agile and what isn't. This is very important because the agile label is getting slapped on many presentations when companies think it makes them look good when they are in fact, not agile. In doing so, they are also diluting the global understanding that agile is a cultural change as much as a process change. Not standing up for this means allowing agile to become the same thing as RUP, PMI, CMM, or any other silver bullet labels that have been mis-used to the point where they don't contain the strong value they did when they first arrived.
Having said this, we can't keep believing that everyone should either be full agile or no agile. I get the sense that many people post about what it means to be agile, and at the same time (reading between the lines) they are creating a "you aren't really one of us unless..." cultures.
Agile started as an inclusive community. We are all going down a path of growth and learning. We have to make sure that when we provide clarity on the true side of agile, we don't give the impression that there is no value in the separate pieces.
We WANT people to get ALL of it. But sometimes people have to get there in their own way. Is it okay for someone to add retrospectives and nothing else? Is it okay to implement sprints and nothing else? Yes, I believe it is. I believe that if people are reading about agile and like the ideals, but can't afford the whole cost (and immediately gain the whole value)... then they will continue to learn and read. Many of the agile practices are a gateway drug to wanting to achieve the whole thing.
Maybe that's an Agile 2009 presentation I'll consider giving: Using agile practices as a gateway drug to becoming agile.
Anyway... this thread was triggered by a blog post about incremental, iterative, and agile development by Mike Cottmeyer. He also makes some good points such as:
"... You can still get some mileage from delivering software in two or four week cycles, daily interactions between project members, and frequent project reviews. You can make use of loosely coupled requirements, prioritized backlogs, and rolling wave planning. There is value in understanding the definition of done and making sure that once you've delivered, you have really delivered. Managers can do product planning, release planning, and iteration planning without being particularly agile... "
We seem to be going through an identity crisis where we are declaring what is agile and what isn't. This is very important because the agile label is getting slapped on many presentations when companies think it makes them look good when they are in fact, not agile. In doing so, they are also diluting the global understanding that agile is a cultural change as much as a process change. Not standing up for this means allowing agile to become the same thing as RUP, PMI, CMM, or any other silver bullet labels that have been mis-used to the point where they don't contain the strong value they did when they first arrived.
Having said this, we can't keep believing that everyone should either be full agile or no agile. I get the sense that many people post about what it means to be agile, and at the same time (reading between the lines) they are creating a "you aren't really one of us unless..." cultures.
Agile started as an inclusive community. We are all going down a path of growth and learning. We have to make sure that when we provide clarity on the true side of agile, we don't give the impression that there is no value in the separate pieces.
We WANT people to get ALL of it. But sometimes people have to get there in their own way. Is it okay for someone to add retrospectives and nothing else? Is it okay to implement sprints and nothing else? Yes, I believe it is. I believe that if people are reading about agile and like the ideals, but can't afford the whole cost (and immediately gain the whole value)... then they will continue to learn and read. Many of the agile practices are a gateway drug to wanting to achieve the whole thing.
Maybe that's an Agile 2009 presentation I'll consider giving: Using agile practices as a gateway drug to becoming agile.
Anyway... this thread was triggered by a blog post about incremental, iterative, and agile development by Mike Cottmeyer. He also makes some good points such as:
"... You can still get some mileage from delivering software in two or four week cycles, daily interactions between project members, and frequent project reviews. You can make use of loosely coupled requirements, prioritized backlogs, and rolling wave planning. There is value in understanding the definition of done and making sure that once you've delivered, you have really delivered. Managers can do product planning, release planning, and iteration planning without being particularly agile... "
Wednesday, October 1, 2008
Their military is agile...
I've always thought of the military as a command-and-control type of environment and therefore very un-agile. Funny thing is that 1187hunterwasser has a great personal experience where he connected military experiences with agile experiences. It was surprisingly interesting to find out that mission-type tactics and agile are similar.
I guess the glimmer of hope here is that it's not the organization type (military, research, etc) that defines the culture, it is the people.
I guess the glimmer of hope here is that it's not the organization type (military, research, etc) that defines the culture, it is the people.
Tuesday, September 30, 2008
Agile Wikipedia update...
Jon Strickler has been working for months on a better clarification of agile to the open world. He recently took it upon himself to update the wikipedia page on Agile software development. In reviewing his work I also realized it might be good to call attention to the PM Declaration of Independence.
Monday, September 29, 2008
70% accuracy + Speed is better than perfect...
Artemgy has an interesting post about agile decision making.
"...it is important to make the right decision… …or is it?
Not according to Percy Barnevik’s “7-3 formula”! The man who ran Swiss engineering giant ABB for a decade insists that you can still be successful if you make nearly half as many wrong decisions as you make right decisions!"
I think a big part of embracing agile is understanding the fail quickly mantra. You have to accept the boundaries of your day, iteration, and release and use them to force forward progress instead of falling into an analysis paralysis state. This is a by-product of all the feedback loops found in agile (pick your agile denomination). It's okay to make bad decisions sometimes if you can recover quickly.
The more transparently you can do this, the more trust you build with your customers and users that you will always do the right thing for them in the long run. This creates loyal followers.
Sustainable pace...
I ran across this from another site. It's about productivity and overtime. It wasn't intended to be agile focused (actually, if you are truly agile, then this isn't relevant), but it's good ammunition for an agile team when arguing with management about sustainable pace.
Enjoy!
Update: Today InfoQ published an article about sustainable pace. OpenView Venture Partners has announced that overtime is detrimental to scrum. There is a reference to Clinton Keith's discussion on this also.
Enjoy!
Read this document on Scribd: Rules of Productivity
Update: Today InfoQ published an article about sustainable pace. OpenView Venture Partners has announced that overtime is detrimental to scrum. There is a reference to Clinton Keith's discussion on this also.
Friday, September 26, 2008
Rant about Agile Certification...
If you hadn't noticed, the title of this post notes that this is a rant. I know I will upset certain people in the community, but I believe in this and I've got to speak up.
I endorse scrum as a good approach within Agile to pursue. It is one option of several and I've had success with it. I'm also a CSM, certified scrum master. This was paid by my prior employer and I was trained by one of the original 40 CSTs, certified scrum trainers.
//rantbegin
At Agile 2007, I talked to someone in the Scrum Alliance booth and found out that there is a great money sucking scheme behind this certification thing. First of all, it expires after a year. Secondly, you can renew it by simply paying for it. Back then, they sent you a new sticker for the new year to place on your certificate. They didn't even take the time to print and send you a new one.
So basically, the certification is a scam. It certifies that you sat in a class that has no test at the end. It doesn't require you to have experience. It doesn't require anything for renewal but money. Oh yeah... now that everyone has it, they offer several other upgrade certifications: CSC, CSP, CSPO, CST. Why not a CSBSer?
What triggered this rant a year after I gained this knowledge at Agile 2007? Recently, Bob Sarni did an awesome thing by creating a LinkedIn group for the Scrum Alliance. It was one of the few LinkedIn groups that had some real discussion. Recently, he handed the baton off for the group to someone else. After a few weeks, there is an announcement that members of the group should divide themselves by the above acronyms and join new groups. Oh yeah, and-
It's a shame because its stuff like this that helps people lump agile into the same bucket as all the other has-been process certifications over the years.
Agile is supposed to be an inclusive community. We are all supposed to be striving together for higher understanding. We are all supposed to be helping each other. This smells like an old boys club.
I'm not alone in this thinking... here is a post on InfoQ, a second one, and the formal Agile Alliance stance on certifications.
//rantend
I am glad I have the certification. The training was valuable and helpful for my education in Agile. I am honored to have worked with some of the people in the Scrum Alliance. I'm just opening a real debate around how it sets a perception of elitism.
In related news, there is a driving movement towards peer certifications that I do endorse (assuming it continues in the direction it is currently heading).
Invitation: I seriously welcome any thoughts on this topic. I will let them all through... I only moderate comments to block spam.
Update Nov 2008: this post got a lot of traffic... there is good news... they are adding a test to this certification! I don't know how well it will work, but it is a start.
I endorse scrum as a good approach within Agile to pursue. It is one option of several and I've had success with it. I'm also a CSM, certified scrum master. This was paid by my prior employer and I was trained by one of the original 40 CSTs, certified scrum trainers.
//rantbegin
At Agile 2007, I talked to someone in the Scrum Alliance booth and found out that there is a great money sucking scheme behind this certification thing. First of all, it expires after a year. Secondly, you can renew it by simply paying for it. Back then, they sent you a new sticker for the new year to place on your certificate. They didn't even take the time to print and send you a new one.
So basically, the certification is a scam. It certifies that you sat in a class that has no test at the end. It doesn't require you to have experience. It doesn't require anything for renewal but money. Oh yeah... now that everyone has it, they offer several other upgrade certifications: CSC, CSP, CSPO, CST. Why not a CSBSer?
What triggered this rant a year after I gained this knowledge at Agile 2007? Recently, Bob Sarni did an awesome thing by creating a LinkedIn group for the Scrum Alliance. It was one of the few LinkedIn groups that had some real discussion. Recently, he handed the baton off for the group to someone else. After a few weeks, there is an announcement that members of the group should divide themselves by the above acronyms and join new groups. Oh yeah, and-
Each requires active membership in the Scrum Alliance and appropriate certification. Please feel free to join any of the other groups you are certified for...So, now they are using LinkedIn to milk money out of the certification machine.
It's a shame because its stuff like this that helps people lump agile into the same bucket as all the other has-been process certifications over the years.
Agile is supposed to be an inclusive community. We are all supposed to be striving together for higher understanding. We are all supposed to be helping each other. This smells like an old boys club.
I'm not alone in this thinking... here is a post on InfoQ, a second one, and the formal Agile Alliance stance on certifications.
//rantend
I am glad I have the certification. The training was valuable and helpful for my education in Agile. I am honored to have worked with some of the people in the Scrum Alliance. I'm just opening a real debate around how it sets a perception of elitism.
In related news, there is a driving movement towards peer certifications that I do endorse (assuming it continues in the direction it is currently heading).
Invitation: I seriously welcome any thoughts on this topic. I will let them all through... I only moderate comments to block spam.
Update Nov 2008: this post got a lot of traffic... there is good news... they are adding a test to this certification! I don't know how well it will work, but it is a start.
Subscribe to:
Posts (Atom)