What "Done" means?

Is it Done? This topic that is constantly reoccurring in the (agile) software development community.

Done is a magic keyword, with different meanings for different people.

• For a business owner, Done means that the product is running and serving Customers
• For a project manager, Done means that the code is implemented, tested in all testing cycles and delivered
• For a development manager, Done means the code is implemented according to standard, commented, unit tested and deployed in testing environment
• For a developer, Done often means that the tricky algorithms work, code compiles and was checked into Source Control. The HARD part is over and the code CAN run.

Here's a sample definition of Done for a Task (via scrumalliance) :

1. Coded/implemented
2. Peer reviewed (pair programming counts as peer review)
3. Code is run against current version in source control
4. Code is commented in source control and checked in
5. Code is commented on Public/Friend methods
6. Story/use case manual test plan updated
7. Unit tests written and passing
8. Build and package changes are communicated to build master
   
9. Task list hours are updated and task is closed out
10. All to-do items in code are completed

We need to establish a scale of Done, so that we can rate our "donnes" clearly, just like a good stake house does.
Oh, Sorry Sir, you didn't ask for a rare rib eye? My apologies, let me fix it for you! (The staff in a good stake house doesn't usually point out that the meat is properly cut, is very well seasoned and the last piece missing is a bit more heat. The stake is simply not done well).

In agile development, Team has a lot of sovereignty to make decisions and drive the implementation of Tasks. It takes an ownership of the Tasks and makes the implementation as good as can be.

But the Team also needs to clearly communicate the level of Done, as different stakeholders have different expectations. Only when the communication is clear, factual and correct the mutual trust can foster.

Let the Water fall

On Waterfall software development methodology












Fig-1 Waterfall phases


So Waterfall is GREAT, right? It is GREAT for its risk mitigation ability, it is GREAT to produce bug free software and it is GREAT to produce mission critical software. It plays extremely well in regulatory environments. Above all, it is GREAT in maintaining of Status Quo in order to keep the aforementioned virtues of a system.

It runs Space Shuttles and it got us to the Moon.

Every phase is dependent on the completion of the previous phase; we do not code unless we have gathered requirements, analyzed it, and came up with design already. This gives Waterfall very SOLID structure, gives a big deal of comfort to organization that a project will be eventually completed, with all Ts crossed and Is dotted.

Auxiliary control mechanisms and directional layers and reporting structures are deployed alongside all of the phases, with very little overlap to boot. Testers do not have to care about development till the day they get the custody of the code that needs to be tested. Each phase is taken care of by a different group of people; roles and responsibilities are finely defined and distributed.
Each phase feeds into next one and one run through the mill and we are done. Unless...


The Waterfall is BAD, right? It's BAD because it is HEAVY, oh so SEQUENTIAL and downright stuck in the last century.

All the virtues of Waterfall come at a significant cost. Many people, often many organizations collaborate during Waterfall phases. Due to the great isolation of the Waterfall phases, communication becomes an overhead and bureaucracy prospers. Cost spirals, fat grows. Each of the phases is becoming longer, synergies are absent. Evolution of the product and keeping with the times are difficult - that's the price of a great Status Quo watchdog. We do get a bug free, mission critical software, though. Unless...

The most important and often overlooked aspect of Waterfall development sits right in front of our eyes. On the top of the pyramid. Basking in the sun. That's right, the REQUIREMENTS. It is the first coin we insert into the slot machine and it decides on the outcome. Crooked pennies do not need to apply. Weight of the coin needs to be precise, so does the width and diameter.

Waterfall assumes that requirements are exactly specified, are understood by all parties and do not change. Change the requirements and any of the phases will come to a screeching halt. Either you can restart the whole process or you take a shortcut and circumvent the rigid and fail proof process.
Most of the bugs in the system come from such shortcuts and firefights, negating the bug free property of the process. The system will retain the heavy cost associated with the process but will not be bug free and or fit of the mission critical label.

If you decide to do Waterfall, beware of change. And if there's a single change on a project it will probably be the REQUIREMENTS.

If there ever is a mission critical project with ZERO chance for requirements change, deep well of resources in a highly regulatory environment, I wouldn't hesitate subscribing to the Waterfall process. But I hear they are retiring the space shuttles ...

Agile Values

The four basic Agile values were described in Agile Manifesto in 2001. Brief interpretation of the values follows. I focused on the Working Software value, as it is the most relevant one to me at the moment.

1) Individuals and interactions over processes and tools
It's all about the TEAM which is executing the Tasks. Process and Tools exist in order to support the TEAM reaching its objectives.

2) Working software over comprehensive documentation
Test ALL THE TIME, deploy often and refactor constantly. Code by intention, not prescription. Design as you code and code as you design.

Coding by intention: What do I want to code? What is my intention? Coding starts with Interface as my understanding is vague and generic at first (I only know I need the code to do something and return something else), and evolves into concrete implementation as I learn and understand the topic better as-I-go. I also know basic test requirements from the beginning, so I can start testing as soon as I decided on my Interface.

Refactoring: Did I understand the requirement correctly and is it still reflected in my code? Is it as simple as can be? I rarely get my code spot on from the beginning, so refactoring is constant effort. And it's FUN! Only constant Refactoring creates Beautiful Code.

Detailed Design and documentation: Is often formalized at the end of the iterations cycle in extra iteration called a Landing Strip

3) Responding to change over following a plan
Plan is created and owned by the TEAM, is alive and constantly change after every iteration. If we get behind or ahead, we will know at the end of each ~10 days long Iteration.

4) Customer Collaboration over contract negotiation
The TEAM includes ALL the collaborating parties. On a typical application release we would have a BA and a PM in all of our daily stand-ups (and it would still take only 1/2hr!). Constant collaboration of all parties is more important than signing off "requirements" and delivering "something" few months later.