The Project Owner

I recently paired on an Agile Fundamentals training for an organization. Its a two day course in agile philosophy, principles and basic practices offered by ThoughtWorks Studios. Its more of an awareness programme than training that you can put to use in your daily life. This makes sense as any two-day training that promises "take-away"s that can directly be applied to your situation is probably bogus.

Although the training itself is pretty much "canned" in terms of material, the discussions that happen over those two days are very important. In discussing various aspects with people from this organisation, I saw another instance of an engagement setup anti-pattern.

There were multiple stakeholders in the client organization (there always are) and the IT team was dealing with all of them. There were a lot of conflicting priorities, priorities changed while development was going on, people who made decisions went away and new people made opposite decisions due to lack of context, etc. Here's where I think the problems is but first lets talk about the product owner role for a bit and then we can discuss how this ought to work in a services context.

The Product Owner

In my view a product owner role is defined by two simple characteristics:

1. She has absolute authority over what features go into the product.


2. She is absolutely responsible if the product doesn't work.

To satisfy these conditions, the product owner will show several behaviors.

• Has a clear vision of what the product should be


• Knows exactly what the product is currently capable of doing


• Knows the target market (user segment) and the trends in that market


• Takes inputs from the organization, the development team, the marketing guys, the market itself and base


• Based on such inputs, is able to prioritize between planned features, bugs and new ideas

For a product, this role is absolutely necessary. And companies usually don't go wrong there. But when companies set themselves up for running a project, they usually miss this role. It leads to a lot of heartache for everyone and needs to be taken seriously while setting up the project governance.

The "Project" Owner (for lack of a better name)

Let me try to explain what this role should do in a project context. I will also add some context around each point and why I think its important.

1) The Project Owner should ideally be from the client organization

• Since the product owner is supposed to be the absolute authority on what features are developed, he should be part of the client organization.


• If the product is not external facing, it is probably going to be used by employees of the organization. An internal person will be able to understand their needs better

2) The Project Owner should be fully involved in the development process

• To understand the current capabilities and gaps in the product, the product owner should be fully involved in the development.


• She should attend all the showcases, test the application and give feedback to the development team


• She should be involved in story discussions so that she can give inputs about the best way to achieve a piece of functionality based on her knowledge of the user base

3) The Project Owner should have complete authority and responsibility

• She should be the Business Sponsor herself (possible in small startup like companies) OR be someone who is completely trusted by the business sponsor.


• She will take inputs from various parties but will decide what to do herself.


• She will have to have a strong personality to negotiate within various stakeholders in the client organization to make sure the product stay true to its purpose and doesn't go off track because one of the stakeholders shouts louder.   

 

Common arguments and pitfalls

If I am an IT vendor and I ask my client to create this new (almost full time) role, why would they listen?Well, it can turn out to be a tough conversation with some clients. But the basic idea is the same. The way you ask for time commitment from the client, you should also ask for such a role. Its in everyone's best interest. For some clients, you might need to prove the requirement before you ask for someone to take on the role.

Can it be someone from the IT organization?Well... its better than having no one I guess. But its not ideal because there's a lot of client context required for the role. Maybe a smart BA/PM who is permanently stationed at the client site can do it but its not where you want to go.

Iterations, Batches and Flow

I've recently had a lot of conversations with people who are thinking of iterations as batches. By definition that's what they are. You sign up for a "batch" of stories, at the beginning of the iteration, and you deliver them by the end of that iteration. However, it is useful to think of requirements (stories) as units of work that flow through the value stream. Here is why I think so.

What is a batch?

"A batch is a group of items that will be processed at once as a single unit"

Items are usually batched to achieve "economies of scale". This usually means that there are some overhead activities associated with the items in question and it is better to distribute the cost of such activities over a batch of items than to perform such activities for each individual item. A good example is transportation. It is always more economical to transport a whole container full of items than to transport individual items.


You can batch items up at various levels. Coming back to the software world, you could batch requirements (stories) at an iteration level, at a release level or even at a project level if you must. That's what classic waterfall does, it batches requirements at the project level. But the point is, you need to work on the whole batch at once at each step of the process. Which means you'd prioritize the whole batch, analyse the whole batch, develop the whole batch, test the whole batch and then deploy the whole batch.

So what's the big problem?

Well, by batching items, you are limiting what you can do with each of them individually because as we discussed you have to process a whole batch at once. So where you could have prioritized, analysed, developed, tested and deployed individual requirements (stories), you can now prioritize, analyze, develop, test and deploy only iterations, releases or entire projects.

Flow

Instead, think about requirements (stories) continuously flowing through the value stream. This way you can assess individual requirements and make sure that only the most valuable make it into the value stream. Then you can analyze, develop, test and deploy these faster because they are small. Now all you need to do is take stock of how your team is doing at regular intervals. This is the time when you would showcase to your client stakeholders, check your throughput for the given time (velocity OR number of stories), have a retrospective, brainstorm technical approach, assess technical debt, etc.

And what about those "economies of scale"?

You do lose out on them to some extent. But here are two points to make you feel better because economies of scale are overrated anyways (at least in context of software development).


Firstly, remember that the more you do of something, the better you get at it. So by doing small parts of the overhead activities, you get better and faster at those activities and they don't remain such a big cost anymore. For example, take deployment as an overhead activity. The whole process of deploying to production is usually so tedious and time-consuming that you prefer to do it only when you have a sizable "batch" of features to be deployed. But if you start deploying each story to production, you will have to better that tedious process. You will have to automate most of the deployment. You will have to automate most of the testing. After 10-15 stories are deployed this way, the process will not remain tedious anymore.


Secondly, stop thinking of it as extra cost and start thinking about is as the price the business pays for being able to delay decisions and for getting the opportunity to course-correct.

Example:

Let's say you were developing a feature which was split in 10 stories. After deploying the first 3, which formed the minimum marketable feature (MMF), you saw that your users are not using the feature as expected. You either need to change the approach for the remaining 7 stories OR you need to stop working on that feature altogether because, given the users' response, other features have become more valuable.

As business, you would have saved some time & money if you had waited for all the 10 stories to be finished and then deployed. But those savings are insignificant compared to first hand user feedback about the feature and the chance to act based on that information.

As the development team, don't feel bad because your efforts on the first 3 stories were wasted. They weren't. You invested that time and effort to find out whether that feature works for your business. You already got more than what you bargained for.

So what about iterations?

Have them by all means. But don't worry about hangover*. Don't try to sign up and finish a particular set of stories in the same iteration. If you can well and good. But what you are really aiming for is to perform consistent amount of work every iteration.

*So as long as your hangover remains constant you are good. If its increasing, you need to change your approach. For example by signing up for lesser stories.

When in a inception...

Everyone is an analyst
Don't get bound by role boundaries. Everyone needs to understand the system. Talk to the clients, ask questions, draw diagrams, make suggestions, understand problems and solve them.

Make sure everyone facilitates sessions at least once
Especially the BAs since they have to interact the most with the clients. Clients need to feel confident about the BAs on the team. Other members should also be actively involved. Don't let a single person be the scribe all the time. The client might ask "why am I paying for this guy" at some point.

Have an intent for each session
and strive to achieve it. Have back up plans ready in case you find that your planned tools / techniques are not working for the client. Fail fast, change your approach, take a break and regroup, but make sure you get the right information out of a session.

Educate the client about the way you work
They should know what it would be like to work with you day-to-day. Clarify time commitments and kind of inputs required from your clients (suggestions during analysis of stories, showcase feedback, testing). Have special sessions that cover methodology. Offline the subject if it comes up elsewhere. It can derail your session plans easily.

Be honest and upfront
About any shortcuts you have taken, any information that you don't have, any help that you need.

Understand each stakeholder
You should know the pressures that they are dealing with, individually. Know how you can help them.

Create. Shared. Vision.

Number Lust

I am an amateur photographer while I am not not hacking project teams and building custom software at ThoughtWorks. Photographers are known to have bouts of lens lust* time and again, especially at the beginning. I realize that some managers seem to have similar urges when it comes to numbers, metrics. They suffer from acute number lust.

In ThoughtWorks, we believe in and encourage self organizing teams. BAs gather requirements, developers write code, QAs test and automate and the customer signs stories off in a flow. The Project Manager role is therefore reduced to making sure that nothing obstructs this flow.

The way this would be done is to gather and analyze the right data and take actions based on this analysis. Examples being:

• Finding bottlenecks from the wall or a CFD and taking actions to fix the problems.
• Looking critically at retrospective action items and seeing that all those issues are fixed (especially if they are issues outside the teams control, like infrastructure).
• Making sure that the right capabilities exist in the team at the right time. If not, get people from outside, arrange training, etc.

Some PMs are content in gathering just enough data to spot problems. But then there are some who can't get enough data ever.

They want to organise the whole world into neat boxes and label them and track anything and everything possible. The walls soon fill up with useless charts with graphs and numbers that the team can't use in any way. The worst part is, there is no analysis done around the data even by the people who gather it. Having people in a 15 member team draw emotional seismographs every iteration and sticking them on the wall is of no use if you are not going to make any decisions based on them.

Now I agree that gathering all possible information can enlighten us to some extent. But its a matter of marginal utility. If I have to do 5 extra things to do my job, just because we want to gather data, I am not doing it.

So guys, here's a humble request. Figure out with your client what kind of data he would like to see. Figure out as a team what you would like to improve and what data needs to be gathered to help you get there. Don't burden your team with things that obstruct OR slow down the flow. Keep it simple and keep it lean.

Our job is to provide quality software not elaborate reports.

* lens lust - the dangerous urge to keep buying new, expensive lenses not realizing that its practice that will improve your photography, not lenses!!

Onsite Business Analyst

This has come up in various discussions recently and I want to put down my thoughts about the role and responsibilities.

For a ThoughtWorks team in India (or China) most of the work is offshore agile development. Clients are usually in the UK or the USA. The team is structured as follows:

1. Offshore PM
2. Offshore Devs
3. Offshore QA(s)
4. Offshore BA(s)
5. Onsite BA(s)

This is how the communication works.

Of course there are other exchanges that take place but the Business Q & A and the Technical Q & A are the most important pieces of concrete information exchanged.

Other companies, even traditional development outfits, have a role called the Onsite co-ordinator. I believe this role facilitates similar discussions (although I hear that they are more technical than business related)

The onsite business analyst's main role is to facilitate business and technical discussions between the team sitting offshore and the client. She is not restricted to be just an onsite co-ordinator. She can take up a new stream to analyze by herself. Even feed it to an onsite development team, if there is one. But all this keeping in mind that the main purpose is bridging the communication gap between the client and the development team.

At the same time the onsite business analyst shouldn't go overboard with this and become a single point of failure. The direct communication lines between the offshore team and client should always be open.

Metrics

I have recently come out of a consulting assignment which has given me loads of time to read and think about processes, improvements and effectiveness. (People who follow me on google reader must have noticed). It also had me thinking about introduction of agile into a traditional IT outfit and what would make it more effective.

Top -> Down

The Top -> Down approach is where someone in the top management realizes (or is convinced) that agile is the solution to all their problems and goes on to "mandate" agile. This is not necessarily bad. If the organization hires the right consultants to bring agility into the project teams at the ground level.

Bottom -> Up

The Bottom -> Up is not really an approach. Its just a team realizing that they can do their stuff better and try to bring in improvements in their team without affecting the organization. This is later, agility may spread into other teams virally and this might trigger an organizational transformation with eventual buy-in from the management.

Here's what I think works best. Like any win-win solution, its a mix of the two extreme approaches described above.

Top -> Down buy-in, Bottom-Up implementation

The management decides, that they require to be agile to meet the market conditions but instead of pushing "agile" down the throats of people below, they let the people on the ground level realize what agile means and how it changes the way the team works. Agile Coaches are useful in this transition.

Sounds simple enough? Well here's the catch. How does the management know that the new process is effective?

The sad part is in a traditional organization's hierarchy, the only interface between the management and the teams is "Reports". Reports on various parameters (metrics) that the management believe should be monitored to see how stuff is going on. Whether the teams embrace agile themselves OR whether management asks teams to be agile, the teams will need to report the right metrics to the management to gain their confidence. If the teams don't do this, the management might start tracking the wrong metrics and hence encourage wrong practices. What you measure is what you get.

I opened this topic to a bunch of people from the client organization and we came up with a bunch of metrics based on the principle that we should report consistency rather than hard numbers. Consistency gives a measure of effectiveness and also encourages the right activities.

Here's the list that we came up with (There can be many more. The basic principle is to use proportions / percentages instead of hard numbers):

1. Velocity Barometer without numbers (we mark completed stories in red on a barometer, but we take out the numbers. Consistent color means good, ups and downs means trouble)
2. Cumulative Flow Diagram (consistent thickness of bands v/s actual numbers)
3. Ratio of open V/s closed bugs (Percentage. Instead of bugs found and bugs fixed)
4. Test Coverage (Percentage)
5. Automated V/s Manual tests (Percentage)

Really speaking it all boils down to using just Control Charts for project reporting and management. What do you think?

Testing considered wasteful??

@silvercatalyst posted on twitter a few days back that one of the trainees in his session counted testing as waste. I retweeted with a #funny but @silvercatalyst said he actually agreed with it. So we twiscussed it for a while. (By the way twitter is just the wrong tool for discussing interesting things). Back to the story.

Here's what we ended with after a few emails had been exchanged:

• Testing is not wasteful. But testing as an activity after development (especially after a time gap) is wasteful
• Some types of testing can be done upfront but other types still have to be done after the story is complete
• There are ways to prevent bugs (rather than catch them) by Dev + QA and BA + QA pairing

Mixing this conversation with Feature Injection technique and Mike Cohn's post on removing Finish to Start activities, I think that BA(or Customer), Dev and QA pairing on a story will provide tremendous boost to cycle time and significant reduction in bugs. But to achieve this, you need certain pre-conditions to be true.

1. Co-location with customer. Else a great BA who is an excellent customer proxy
2. Poly-skilled team members (not just smart)
3. Team members (including the Customer) open to work towards a moving target (with negotiable stories)

My next project will hopefully see this implemented, at least in small steps. Something a step ahead of the Ménage à trois that's already been tried out successfully.

Thanks @silvercatalyst for an interesting discussion and helping me put my thoughts together on a bunch of stuff I had read recently.

Back to the Basics - 1 - The problem

Reading Martin's ConversationalStories renewed my confidence in this draft post from about an year ago. I just couldn't put it in the right words and gave up on it. I keep talking about deterministic universes over randomness and stuff like that but the gist of the matter is simple.

Writing stories is not the JOB of a Business Analyst in agile development. Writing stories is a collaborative effort in which Customer, BA, Dev, QA should all take part. This is the N in the INVEST principle.

And here's the post

==============

I have been talking about tracking and trends and smells and quantum physics for sometime but here's a post that takes us back to the basics. This is about the very problems (with waterfall) that we are trying to solve using alternative approaches (agile, lean, hybrid, etc).

As everything in life should start, we start by defining the problem. Waterfall is an approach that borrows heavily from Einstein's idea of a deterministic universe. The idea is that

If you know the position and velocity of each atom in the universe, you can accurately determine the state of the universe at a given point in future or the past.

The point is that this is just a theory. I am not contradicting the theory but I am just pointing to the simple fact that gathering knowledge about the position and velocity of each atom takes too much time to be of any use.

Waterfall tries to do the same thing at a very small scale; at a project level. And the argument remains the same. It'll take you too much time to understand every aspect of a problem for you to be able to successfully solve it while it's worth solving.

Agile is about improvisation. You accept the inherent randomness of the universe. This might be genuine randomness OR it might just feel random because we are not able to understand it, but at any rate the universe is random to Human Beings.

So we say, given that things are going to change in ways that cannot be determined, let's do our best to adapt to those changes as quickly as possible. To adapt is to understand what has changed, how it affects us and what can we do to "maximize our happiness" in the given situation.

This is where you require the key component of anything worth calling a success. Collaboration.

In the deterministic world of waterfall, the Business Analyst is supposed to be this wizard, who understands the whole problem, whose affected and how and formulates a solution to it all by herself. Few have succeeded at meeting this unrealistic expectation.

Agile says let us all work together towards solving this problem and I think that's a more realistic way of getting an optimum solution. Now what this means is that nobody's word is final on any solution unless everyone is happy. Neither the client, nor the Business Analyst and nor the Developers. That is what it means when we say that a user story is Negotiable (i-N-v-e-s-t).

* Increasing happiness as in the sole purpose of life.

==========

Kanban

Although I am not in the thick of things right now (because I am onsite, alone, so far away from my team) I follow the very active kanbandev yahoo group. It's a great resource for thoughts and questions on lean and kanban software engineering.

David Joyce, a group member, posted about a presentation he gave and I found it really good. So here's the presentation for anyone else interested.

It's definitely a long one but take some time to go through it.

Good stuff David.

Story Dependencies

As I mentioned in this post, I am pretty annoyed with myself because of the way I structured stories in the first release of my current project. Here are a few things that I learnt.

First of all when we say that Story A is dependent on Story B, it means that Story B development cannot start until Story A development is complete

There are different situations where one story is dependent on another. Each situation needs to be dealt with in a different manner.

Types and Approaches

Situation 1 - The wrong split
This is the classic vertical split. Many have advised against it but many more fall into the same trap again and again. Myself included :)

Look out for the vertical split problem.
Remember,
If your body is horizontally split in half as in you have no legs, you can still do something with yourself.

If your body is vertically split in half as in your left is separate from your right...

The first place to look for the vertical split is Admin Functionality / User side of the application. If you see your stories divided like Admin Stories and User Stories make as big a noise as you can quickly.

Situation 2 - The application flow
This is where we just plainly don't think.

Example:
When you get a message on Yammer, Yammer sends you an email. You can click on the email to look at the message you have got. BUT you can obviously keep your Yammer client open and see the message instantaneously and thats the way it's supposed to be used.

Email notification is a nicety. Showing the message on Yammer client DOES NOT depend on sending an email notification to the user.

Such errors are much easier to spot. Beware of the Business Process Workflows that you refer to. The business process workflow DOES NOT represent development flow. Mark the niceties and essentials apart in your workflow.

Situation 3 - Data dependence
This is a little more tricky. But I have seen this a lot of times as well. This is closer to David's comment on my earlier post.

Surely to sell an item, you need to set the item up in the system. Doesn't this mean that you have to build the Item CRUD features into the system before you can sell it.
NO!!
Theoretically the items could be setup directly in the database. If the goal of the system is to sell an item, then that's what should be done first.

Practically you should be doing the absolute minimum "item setup" before you build the functionality to sell it.

The first thing is to concentrate on the crux of the system. Selling Stuff, Lending Books, Renting out DVDs, Playing Music, these are the things to achieve as early as possible in respective projects. Therefore you need to do whatever is needed to get to these areas as soon as possible.

Musings-at-the-end
I was mostly plagued by the admin V/s user situation throughout this release. We split stories that way because there was a tough deadline to meet and we thought it's better to split the work so that more pairs can work on the project. It worked out alright and we are in the last iteration and even able to provide a few more story points than promised. But we did face a lot of problems in scheduling because we split the stories in a wrong way. So that's definitely something to avoid.

Another thought that keeps popping in my head is the idea of Programming by Convention. Like RoR.

If you have a team of fairly experienced, "like minded" developers... can they agree upon a few conventions to follow so that two pairs can work on "Setting up the Item" (Admin part) and "Using the Item" (User part) simultaneously? I am still talking about evolutionary design (code as well as database). I seem to think that with good build processes, this should be possible.

What do you think?

Can you shuffle your stories?

No? Neither can I and I am not happy about it.

So I got my new iPod Touch. One thing I find slightly annoying is the fact that when you select an album it gives you the list of songs. But the first option is "Shuffle". Being used to LPs and Cassettes and CDs I don't really like to shuffle songs. I have listened to my favorite albums in a given order of songs for so long, that I want to listen to them in that order.

So I started wondering about the requirement for a shuffle option itself. And I conclude that it does nothing but brings a tiny bit of randomness in our lives. A little bit of surprise. That's all.

What is also important is that the songs that we listen to usually are shufflable :) Because I do listen to Indian classical music and you can't shuffle that. The khayal has to come before the drut rendition.

So what's this got to do with user stories? Well, I am currently plagued by dependant stories and I suddenly realized that they are like India Classical music. They can't be shuffled. Separate post about why I have too many dependant stories on the current project.

Dependant stories are not always avoidable. But it is ideal to have a lot of stories that can be shuffled.

A Bunker Buster coming!!!

Get Down!!! Take Cover!!!

A bunker buster on it's way here guys...
...been a long time since I wrote one of those :D

But then again, as Nassim Taleb says in The Black Swan

What you know can't hurt you (much)

More on the book later. I still got to finish it.
And by the way, have a wonderful New Year guys.

Cumulative Flow Diagrams

Once you have your wall in place, it’s time to start monitoring your progress through the project. Best done on a daily basis and best done with a “Finger Chart”. Here’s an example.

A finger chart is basically your wall turned sideways so that your swim lanes are horizontal rather than vertical. Now what you track is the number of stories in each state (finger).

This chart may not make sense to you immediately but there’s a lot of useful data hidden in here. Here are the different inferences you can make by looking at a finger chart.



1) Bottlenecks
The first thing that you monitor on a finger chart is bottlenecks. This is easy. Just check for a band thickening consistently. A band thickening means that there is either a capacity problem or a capability problem in the next band. For example, the BA/QA band consistently thickens a suddenly rises at specific intervals. This is because the Client is signing off the stories only at the end of each week. This may be due to various reasons which need to be investigated to see if something is wrong OR can be made better. The ultimate goal is to achieve a smooth graph.



2) Work in progress
At any given point if you measure the total across all bands vertically, it will give you the total work in progress. This is a total of everything that needs attention from someone or the other on the team. Always try to keep this as low as possible. You should ignore the Celebration State for this calculation.

3) Average Turnaround Time
If you measure the time across all bands horizontally, you get the turn around time for a story. This is a good measure of your entire process. How lean your processes are, how good the team is, how involved and keen the client is, etc. This is what tells you how much time your team needs on an average to turn an idea into working software.

Remember that the finger chart is a cumulative of all stories. Therefore the top line of the graph should never dip down unless you have really reduced scope.

Now whether to track Number of Stories OR Story Points on a finger chart is an interesting debate. I will try to present my ideas on that in another post.

UPDATE : As David pointed out these are called Cumulative Flow Diagrams in the Lean world. Finger Charts is/was more of a ThoughtWorks term.

Choose your lanes

Starting a new project is always fun. For Agile/Lean teams setting up the story wall is a part of the fun.

Some would say you are defining the process that you want to follow. The life-cycle of the user stories from being analyzed to delivered. But there’s more to a wall than defining the story lifecycle. In its wall the team chooses what it wants to monitor.

The lanes on the story wall are statuses in which the story can be. An agile team wants to track these statuses to quickly find problems that are slowing the team down. These problems can broadly be classified into two categories.

Capacity Problems – Found by tracking Wait States

• There is a bottle neck because people have too much on their plate
  
• Can be solved by
  
  
  
  • Adding more people
    
  • Finding out better ways of doing the work
    
  • Prioritizing the work correctly
    
  • Making the process leaner by removing statuses
    
  
  

Capability Problems – Found by tracking Work In Progress States

• There is a slowdown the right people are not doing the right job
  
• There is are problems external to the team which are slowing the team down
  
• Can be solved by
  
  
  
  • Training people if there is enough time
    
  • Bringing in specialists who can help out
    
  • Addressing external problems
    
  
  

Monitoring every state that the story is in is ideal but not optimum.

So choose your lanes keeping in mind what you want to monitor.

When something is not happening on its own, make it a ritual by adding a lane.

Keep your process lean by removing unnecessary statuses from the wall as well as the process.

Can't negotiate size... and a good thing too

In many companies the Business Analyst or the Project Manager “estimate” the project and bind developers on the project to that estimate. This is an absolutely brutal thing to do to your project. But even within agile teams where the developers estimate, the Business Analysts or Project Managers sometimes tend to challenge and negotiate developer estimates. Not because they don’t trust the developers but merely out of selfishness. Because it gives a tremendous kick to deliver something that a client wants faster.

Now if the team is “estimating” in a “time based” unit such negotiations make some sense. Because a developer might say “Well I’ll take 3 days to do it but developer X is really good at XML so he can probably do it in 2 days”. And that might help given that you can assign the task to developer X (who in all probability is good a everything).

Another way of doing this is for the team to “size” user stories based on relative complexity. Here’s how it works.

As a developer on the team you are only classifying the stories into buckets of high, medium or low complexity. Nothing you can do is going to change the complexity of a given story.

As an analyst or project manager on the team please don’t ask developers questions like “Are you sure this is a 4-pointer?” The only one who can simplify stories is you.

Something Faster is better than Everything Later.
Everything Faster doesn’t exist

What are we doing?? - Part One

I am doing what we call an Inception for a new project. The situation is not at all unusual.

The Constraints

• An Organization with a bunch of generic e-commerce platforms
• Live customer sites on each of these platforms
• One of these platforms particularly painful
• Integration with proprietary back-office operations software

The Requirements
Build a custom platform that will replace all the existing ones, support all the customer sites and have a bunch of unique features. And BTW we need to go live in 2 months.

How?
The only way to do this is build a bare bones application that can take a couple of simple customer sites live in 2 months. We can then keep adding to the application and making it richer and better and migrating more customer sites as and when possible.

Now whenever you try to skin an application the first ones to suffer (and rightly so) are the administrators of the system. I say "rightly so" because normal users can potentially be dumb, careless, in a hurry, etc. and the application has to make sure they are doing the right thing.

Administrators on the other hand are trained to maintain the application. They can do without a jazzy UI and help and pointers all over the place. They know how to do their job. We, as designers of the system, take the liberty of trusting them. And in that trust lies the topic of this series.

To be continued...

Business Analysis and Quantum Physics

I recently read In search of Shrödinger's cat. It's a wonderful introduction to quantum mechanics; The basic (and intriguing) problem of the elusive electron acting as a wave and a particle at the same time.

Analysis is very much like observing the electron in the classic two slit experiment. The business domain is like a wave traveling through the two slits. But the moment we analyze, we make it boil down to one reality by asking it How, What, When and Who.

Waves give you a probability distribution, while particles give you one of the possibilities as a reality. Looking at a business problem, in the wave form is better since it let's you choose a reality that solves the problem well.

For Example: Let's say the business problem is "I want to let my customers know of the new offers I have so that they can take advantage of the offers and I can make money"

This is the problem in it's wave form. The reality can be one or more of email, website updates, RSS feed of offers, people going door-to-door, mobile advertisement vans and a million other options including telepathy, albeit with low probability perhaps.

The problem is that clients come and say "I want to let my customers know of the new offers I have by email so that they can take advantage of the offers and I can make money" and it takes a while to get into a mode where you challenge every reality and go back to the wave form, by asking "Why"? Why is the only question that let's you go back to the wave form.

The more we procrastinate our observation, the better will the chosen reality suit our problem. Agile takes this approach with the concept of the last responsible moment for a decision. It let's future remain future and hence full of possibilities.

Size or Estimate

Estimation, I think, has been one of the biggest problems of mankind. The Software development industry is no exception to this sad reality. We almost never seem to get it right.

The problem with the word "estimate" is that it's personal. It's relative to the person who is estimating. Moreover, it's a unit of time. That is why I prefer "sizing" stories rather than estimating them. Size is a non disputed (standard) unit, which measures the level of complexity involved in developing a piece of functionality, a story. The size is standard across a particular project team.

Pizzas are a great example of standard size. They come in small, medium and large sizes and, given the context of the vendor, the whole world knows what a small pizza means.

Pizza Appetite is the capacity to consume pizzas. A 5 year old will find a small pizza to big to eat. A teenager will probably find it perfectly filling. At 25, I find the small pizza too small. I can comfortably eat a medium pizza (or 2 small pizzas). I am sure there are people I don't know who can eat nothing less than a large pizza (or 4 small pizzas)!!

Stories are like pizzas. Given the context of a project, they have fixed sizes. As a developer spends more time on a project, getting older (and wiser), his/her capacity to develop complex stories increases. And this is where the trouble starts. At the beginning of the project the developer could do 1 small story every day. But now, instead of realizing that he can do a medium story (or 2 small stories) in a day, he begins to think that the medium story is actually a small one. The thing to remember is that the size of the story remains the same. It's just that the developer can now do more complex stuff in a given time.

Complexity points are never to be estimated (in fact they can't be estimated because they are not relative to individuals). In the OLAP terminology, complexity points are the fact. An estimate is a calculation you (as an individual) do when you are looking at them from the Time dimension.

So if you are estimating units of time, it makes sense for you to re-estimate so that you take into account your improved understanding of the system.

When you are sizing stories in complexity points be very careful not to fall in this trap. Re-sizing even sounds wrong anyway.

Functional Goals

After this post, I have had a number of conversations with people about what I really meant by setting functional targets instead of story point (velocity) targets. In one such discussion, I was given an example where someone set a goal to run for 90 minutes!!

At first glance you might not find the last statement worth the exclamation marks at the end of it. But this is exactly the difference between functional targets and velocity targets. I think it's wrong to set a target of running for 90 minutes. The real goal is to burn X number of calories. Or to travel X number of kilometers.

Once you set your goal right, you are open to find better ways of achieving it. If your goal is burning calories, you'd probably do it better (faster) by skipping rope for 30 minutes than by running for 90 minutes.

Now all you have to worry about is

• the rate at which you are actually burning calories AND
  
• what can you do to improve this rate
  

So instead of planning to complete 30 points next iteration (going by yesterday's weather, etc), I'd plan to achieve a set of features and keep optimizing the rate at which I am able to produce features assuming that I never compromise quality in wake of going faster.

Iterationless...

After working in week-long iterations for 2 and a half years, going iterationless left me a little confused on my recent project. Of course when I say iterationless, I mean using extremely small iterations to bring in a flow to stories. Lean? Distributed Lean, maybe?

Firstly, I like the idea of trying something new. The team being small and the project being developed in ruby helps this experiment a lot. There are, however, somethings missing in this way of working. I'll list them down and give my view on each of them in this post.

To realize what we missed, let's look at what we get from iterations. The following are the main motives behind iterations.

1. Celebrate small successes
2. Get regular feedback from clients (showcases)
3. Let the whole team know what we will be focusing on in the next iteration, including the business context around it (Iteration Planning Meeting)
4. Re-estimate stories based on additional information gathered during the earlier development (Iteration Planning Meeting)

So let's see how we are trying to handle each of these situations.

1. Celebrate small successes.
This is very important. To look back and realize that we actually celebrated achieving a story-point targets each iteration, however, now sounds really lame. The moment you move your focus away from finishing a set of stories in a given time TO finishing a set of features and going to production, the world starts making more sense.

I think in this aspect chucking iterations totally makes sense. What this means is you should have a very strong release plan, with frequent (less than a month long) releases.

2. Getting regular feedback from clients
Showcases have nothing to do with iterations. Iterations only provide regularity to showcases. To say that we will do showcases once a week (and do it) is I think good enough.

One thing to beware of is that showcases-bound-to-timelines (once a week) and development-bound-to-releases (of irregular time intervals) can be quite tricky to handle.

3. Let the whole team know what the focus of the next iteration is
Ours being a small (ideal?) team, I don't see too many problems in this area.

4. Re-estimate stories based on new knowledge
This, I thought, was the most important aspect we were missing out. But once you realize that your story point sizing is only relative to any other story you estimated, the world seems much better. This means that as long as your triangulation is correct, you are ok.

One thing that IPMs give us though, is an opportunity for the whole team to estimate together. Right now I am unsure of how important this method is. I am posting a few questions related to this at the end of this post. It'll be great to get some feedback on these.


All in all I think going iterationless is beneficial in terms of:

• Shifting the team's focus from story points to features / business value.
• Letting the team focus on estimating complexity of stories much more clearly.
  

What I am unclear about is estimation.

• If we spend 2 hours every week to estimate together, are we going against lean philosophy?
• On the contrary, if we estimate just-in-time, in smaller groups (pair to work on the story) are we losing the "group touch" to estimation?
• Also if we estimate just-in-time (when we decide to play a story), the business doesn't get an opportunity to re-prioritize based on sizing.