Note: This article is a work in progress!
So we all have heard about it and may be heard a lot of people and other fellow programmers taking about it.
May be we have been forced against our will to go learn about it or attend a seminar or a course or something.
May be like me, after a few of these courses we have come out and started thinking about it, started reading up on it. It all seems new and interesting and at time evolutionary.
Or may be like me some of you folks have thought “ah its just another way of doing things, and we needed it because the people calling the shots needed somat new”. I certainly have had these thoughts, and at some occasions I have even dismissed it, classing it as yet another fad. But ask me now and I will tell you its not, but its a not new either(been arround for over 10 years now).
I view it as an improvement and an uncovering of better way of doing thing. Well at least I cannot ignore it, because recruiters are asking for this particular skill :).
After a lot of courses, lectures, videos and years of practicing this is what I think Agile is:
Lets start with the Agile Manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
Lets deep dive into the above and see what it means.
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:”
– From this what becomes apparent to me is that the people behind Agile are still “uncovering” better ways of doing things! (just like me or you) they aren’t done with it yet. If they had it would have read something like “we have finally discovered a better way ……”, hence what this tells me is that is an on-going process. Then what baffles me is if we are still in the process of discovery, how can someone say “oh by the way this is the best practice”, we are still discovering, there are better ways emerging everyday. We adapt some practices today which seem better then yesterday and when we discover more better ways tomorrow and we change the old one – Isn’t that being agile? Is this not what being agile is all about?
Next it says “Through this work we have come to value:”
Individuals and interactions over processes and tools
Now I want to stop here and keep in mind “That is, while there is value in the items on the right, we value the items on the left more.”
so on the right “Processes and tools” is important-ish but what’s more important is “Individuals and Interactions”.
“Hummm, can we have individual and interactions, without processes and tools”?
-“Of course we can.”
“So we don’t need processes and tools?”
“In My opinion we don’t need them but if they facilitate interactions, we will have them.”
“Remember its all about the Individuals and Interactions, tools and processes are secondary! If some process or tool is not working, we should be able to change it”.
Being Agile also means to do the simplest thing that works , and that does not mean just in code. We can also follow the simplest process that works, chop and change procceses to fit the context as we go along. Simplicity is at the heart of Agile.
Andrew Hunt in one of his talks once said: “Agile is ever-changing, ever-shifting and ever-responding.”
So when we say we are agile we should be ready to change, shift, and respond and that includes all layers from project management processes to code to testing and delivery.
If something is not working lets change it, let’s be agile. And for me this can only be if we do not lock ourselves down into tools, processes and plans.Think about it, when we have a plan, why we always have plan b. Planning was a characteristic of the waterfall model.
Here is something to think about: “Practices can never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real-time” – Dr Patricia Benner, From Novice to Expert.
“Working software over comprehensive documentation.”
The emphasis is on working software, not on getting rid of documentation. We should have some documentation may be to explain the intent or 10, 000 feet view of the Architecture. What Agile is about is, having the focus on delivering working software every time, not on producing documentation. Yet we are focusing on documentation, on handover documentation, on testing documentation, on process documentation.
Customer collaboration over contract negotiation
Now this is a real topic, first of all what we mean is we need customer collaboration rather than some strict contract with deliverables. We do not get rid of the contract, but Agile is focusing on collaborating the customer at each stage/ each iteration, while working towards some deliverables. Think about it if we focus on the Deliverables, we might as well follow waterfall, get it all done and deliver the deliverables. From my experience what seems to happen is these deliverables seem to change or shift over time and we end up chasing a moving goal post. The backlog always fills up at a pace far faster than we can clear it, because someone out there is managing it and hence shifting the goal post. We can’t really respond to change if we just put that change into the backlog.
So what should we do? To Answer this, let’s for a moment think why the backlog is there?
“Because when we were doing the project, these issues were not important and we just wanted to get it out in a reasonably working order. Hence we pushed these issues to a later stage “A Backlog”. These were supposed to be done after the project finished and went live”
“Alright, so did you guys do these or fix these”
“No, because, we got new requirements, and some of the contractors left, and It’s not our responsibility any more”
“Responsibility is : “Response Ability” ( The Seven Habits of Highly Effective People, Book by Stephen Covey)
“So who ‘s Response-Ability was to fix these issues and you were the owners of this product, how can you have pride in the work you did, that had bugs in it?”
“If you are Agile, the bugs should be fixed after each iteration, if they are on a back burner , that’s ok, but they should be fixed as part of your sprint, remember the boy-scott rule”
“Responding to change over following a plan”
You can only in real terms respond to change quickly if you have a very loose plan. Because when the change come in the plan automatically has to change. So it’s no point following a long term plan. I know, we need to have a working order, we and people above us need to know what we working on. so why don’t we let them decide the so called plan, we as a software development people involve them at every stage and iteration to keep that feedback loop running.
Estimation is sort of plan, when you estimate a story into points or hours or number of cups of tea, its one and the same things. A story point of 20 means its complex , which in REAL terms means its going to take me more time. So complexity is converted into time at some point or the other. All answers will have to be in time at some point. So why not cut the crap and get straight to it.
Should a Story with 20+ points really exist? if it does break it down.
when its smallest it can be, estimation is not estimation anymore, its becomes factual.
When do you know the more about the project or an issue? when you start doing it, so why estimate only once at the start of the task. Why don’t we re-estimate it middle way through.
I always ask “What does the velocity translate to?” one of the answers is “Number of story points we can complete in a sprint”,
“how long is the sprint?”
– “2 weeks”,
“2 weeks is a time, hence number of story points we can compete in 2 weeks”
“So we are thinking in terms of Time?”
-“Well yea, but……………..”
I know and I understand the logic but I think the process is too blotted and spray painted with lots of buzz words. Estimation should also be Agile, change it if you thought it was wrong to start off with , I think you should always re-estimate.
Sprints are there so we can deliver at the end , not because we can have a testing phase at the end, that’s just waterfall.
Estimation is what we did at the start of the waterfall projects. And now we are doing it at the start of the sprint? what is the difference?
Plans do have a purpose, In my view planning in Agile should be short.
Long term planning should be in place just on the product level and best managed by the business. In terms of software development teams, plans should be very short as short as they can be. This allows for the plans to be agile.
Below are some links to some interesting reads: