Agile Development != Low Ceremony && The Movement Needs to Die
A search on Google for Agile Development returns about 4,940,000 hits. Everything is Agile now. Businesses, project management styles, databases, legacy system interface development, architecture, enterprise architecture, enterprises, testing, executives, and the list goes on and on and on and on. Yet the same teams that stank at making software before they were agile, still stink at making software. They just stink at it sooner in the process.
The teams of gurus that decided to put the Agile Manifesto in place, can make software just as well with a high ceremony RUP, or even the dreaded waterfall, as they can smashed into a room the size of a closet with whiteboard wallpaper doing it XP style.
XP was one of the silliest movements I have ever seen. Hey, look at us, we can do software blind folded. It's like Tiger Woods taking me on with only a 7 iron. He will still kick my butt. It seemed like a movement to make things challenging for the pros who got bored doing it the easy way.
I am not saying being agile is bad. What is bad is the branding of agile as something that is new or different. Some new techniques that are useful came out of the movement, but it is time for the movement to die. Please die!!!!!!!
Just like you can't take the RUP and make a team of inexperience developers make good software, you can't take that team and expect them to make good software using XP. Odds are that would just confuse everyone to the point that they don't know what is going on in the process as well as with the product they are trying to develop.
So I guess my point is, processes have not changed the end result of what makes good software development happen. They have renamed things, moved them around, removed things, and added things, but in the end it is the team that knows what it is doing that gets the job done. That includes knowing how to elicit requirements, document the requirements in a traceable way, knowing the patterns that are common to the domain issues and are available in the given technology in order to put together a solid architecture, how to do unit testing or TDD the right way, how to have some sense of pride in developing bug free software, they know how to communicate, they look out for the customers best interest even when it will tick the customer off, they also know what the goal of the project is which enables them to set the proper level of ceremony , and most importantly they realize that nothing is invented, it is only discovered, especially on a software project.
Of course the list is even greater than above, but the point is you either know how to do the tasks in the process right, or you don't. Just doing them is not good enough. So this agile attitude of "Since process activities don't work, let's get rid of them" does not do anything for the team that didn't know how to accomplish the tasks right in the first place. It just displaces their lack of skills to different task. I have seen tons overly bloated software out of agile teams because most teams use agile as an excuse to go right to code.
I personally have found the 80/20 split works best for me when I have an experienced team of developers. That is 80% planning, doing an architectural synthesis, and other prep work, and the 20% construction. Most places you find it a 20/80(60+20) split. 20% planning and thinking, 60% coding, and 20% fixing the code because they didn't plan enough. Teams now using agile methodologies wrong are doing 5% planning, 60% coding, and an additional 60% fixing. Making the project end up with 120% coding time.
They also end up with no roadmap to the code. That roadmap being documentation. Of course the teams that don't know what they were doing, ended up with bad roadmaps anyway, so who cares if you don't have one when you are done.
If you have been doing RUP, UP, or even PLE (Product Line Engineering) right, you have always been agile because you have taken the time to create an architecture that allows for it. A lot of the companies I talk to today do not understand that an agile process is only as agile as your architecture allows it to be. So you ask what are these teams doing that don't need to create an official architecture? They are golfing with a 7 iron. They are good enough and have gained enough experience to be able to build an architecture without the entire blue print. That does not work for the average team. They need the blue print.
What you will find is that the average developer can follow a well done blue print, but very few can read minds. And no, talking about it in little groups with your thoughts on an index card and then all running back to the same room where you can't think straight unless your head phones are good enough to drowned out the noise does not add value.
The blue print also adds value the modifiability of the project, meaning it can have a healthy maintenance phase. A project without the proper blue print is a legacy application the day it is delivered. I don't care if you have tests around the whole thing or not.
Processes are tailored for a project. Always being low ceremony does not work. Low ceremony does not have anything to do with being agile. Agile is an enabled state that is only accomplished through experience. It can be learned, but absolutely not by doing less.
The teams of gurus that decided to put the Agile Manifesto in place, can make software just as well with a high ceremony RUP, or even the dreaded waterfall, as they can smashed into a room the size of a closet with whiteboard wallpaper doing it XP style.
XP was one of the silliest movements I have ever seen. Hey, look at us, we can do software blind folded. It's like Tiger Woods taking me on with only a 7 iron. He will still kick my butt. It seemed like a movement to make things challenging for the pros who got bored doing it the easy way.
I am not saying being agile is bad. What is bad is the branding of agile as something that is new or different. Some new techniques that are useful came out of the movement, but it is time for the movement to die. Please die!!!!!!!
Just like you can't take the RUP and make a team of inexperience developers make good software, you can't take that team and expect them to make good software using XP. Odds are that would just confuse everyone to the point that they don't know what is going on in the process as well as with the product they are trying to develop.
So I guess my point is, processes have not changed the end result of what makes good software development happen. They have renamed things, moved them around, removed things, and added things, but in the end it is the team that knows what it is doing that gets the job done. That includes knowing how to elicit requirements, document the requirements in a traceable way, knowing the patterns that are common to the domain issues and are available in the given technology in order to put together a solid architecture, how to do unit testing or TDD the right way, how to have some sense of pride in developing bug free software, they know how to communicate, they look out for the customers best interest even when it will tick the customer off, they also know what the goal of the project is which enables them to set the proper level of ceremony , and most importantly they realize that nothing is invented, it is only discovered, especially on a software project.
Of course the list is even greater than above, but the point is you either know how to do the tasks in the process right, or you don't. Just doing them is not good enough. So this agile attitude of "Since process activities don't work, let's get rid of them" does not do anything for the team that didn't know how to accomplish the tasks right in the first place. It just displaces their lack of skills to different task. I have seen tons overly bloated software out of agile teams because most teams use agile as an excuse to go right to code.
I personally have found the 80/20 split works best for me when I have an experienced team of developers. That is 80% planning, doing an architectural synthesis, and other prep work, and the 20% construction. Most places you find it a 20/80(60+20) split. 20% planning and thinking, 60% coding, and 20% fixing the code because they didn't plan enough. Teams now using agile methodologies wrong are doing 5% planning, 60% coding, and an additional 60% fixing. Making the project end up with 120% coding time.
They also end up with no roadmap to the code. That roadmap being documentation. Of course the teams that don't know what they were doing, ended up with bad roadmaps anyway, so who cares if you don't have one when you are done.
If you have been doing RUP, UP, or even PLE (Product Line Engineering) right, you have always been agile because you have taken the time to create an architecture that allows for it. A lot of the companies I talk to today do not understand that an agile process is only as agile as your architecture allows it to be. So you ask what are these teams doing that don't need to create an official architecture? They are golfing with a 7 iron. They are good enough and have gained enough experience to be able to build an architecture without the entire blue print. That does not work for the average team. They need the blue print.
What you will find is that the average developer can follow a well done blue print, but very few can read minds. And no, talking about it in little groups with your thoughts on an index card and then all running back to the same room where you can't think straight unless your head phones are good enough to drowned out the noise does not add value.
The blue print also adds value the modifiability of the project, meaning it can have a healthy maintenance phase. A project without the proper blue print is a legacy application the day it is delivered. I don't care if you have tests around the whole thing or not.
Processes are tailored for a project. Always being low ceremony does not work. Low ceremony does not have anything to do with being agile. Agile is an enabled state that is only accomplished through experience. It can be learned, but absolutely not by doing less.
posted by tadanderson at 6:39 PM
1 Comments:
Amen. Use common sense, be practical and pragmatic. Keep it as simple as is required by the project the team and the culture.
Post a Comment
<< Home