ronwidhaAgile is not TDD
A few days ago, I attended a user group event Agile open forum discussion, which lead to a couple of interesting topics that I'd love to elaborate on the next couple of blogs.
On this particular post I want to focus on how I understand the essence of Agile, and address the common misconception how Agile is ALOT more than just TDD.
Agile for agility
Agile is about achieving agility. With the ever changing landscape in economy, rapid pace of innovation in technology, it's even more important to embrace change. As Robert Collier said
Regular releases
Agile is about focusing development on demonstrable feature, which allows the team to integrate and release often. It gives a chance for the stakeholders of the product to review, give feedback and even change the direction. It exposes problem early and its up to the team to react upon it (it's important to differentiate problems identified by agile as opposed to caused by adopting agile).
Continuous improvement
Having regular releases allow the whole team to re-asses what went well and what can be further improved. Grow as a team. This will allow each of the team member to grow, make better decisions and self manage. The team becomes a living organization.
Identify and Reduce Waste
Apparently (I'm not trying to be an expert in history here-which Jason Yip might be able to help me with), Agile have a strong root from the manufacturing processes. It can be seen from its focus on identifying waste. Long term plans will be wasted when situation change, requirement documents will turn obsolete as direction change.
The Discipline
Being able to embrace change, short term thinking and little documentation does not come for free. This is why many agile advocate will tell you: don't just pick and choose the practices that you want to do.
All these nice characteristics comes through discipline; relentless refactoring, modularise component to small testable pieces, automated testing and continuous integration. They won't be easy, but they need to be done!
[...] is a continuation post to my previous post Agile is not TDD and also somewhat a reply to my good friend @Hammad Rajjoub and his post Agile Discussion : Part [...]
Concur. I tempted to say TDD is kind of over-engineering :) In the environment of business requirement is constantly changing, TDD approach ain't the best. Once upon a time, I wrote software from the scratch in TDD way. It was awesome, I'm so proud that the code is highly testable with high code coverage, but unfortunately business changed their mind in the implementation and require almost 70% code to be changed. Very sad indeed. But I learnt something. TDD is not agile.. That's why I tend to agree with what you say above man.. regular release and continues improvement are far more important. Btw, have you read Joel's Duct Tape Programmer article, in some way im agree on his view which I reckon is more suitable to agile. Anyway, Just my 2 cent.. :)
I have to say I have to bluntly disagree with you Hery. As with my final point: The Discipline, agility does not come for free. I would question a couple of things: 1. daily standups should've caught business changes early. 2. if not, are you sure the right people were in the standups, and proactively engage with the development 3. is the codebase, modularized and easily tested as a small unit? if it is, you should be able to take advantage of the open close principle. Leave the code base intact, create a new small class that does the new requirement, configure your IoC container to use the new class. Any practice will be 'over-engineering' without the proper context. Thoughts?
1. yes 2. yes and no. but i think this is the problem was. 3. yes. im taking advantage of single responsibility principle, open close principle, etc and structure map as ioc. But, what I want to say here: What if the business doesn't even know the direction or what they want. Like in my example, the business wanted to build a product. We'd spent amount of time on analysis and then development. Daily standups and regular updates on the project to make sure we are on right direction. However, in the middle of the project, all of sudden, they asked us to stop the development. They said they wanted to change the direction and the features we were developed were no longer giving any values to them. So they wanted to drop many features and replace it with new ones. What can you do? No matter how good the code you wrote, you have to give it up. Right? My point is: in this kind of environment, I would rather to build something quick and pay the debt later. So, instead of spending time on TDD, thinking about the best architecture, what design pattern to use, and etc, I would pay more attention on product delivery. Don't get me wrong, build quick, doesn't mean I give up some of the rule of thumbs on software development. But, i would rather to go for the not-too-so--the-best architecture. But it allow me to release code more often and faster. Ron, I can feel that, you'll disagree :p Correct me if I'm wrong... :) PS: After I read the blog again, seems my first comment isnt appropriate to the context.
You'll be surprised, cause I actually agree with you. some parts of your argument at least.Firstly, the business might not realize that the original path that they decided one wasn't the correct one to begin with before looking at the finished iteration. So even though there are a huge part of the codebase/effort that goes to waste, it can be considered worthwhile. Without it, the business might not have known the right path. It re-emphasize the point about continous improvement.The best practise+unit test is an insurance, to ensure if the business got it right, you can proceed further with confidence. Agile is about maintaining consistent sustainable speed, not getting somewhere fast.Secondly, what you're describing as do it fast and pay the debt later is spiking/prototyping, and there are times to do that. But the goal has to be to work out what to put in the backlog, as oppose to getting version 1 done.There is obviously alot of caveats, and the points I've given above mostly comes from theory. WOuld love to hear if it's applicable in practice. thoughts?