Agile - Clearing the first misconceptions

Addressing the most common misconceptions or mental roadblocks for the lead

1. Water fall works then why Agile?

- We agree that water fall works, we agree even more that agile works better.Waterfall models forces us to enter in a contract based relationship with the customer.Instead Agile model is more inclined towards collaborative working.In agile, with the shorter iterations delivering working software, the customer can get a feel of what they would get and could ask for changes early. One reason Agile came into picture is because it is a better model to incorporate frequent customer change requests.

2. How to ensure quality in 3-4 weeks iteration?

- Being Agile on the project management is not enough, Agile has to work from individual contributors till the management. The individual contributors need to be educated about Agile development methodologies like TDD, User stories, etc.

3. It is not possible to deliver some thing in 3-4 weeks

- This perception is due to past experiences in water fall, which is more focused on task completion than deliverable. In Waterfall the word "deliverable" is not uttered in the first 3-4 weeks. Here is where the basic difference comes, Agile talks about deliverables as agile believes in working software than documentation or code. In order to deliver some thing in 3-4 weeks, right from the lead to every individual level would have to contribute deliverables. Larger deliverables are broken into smaller ones.


4. How to get the more frequent client involvement?

- One of the requirements for Agile to be successful, is to have the client involved on a regular basis. If the client is not ready to receive the iterative deliverables, agile is not useful to the client as well as to the team following Agile. If for some reasons meetings do not happen with the client regularly, other ways to get the client involved to actually see the deliverables in effect is a must. For this other mediums like a audio video recording of the working software could be provided. This may help in getting the client interested to actually work with the deliverables and suggest their feedback early on itself.




Addressing the most common misconceptions or mental roadblocks for the individual contributors

1. How can 3 weeks suffice for delivering some things

- As far as individual time line is concerned. This is not a big change. Developers in Watefall model also have tasks assigned for 1/2/3 or max 4 weeks. Agile is all about changing the developers mind set from tasks to deliverables. As the developers role changes from completio n
of tasks to deliverables, they become responsible for the deliverables. In this sense they are more productive and start thinking from what really matters to the customer.

2. Daily Stand ups or Scrums - What a waste of time?

- Developers or QA testers wish to be more productive and they perceive meetings as necessary management evils. In case of Agile, the meetings are focused for individual contributers and are meant for individual contributers to provide feedback, status and put forth their roadblocks. Daily scrums are not only status update meet to report to the lead, but to provide possible risks seen by the individual contributors and corrective planning to allow individual contributor to be more productive. This is also the place to change priorities based on the daily situations

3. Updating Status on Wiki - We meet daily then why this additional overhead.

- The Status update on Wiki helps two purposes
a. Tracking Progress
b. Acts like a record, that can be used for future estimations.

Instead of shooting a email (which is hard to track), updating a wiki page, takes the same amount of time.


4. TDD works only in Theory

- Most of us acknowledge TDD is helpful, but most of us again would not take dedicated effort in that Direction. TDD (Test Driven Development) even though is easier said than done, the benefits of TDD against not doing it (as it requires time and effort) is way more than the consequences of not having TDD.
One misconception with TDD is that people think that TDD has to be implemented for even existing code. Writing TDD for existing code/legacy code is some what a non feasible operation. Instead the idea is to have strong integration test cases for existing/legacy code and follow TDD for the new development you would do.

Agile Story - Scrum Panchatantra

Effectively executing Daily Scrums
Instead of reading one more article on Agile, let's see conversation that takes place in an Agile team during their Daily Scrums.
Let me introduce you to our Agile team under observation.

	King Frog - Agile Lead
	Tom - Agile Developer
	Missy - Agile Developer
	Hog - Agile Developer

---

10:30 a.m : Day begins .....

	: Let's start with our Daily Scrum
	: Who would like to start?
	: I would! Yesterday, I completed test cases and implementation for my XML configuration module. Today I plan to integrate it with the system. I do not have any road blocks. Basically my world rocks!
	: I was supposed to work on the Mysql DAO module, but I got stuck with a Mysql transaction problems. I have written to the Mysql forum, I expect a resolution by today. This means by yesterday's task of integration with system does not complete and I will have to work on it today also.
	: Ohh!! that means I can not start with my service layer. Well I wrote the interfaces for the service layers yesterday and today I wanted to write the implementations, based on Mysql DAOs provided by Hog. That means I can not work on what I planned for today and tomorrow :(.
	:So do you have any thing else on plate, which can be done in 2 days time?
	: Well, yes indeed, I was coming up to that point. I was planning to write client code for my service layer. I was to myself write a stubs for the Mysql DAO. This will help me test the client code also. I was planning this at a later time, but looking at the situation now I can very well continue on that task for today and tomorrow. /my immediate plan would be : Today I work on the DAO stubs and tomorrow on the implementing and testing client code for my service layer.
	: Good to know, you yourself could plan out things for you
	: Well that's what I have learnt working in Agile for a year. I know I have to contribute deliverables instead of just doing my tasks. I also know I am responsible for it.
	: Great!! My turn now, Yesterday I did code review for Tom and wrote test cases for Hog (in pair programming). Today, I am preparing the deliverables which we will demonstrate to the client in Tomorrow's call.
	:But the Final Delivery is months ahead, What's the point in doing a demo now?
	:This way we will know early whether the client approves these features, if yes great. Even if there are some changes, it won't cost us so much at this course of time. In the worst case if the client doesn't want a particular feature to be put in at all (after getting a feel of it), only 1-2 weeks of work is wasted.
	: So we have the meeting with the client tomorrow? but I heard that he is out of town and won't be available for tomorrow's meeting.
	: Ohh! yes I remember now. Well in that case, let me send him a audio video recording of the demonstration. This way the client would be up to date on the most recent deliverable. Also, I will reschedule the meeting some other day in this week itself. Getting a feedback from the him on our deliverables is very important for our Agile Story to succeed. Lets get started on our work, Team!! Ribbet !!

Did you observe?
1. The conversation indicates the team's approach is bottom up
2. Changing prioritites is accepted in a very positive way
3. Individual contributors play a bigger role, than just focusing on one's own task.
4. Every one is watchful for risks coming up from dependencies, also every one seems to be able to come up with mitigation plans
5. Client involvement is on a high priortity
6. Every one knows what every one else is doing

Myths about time and material model

Myth 1 – Iterative product development using agile methodology must be done using the T & M model. “Fixed bid agile” is an oxymoron.
T & M has certain intrinsic inefficiencies listed in the myths below. It works better for outsourcing work to “body-shops” than to the tech savvy providers of product development service. It is possible to do agile development in the fixed bid model using the first iteration to elaborate requirements and estimate costs. DSDM ( www.dsdm.org ) which is one of the agile methodologies prescribes this too.

Myth 2 - Fixed Bid model can’t whereas the T & M model can address loosely defined requirements which is the case with most of the product development work.
Nothing can be more untrue than this. Most of the customers and product managers know most of what they want when they decide to approach the developer. Many of them have elaborate requirements document covering most of the core functionality to be delivered. The developer can estimate and submit a fixed bid on the basis of such a document. Its true that requirements change and estimates need to be revised and the requirements document becomes outdated. But having an outdated document and an initial estimate is better than not having any document or estimate.

Myth 3 – Customers own the team and the IP held by the team-members. Team member’s tacit knowledge is more valuable than explicit knowledge stored in the document form.
Agile gives more importance to people over processes and working code over documents. But relying on people as the only way of holding IP is dangerous particularly when you are using off shore teams where factors such as attrition and low loyalty and low experience need to be accounted for. Teams must maintain documents that give insight into the code being developed or else it will be difficult to induct new members into the team.

Myth 4 – Why spend time on elaborating requirements, design and delivery plan as required in case of the Fixed Bid model? Requirements change; thus making the design documents outdated and throwing the delivery plans off course.
Design documents not only record what is going to be delivered in the code but also force the developers to organize their thoughts. Similarly not having a plan with milestones and completion dates is not a good idea. Over all management and cost control would be difficult without a plan. Design and plan documents provide the basis of comparison to estimate extra efforts required when the requirements change. Story point based flexible plan with no completion dates can lead to “gaming”.

Myth 5 – Delays happen mainly due to the phenomenon of “requirements creep”; hence customers must allow teams to postpone part of the time-boxed deliverables to the next sprint – in other words, customers pay for the delay.
Developers should share the risk of such delays too. Its the developers’ responsibility to extract requirements in the first iteration by asking the right questions. Quick methods of estimation such as “Planning Poker” lack the opportunity for product owner to go back to business analysts and other customers for answers to some of the questions posed by the developers. Time boxing prescribed by the agile model is possible only when enough effort has been taken on elaborating the requirements. Leniency on what is delivered in each sprint leads to inefficient utilization of development resources and hence it should be avoided. There should be some restriction on when and how much to re estimate.

Myth 6 – Test Driven Development. Unit tests can always be written before code and they serve as a substitute for an elaborate requirements document
Many a times developers can’t think of a test before they write the code. By their very nature developers think of “how things work” unlike the testers who think of “where things can go wrong”. Unit tests coverage is rarely 100%. Developers decide not to write unit tests for certain functionalities under extreme time pressure. Unit tests can become outdated just like design documents and are even harder to maintain.