Archive for the Business Value Category

7 Ways to Fail to Deliver Potentially Shippable Code at end of Sprint

Posted in Agile, Business Value, Release Planning, SCRUM with tags , , on September 30, 2007 by vikramadhiman

Before we address the question of how to *not* deliver “potentially shippable code” at the end of the sprint, it would be interesting to define what is “potentially shippable code“. I don’t know where I read this definition – “potentially shippable code” is only a sprint away from release. Whether or not the code is actually shipped or not would of course depend on does it make *business sense* to ship the code right now or after doing another sprint or two. As you are developing based on prioritized set of features and delivering “potentially shippable code”, you are never far from release. However, you are not reading this blog to find out how to produce “potentially shippable code” at the end of each sprint. Rather, we will discuss how you can through lot of “painful, slow and planned” effort not deliver “potentially shippable code“.

  1. Step 1: Do not define DoneLet everyone define what “done” means without communicating on it
    Customer expects to see a tip top UI that functions perfect
    Team is busy building backend and code behind files with lousy UI
    Management thinks the team is building the code that can be supported
  2. Step 2: Departmentalize and Compartmentalize work to be doneYou have to make sure that work is divided in various departments who can blame each other at the end for a job not done. Here are some steps you can take to ensure that:
    Take Quality out and place them in another department with procedural barriers to collaboration among the two teams
    Do the exact thing with UI designers
    If you can do it, divide the work along horizontal layers like database design, business logic design, interface coding etc – the more you can, the better it is
    Do not forget to add ceremony and processes on how different departments should communicate with each other
    You don’t need to include technical writers, UI review surveyors and other support functions in each sprint – have them learn about your months long project in 10 days and churn up some documentation and reviews
    Doing it last minute and hurriedly without a review is the most important thing here
  3. Step 3: Insist on elaborate upfront design documents and architecture designs – Ensure that team worries more about “how they will achieve goals” rather than goals themselves. You can do that pretty easily. Think of the latest modeling techniques and use it to model. Other steps you can try:
    Define all the tasks and their dependencies upfront
    Think about the design rather than what the design should help achieve
    It will help if you can spend a lot of time defining the architecture
    Make developers just Architecture to Code converting units
  4. Step 4: Write crappiest possible code that no one would dare to touch in future – This one take special art, after all by the time anyone will touch the code you wrote, you would be in your third job already. Still, you must plan out in great detail processes which help you write the crappiest code possible:
    To ship potentially shippable code, the team not only needs to work on prioritized features, but also maintain a good velocity – so do everything to ruin it
    Write crappiest possible code [no comments, no standards, no reviews]
    Drive developers to guard their code like treasure
    Make developers horrified of others code [success: this was not my code, why should I fix these bugs]
    Make sure your code breaks the build when you check that in and try doing that the last thing in the day
    Make sure your code has low cohesion and high coupling so that any change in any part of code goes and affects totally unrelated part of the code
  5. Step 5: Code first and test later and if possible leave testing for another sprint – Who wants to do any testing, thats the lowest possible denomination of tasks in a project. Testing is not as sexy as design, analysis, coding and processes. Also, what value does testing provide to the organization or project. Hence, you should make sure your team treats testing as just a necessary evil that has to be done because processes say so. You should try the following to keep this evil as away and as low as possible:
    Testing should be done at the end of the sprint or if possible in the next sprint
    Make sure you don’t write any test cases so that testers have to go through the code and functionality manually each time they do the testing
    Ask testers to test even the smallest change you make to any functionality
    Make responsibility of testing only the QC departments – you are here only to code
  6. Step 6: Change and chop team/ developers – Who wants stability? Management wants flexibility and pre-sales team wants to show developers for new projects. Hence, take as many developers as possible and get new work or shouting customers out of the way. The silent and steady projects mean that they are just too easy to manage and can do with resource snatching. Hence, its important that your developers are constantly changed and chopped between projects between sprints if you want to fail. Additionally, make sure testers, designers etc are changed as well. If you can manage to change SCRUM Masters and Product Owners between the sprint as well, nothing like it
  7. Step 7: Make the same mistakes over and over again This is important. It’s going to be no use if you make the carefully planned mistakes outlined above and then go about fixing them. Make sure you only discuss what’s going to be served in next sprint retrospective and blame every one else but yourself in Sprint Retrospectives. Do not focus on above issues.

If after trying all of the above, you can still produce “potentially shippable code” at the end of each sprint, then please call me. We will create a new software development methodology 🙂


Business View, Learning and Evolution

Posted in Business Value with tags on July 14, 2007 by vikramadhiman

Viewing IT project [howsoever small] as business projects is one of the fundamental shifts that we as a team have noticed since we have been exposed to agile methods.

Earlier we used to treat all projects from purely technical viewpoint, not considering enough the problem what we are trying to solve from business perspective. Our role as solution providers was about how we implemented a cool AJAX feature; used service oriented architecture or used n-tier architecture successfully. Rarely, if ever did we consider that will the system attract many users, will users browse beyond the first page, would search engine bots come to the website and get so confused that they would never index more than 5 pages. All this has changed ever since clients have been sitting next to us as we develop and the focus has been on people who will use the system to do the tasks rather than on “users”.

Another offshoot of the business thinking has been to plan activities using concurrent design methods from first sprint itself. We do not optimize the website for search engines/ usability only after the website development is over. It is an on-going process. Although it means that something does not get built overnight, but when it does, it’s generally robust and scalable.

We do however realize that we can not possibly get everything done at the outset itself. Some things you learn only after the system has been in use. However, we are happy that we are on a cycle where we do learn it each time and have something new to contribute every time. It keeps the team morale high and the client is more than delighted. Now only if we could learn to get there just right enough each time and on time, it would be great.

Release Planning and Business Value

Posted in Agile, Business Value, Release Planning with tags , , on July 4, 2007 by vikramadhiman

Is it important to think of Release Planning in the same breadth as Business Value? Our readings and discussions over the last week seem to suggest – Yes.

Generally speaking, a release can comprise of one or more sprints/ iterations.

  • Can we make an assumption that a sprint really is a release?
  • Can we release something every sprint? Also, is release a product release or just a demo to a client ?

Like all Agile Development practices, it seems that the idea of keeping track of sprints and releases separately has its origins in product development. However, it also seems true that all the projects can probably benefit from this not so subtle difference. Even in these days of software as a service [] the importance of planning a release can not be overlooked. Release planning really is just a collection of stories organized in order of priority and bunched together so that each such collection can be released [i.e. end users can start using the website]. The sprint however is just a collection of stories that the team hopes to complete within a given time period. However, even at the end of a successful sprint you might not have a product or software that you can release for use by potential users or subset of users.

This is where Release Planning comes in. The emphasis of release planning is business value. The team should not think that a sprint and building features by priority is enough to give a business value. The business value comes from getting users to use the software [or probably want to use the software]. Anything else, no matter how organized and dynamic an environment it creates, does not work from an Agile perspective.

Agile Estimating – Part D

Posted in Agile, Business Value, Estimates with tags , on May 20, 2007 by vikramadhiman

I posted the Part C of this series on the SCRUM development yahoo group. There was in interesting discussion on the same in the group. The general crux seemed to be:

1. Team do not generally over estimate. If anything they underestimate. There may be some minor variations depending on recent experience of teams with some clients or features [using Atlas AJAX framework with dot.Net 2.0 takes more time] or team composition [our lead QA just resigned and new QA would take time to understand features and functionality].

2. Generally, all successful teams have a common minimum time that they would take to do a particular work. The fact that others bid lesser than this, does not mean they are able to do it in less time.

3. Sometimes, the teams might have past experience or know of a smart way to do things, that makes them able to bid lower than competition

4. Organizations can bid lower on a large project which would have many change requests and variations during the project, making up for any low bid. There may be projects where total final cost to the customer.

5. Some truly lean organizations can have low overheads and better programming frameworks like RoR which help them develop software at better quality and faster.

However, the fundamental question I am trying to answer is how do you reconcile competitiveness [quality at a price I presume] and profitability. Some of the suggestions regarding the same are as follows:

1. One is to offer a contract where the client pays per iteration. After each iteration they choose whether to keep going or stop so rather than locking them into a 6 month or whatever project they can stop if they are not happy after 2-4 weeks. That way the sunk cost is lower and their deadline is ages away so they can give the job to someone else with little problem. Usually 1 or 2 iterations is enough to convince them to keep going though. [from Dave] But none of the projects like Youtube, Google or any other successful project had full functionality in the first go. So one should underbid, but not on price but on functionality. We should do what agile does best: deliver an utterly minimal system that still meets the PO goals in the shortest amount of time. Stress the fact that they could be seeing results in as little as 3 weeks into the deal.

2. Emphasize the quality aspect of Agile teams, any past knowledge by which you can demonstrate how going Agile helped a project in the longer run would at least bring customer to the negotiating table.

The problem (or requirement) with [1] is that you need to orient your proposal more towards how it will help the customer to get some basic features out first. You will truly need to get into customers requirements and uncover the risks that a fixed price project would pose. Preferably you can convey that a minimal risk does exist, but you manage to tweak the requirements so that you’re really the only party that can sensibly deliver anything suitable at all. That way you don’t have to compete on equal terms on the bid.

The problem (or requirement) with [2] is that you need to manage knowledge internally very well. Not only should you demonstrate how your past knowledge in a field would help you suggest/ build a better product but also demonstrate how it has helped you do so in the recent past. The difference is important to realize.

Having said the above, it is also probably important to realize that not all customers are good customers and there are some you could do without. Whether or not a customer fits this bill is something that only a particular organizations context determine. On most customers, you need to work on making them understand why you recommend going Agile and T&M basis.

It is also important to have the right people articulating this message. A sales staff that can tell customers to go to hell in a way that they look forward to it is just ideal.

Agile Estimating – Part C

Posted in Agile, Business Value, Estimates with tags , on May 15, 2007 by vikramadhiman

A client recently remarked to us – “You have made us very expensive. I lost a deal when the client came back and told me that you are twice as expensive as your competition”. You obviously wonder, how are others able to do things in half time? Why are we not able to do it? And because we are not able to do it, we can’t estimate lower as well? Then how are others able to estimate lower and complete it in less time as well?

Is it a factor of more efficient developers or cheaper resources or both? Efficiency would probably be a factor of the quality of resources and whether or not can they help us [team/ organization] become successful. However, if we consider that developers themselves would be efficient/ profitable without any organization commitment and involvement in the same, we would be missing an important parameter in the analysis. How do we make a fresher a productive/ efficient resource? Do organizations make/ break people into bad or good performers by their culture?

Agile focuses on team empowerment and responsibility. The idea behind the same is that people who are near to the core of the problem would be best able to do a particular work best. Organizations should focus on an empowered, charged, learned, learning and motivated workforce. The above are also the part and parcel of the culture of an organization. An organization that does not take competitive edge as its mantra can not succeed in the long run. Its the quality that counts and decides metrics for productivity and efficiency. Quality comes from quality people – the best talent is attracted by the best talent and it performs in the right environment.

When we talk of estimates, we must also talk of organization culture and competitiveness. The best method to do the same seems to be continual learning/ empowering of the teams to define a culture that makes it competitive. Its not client’s business sense that Agile teams needs to embrace but organization business value needs to be factored into their performance as well.

Agile Estimating – Part B

Posted in Agile, Business Value, Estimates with tags , on May 7, 2007 by vikramadhiman

We have been trying a new technique over the last few weeks with regards to our estimates. Rather than get an expert comment on how long they think a project will take [in number of hours] we have been asking them to estimate specific activities in the project:

a. Business analysis – the scope of effort in a project is described and documented. This includes prototyping, wireframing, use cases, stories, backlogs and occasionally technical specification documents
b. Development – how many developers for how many months
c. QA – How many testers for how many months
d. Graphics designers – how many design elements/ design scope and how many designers for how many months
e. Project Manager – scope of the project/ timelines and per month time to spent by the PM

This has made our estimates go up by at least 80%. Of course most of our clients do not see the bright side of right estimation at present. We are trying to find the right kind of clients. Of course, we have yet to ask the question – is the right estimate how much time we think it will take us or how much time it should take us.

Agile Estimating – Part A

Posted in Agile, Business Value, Estimates with tags , on April 28, 2007 by vikramadhiman

<a href=”; mce_href=””&gt; <a href=”; mce_href=”; >

Agile estimating is supposed to be a democratic and simple process:

1. Write down some user stories
2. Get a group of people together
3 Explain [if required]
4. Play a delightful planning poker game
5. Estimate in story points
6. Apply a conversion factor [derived historically]
7. Compile the points

Details of the software are available at and the game itself is available in a web based version at

So, why is that despite a Business Analyst leading the Agile Project Management movement in our organization, we still have estimates that go wrong horribly? Here are some ramblings from the internal cogitation in the mind:

1. Fixed price estimates: Agility and fixed price estimates seem very different from each other. Agility is responding to change, while fixed price estimates seem to come with fixed specifications as well [well we do know that no specifications ever are going to be final]. One of the suggestions has been to do fixed price estimates with a fixed time period too. I am not sure if that cuts the ice with the customers either who seem to be saying “What can we do if you guys screw up our project and not complete it on time?”

2. Too low time spent on estimates/ proposals: Agility bug has bitten the pre-sales department too. A week is very long time in turning around a proposal especially for low budget projects. Hence, there is less time spent on drafting and importantly discussing the proposal specifications internally and with the client. The result is half baked specifications which go more into how [there would be a text box to allow the users to enter a category] rather than the why. The business process problem/ competitive analysis and importantly domain model – largely stable issues for small budget projects [thereby meaning most of the time small duration projects as well] are often not explored in sufficient detail. An attempt is made to use the historical data for estimating rather than actuals to come up with estimates.

3. Agile environment: An agile environment is very receptive to dynamics of business and requires a very fast response. Fixed price estimates and specifications on which they were based [the same then drives project schedules and milestones] inevitably lead to discussion and heart burn between the team and the client over what is quotable and what is not. This destroys the very basis of Agile – “Customer Collaboration”. After a while the customer distrusts all estimates and milestones, and gets into a bargaining mode.

4. Upfront estimates: Fixed price estimates are always upfront estimates. This means that you generalize everything to result in a utopia kind of environment – average if not perfect developer competence, consistent developer availability, no attrition, knowledge management, code reuse, regular client feedback, no QA issues or regression. This never takes place in a live project. Hence, the idea of a fixed price estimate [upfront estimate] that is ingrained in stone does not seem to work.

Having looked at this, what are the possible workarounds and “art of the possible” strategies for the same? Let’s explore tomorrow or next week …