Skip to content

Agile Software Development

Overseas…

So what happens to the agility when the project is distributed? Well, it suffers… It’s not that it doesn’t work in a distributed context. In fact ThoughtWorks has been doing distributed agile for quite sometime now. We talked about some of the best practices of agile earlier. Let us see what problems distributed agile poses to these principles. Time differenceWhen working across oceans, the first thing that hits the team is the time difference. The typical arrangement renders the team to be in a low cost country like India and the client in the US of A or Europe. The… Read More »Overseas…

Agility…

The key practices of agile software development, known and followed are:1. Face-to-face communication over documentation2. Quick feedback from end users over project phases (as in waterfall) Collective ownership, Pair Programming, use of whiteboard, paper, and most importantly the terrific visual representation of the project health and progress… the wall For an agile team the wall is everything. The action of moving stories & bugs along the columns and the instant snapshot of the project health is fantastic. Here’s how it works… The process : The Business Analyst analyzes the requirement and writes a story and acceptance criteria The developers estimate… Read More »Agility…

Value..

Stories being testable and valuable is as important as them being small and independent. Perhaps more… because these are the two important characteristics which in fact drive the size of the the story. Like we saw that an agile analyst can sometime fool himself by creating independent stories, one can also blunder quite easily when it comes to testability and value of stories. Let’s look at an easy example: Imagine a customer entity in a system with about 50 odd attributes. Creating one story capturing all these attributes will be a real mess. An analyst would (and should) readily want… Read More »Value..

Chicken and Egg

Managing dependencies is another tricky issue that plagues agile business analysts. Fortunately it’s not as bad as the chicken and egg problem. The secret to successfully solving dependency problems is to start at the beginning… Well maybe an example will help. Let’s consider a system that sells books online. The roles which will interact with this system, will be– the buyer– user registration– the administrator– the sales team and– the warehouse manager. The most important entity in this system in undoubtedly the book. Starting to write stories for creating a book is an obvious start for anyone. Now this is… Read More »Chicken and Egg

Small Stories, Large Stories

One question that keeps analysts busy for a most of the time is whether or not to split a story. Here’s my philosophy behind my unending support for small stories. Let’s start with one huge story that covers everything that is required to be done in a project. It is estimated by the developers at say 120 complexity points which converts to about 300 days. Following are the consequences. A requirements document (the story) – coupled with the time taken to prepare such a document The techinical discussions and decisions for implementing these and of course the time required The… Read More »Small Stories, Large Stories

Once upon a time…

User stories are the basis of business analysis in an agile project. A user story is an artifact which captures a small but valuable piece of business functionality which can be implemented and tested independently. The philosophy behind agile methodologies is basically iterative development with short & fast feedback cycle which is used in improving the solution and accomodating changes (subject to priority) so that the end result is really what the customer wants. Inevitably this creates a unique position of a business analyst as a broker between the customer and the developer. Writing user stories is what this broker… Read More »Once upon a time…