Tale of a Pragmatic Team

Take the world as it is, not as it ought to be
                                                                                                  — German Proverb

With the passing every single year in the world of software development I find myself more and more convinced of the fact that every project and every team is unique. They have unique situations and requirements. One should accept and adopt tools and processes only to the extent that fits the personality and culture of the project team and caters to the needs of the project. Let me share a tale of a team that I worked with in recent times.

The team was maintaining a suit of unit-tests around the code. Though the code coverage was decent, the execution coverage was really poor. If you ran the test-suit, at any given point, many if not most tests would fail. Not a happy situation to be in, especially, if you are willing to leverage the benefits of units tests. One of the most important benefits of having a unit tests around your code is to provide you with the courage and the confidence to refactor your code fearlessly. You should be able to make a change in the code and run the tests to make sure everything is alright. And this is what the team was badly missing with it’s tests. Any “red” test that we came across would not clearly conclude that weather the test failed because of bad data or the functionality was actually broken. We dug into the each and every unit-test. To our relief we found almost all the failing tests were failing because bad test-data and not broken logic. Believe me or not this is the case with many teams claiming to maintain unit-tests.

We fixed the test-data, created dummies, mocks and stubs where required and made the test-suite hundred percent pass. We would setup data before running the tests and undo the changes to the database (or other states) after the tests ran. Hence, the test-suit always remained automated.

The next logical question then was how are we going to make sure that the tests we fixed this time around would not run into the same issue in the future. The answer was obvious – Continuous Integration (CI). With Microsoft’s Team Foundation Server (TFS), it was fairly easy to set up the build for Continuous Integration. Once we configured the CI, we realized that the builds were heavy and slow as many of these tests talked to the database. It was turning out to be an overkill for the return we were achieving. Again, we followed the “horses for courses” strategy. The pragmatic solution that we all agreed upon was that instead of queuing a build at every check-in, we should trigger the test-run only in the nightly builds. That way we were sure that code integrates at least once every day. Something we happily lived with.

The idea behind telling the story is that tools, process and best-practices are not meant to be followed like commandments. One should certainly look out for and be aware of what’s working for most teams out there, borrow the idea as and when necessary but should not impose them on the team. They should be adopted and accepted according to the teams comfort and adopted as per the teams need.

As you would have already understood that what we followed was not even close to be called TDD. We just maintained unit tests. But at the end of the day we delivered, and delivered well. Isn’t that all that matters? Isn’t it more important to do what works than what is right? After all, isn’t it true that there is no single key for every lock?


Story about User Stories

It’s amazing how people somehow manage to figure out ways to abuse systems that they once so passionately fought to bring in. I recently came across a user story card which had the whole sequence diagram scribbled on it in an extremely small fonts. Interesting work-around, isn’t it? For those who have not seen one, a user story card is typically a 3×5 index card used by many organizations to represent a user story.  The small size has been selected for a reason. The idea behind having a 3×5 index card is to constraint the user story to short and simple.

But user story card is just a part of the story. Let us try look at the whole story itself. Please allow me to tell you the story of user stories.

A user story describes desired functionality from the business perspective; it is the user’s story. A good user story describes the desired functionality, who wants it, and how and why the functionality will be used. I completely agree with Mike Cohn’s favourite Template for writing user story which are short and simple,

As a [user role]

I want [functionality]

So that [reason]

 A user story is comprised of:

1. Card – the written description of the story, serves as and identification, reminder, and also helps in planning.

2. Conversation – this is the meat of the story; the dialogue that is carried out with the users; recorded notes; mockups; documents exchanged.

3. Confirmation – the acceptance test criteria that the user will utilize to confirm that the story is completed.

A very good guideline for writing good user stories is the INVEST model

Independent – One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.

Negotiable – A user story is negotiable. The “Card” of the story is just a short description of the story which do not include details. The details are worked out during the “Conversation” phase. A “Card” with too much detail on it actually limits conversation with the customer.

Valuable – Each story has to be of value to the customer (either the user or the purchaser). One very good way of making stories valuable is to get the customer to write them. Once a customer realizes that a user story is not a contract and is negotiable, they will be much more comfortable writing stories.

Estimable – The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).

Small – A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. A story which is more than that in effort can have more errors associated with scoping and estimation.

Testable – A story needs to be testable for the “Confirmation” to take place. Remember, we do not develop what we cannot test. If you can’t test it then you will never know when you are done. An example of non-testable story: “software should be easy to use”.

So the moral of the story is this. User Stories being the cornerstones for Agile development, deserve their fair share of time, effort and most importantly prudence to be “invested” in them in order to lay a strong foundation for project.

Agile Software Development

When we first started using Agile, we were amazed by the sheer quickness with which we were able to respond to change-requests and issue-resolutions; we were amazed by the ease with which we could accomodate new requirements; and most of all we were amazed by the way we could focus on the grass-root level ‘real work’, keeping all the mumbo-jumbo around software development aside. It was all about being quick, aggressive and pragmatic as a team. In a very short period of time, I had become a big fan of Agile. I always found myself convinced that Agile would work, and till date my openion has not changed. Let’s examine some of the key differentiators of Agile methodology over conventional practices:

More often than not customers do not completely know what they actually want at the beginning of a project. Generally this is the time when the project contract is signed. Obviously, more often than not the development team ends up providing a solution which partially or not at all solves their problem (even if contract is met completely). This leads to a very high degree of dissatisfaction among the customers. Agile software development methodology answers the problem with a simple, common sense driven approach to software development. It allows the customer to have a direct visibility into the direction in which the project is heading. This allows them to correct and modify an existing requirement or even come up with a brand new one at any point of time in the project. The transparency that Agile provides results in a high level of confidence and satisfaction among the customers.
Agile is about embracing change. It encourages you to accommodate change at any point of time. It even welcomes the new one. These changes are then added to the wish-list (backlog). And the list is prioritized again with the help of customers.
Agile is about delivering continuous stream of value. It breaks down the task in small pieces of deliverable which can be accomplished in a short period of time, say a fortnight (this is called sprint). These task pieces are called backlog items. The list is then prioritized with the help of the customer. Small deliverables are released on a regular basis based on the backlog. The customers play with it and give their invaluable feedback.

Agile encourages not to plan too far ahead. Agile does not bother you about planning for too remote a future. It plans for one sprint at a time. This gives the customer small deliverables on a frequent basis to work and play with. This also ensures a frequent feedback from the customer.
“Business folks must get involved”, is the trick we missed out on in the conventional software development models, so to say. We did not get the customers involved enough. This resulted in the project floating like a boat without sail. Having regular input and feedback ensures that the team is on the right track. Important and critical features (decided by the customers) are built and tested first. It is also comforting for the customer because he or she has a clear visibility of where his or her investment is at any point of time.

Agile encourages regular Face-to-face communication. Agile understands the fact that most effective communication is, in fact, face-to-face communication. Hence it’s a practice that the team must meet at least for five minutes daily and discuss about what did they did yesterday and what they are planning to do today. It is also discussed if there is any impedance. This sort of meeting is called a scrum in the agile world.
Agile is designed for high degree of customer involvement, less up-front planning (as requirements evolve), and high degree of effective communication both within the team as well as with customers. Transparency and clear communication has resulted in an unprecedented level of customer.

I find this idea of Moving with the Cheese behind Agile extremely exiting, how about you?