Nigel Fernandes

 

Extending Agile Algebra

Saturday, September 5, 2009

Paulo Caroli at Agile Tips wrote an interesting post on Agile Algebra. The formulas are all very interesting.

However I believe in order to be usable on a project a couple of them need to be extended a little bit. Specifically, the calculation of the expected increase in velocity per pair added.

In each of the problem statements Paulo states the expected increase in the velocity for the new pair in the problem itself. The means to arrive at these expected velocities is not clearly discussed.

If current Velocity of the team is V, and current number of developer pairs is N, then current velocity per pair is V/N

i.e V_p = V/N

Let us assume the values of V_x and N_x hold for an iteration I_x. We'd like to calculate the expected Velocity after adding 1 developer pair.

Adding new people always has a less than linear increase in capacity. Communication overhead (see Fred Brooks), ramp up time etc.

To account for this, a good technique to predict velocity for I_x+1 is as below

If C is the co-efficient of (ramp up time,communication overhead etc..)

∆V can be defined as C * V_p

By Paulo's formula : V_x+1 = V + ∆V

i.e. V_x+1 = V + (C * V_p)

i.e. V_x+1 = V + (C * V/N)

I've seen that a good co-efficient C for I_x+1 is 0.6 for small teams (i.e N <= 6 developer pairs) For larger teams it makes sense to stagger the projected velocity across more than one iteration. V_x+1 = V + (C_x+1 * V/N)

V_x+2 = V + (C_x+2 * V_x+1/N_x+1)

where V_x+2 corresponds to the iteration I_x+2

In such cases values C_x+1 as 0.3 and C_x+2 as 0.6 have given good results but I encourage you to work out suitable values for your team.

A lot of other factors such as length of iteration, technical complexity, skill/experience of pair added, etc will affect how you pick your values for C. That's where the skill and experience of the project manager comes into play.

Its interesting to apply these formulas retrospectively to your project and calculate the values of C. While it may not be accurate (planning rarely is), it does give you a yardstick for the future.

Labels: agile, agile algebra, projects, velocity

 

Gandalf, the software architect.

Friday, September 4, 2009

My colleague Srushti had conversation with me about tech leads on projects being benevolent dictators. We moved from there on to the role of architects on agile projects. My thoughts on an architects role...




Robert Paterson stated:

Critical for the success of the Mission in LOTR is that Gandalf make it clear to all the nature and extent of the threat and also what has to be done to "Win".

Most of the time Gandalf advises. Rarely - at crisis points - he acts. Above all he treats all as adults. You take his advice or you don't. He does not preach - he offers.

Replace mission in LOTR with software project and you have Gandalf the software architect. If he wrote code regularly he'd be an agile architect.

Labels: agile, projects, software architects, thoughts

 

The right size problem.

Deciding how big a problem to tackle is a challenge agile project planners. What should the size/scope of a story be. Same goes for developers. How big a refactoring should be taken on as part of a story?

The answer usually varies across project team.

There is plenty of written material on this. I'll just add a small point I believe is valid when starting/building teams. This is a also something to keep in mind as a lead/analyst in a project.

Seth Godin says

If you've got a small, fixable problem, people will rush to help, because people like to be on the winning side, take credit and do something that worked.

Labels: agile, Problem solving, projects

 

Make millions: Design a better laptop.

There's millions to be made. All you have you have to do is design a laptop that can be used lying down.

Nearly every developer, student and crazy technologist, I have ever met has confessed to using a laptop in bed, whilst lying down, or laying on their side/front.

If you've done this, you know how lousy the current "L" shaped laptops can be in such a scenario. Yes you have tried different stands, and weird pipe combos, crazy straps and even touch screens. Nothing has worked.

I'm convinced that I work/relax/read in this position nearly half my life. As computing and the internet invade our lives, the person or company who cracks this is going to make millions.

Ergonomic lying down computing is the thing. Ergolyputing(tm). I'm going to try :-)

Labels: next big thing, thoughts

 

Defeating the wall

Thursday, September 3, 2009

Every developer hits the wall. Depending on your fortune and skill that maybe a rare or frequent strike.

The wall could be a challenging problem, big upfront designs, legacy code, stupid people or maybe a combination of all of the above.

My personal strategy for coping with the wall is a simple 3 step process

Step 1: Walk away for a few minutes.
Step 2: Come back and break the problem into smaller pieces.
Step 3: Tackle the smaller pieces.

Image from http://kwc.org/blog/archives/2005/2005-07-27.comiccon_sketches_best_of_the_rest.html

Labels: agile, Problem solving, thoughts

 

Smelling Bugs

Thursday, August 13, 2009

A few months ago, we learnt that our team had the highest bug count per point delivered as compared to any other team. Since the program of work is composed of several teams all working on the same code base, this was a point of obvious concern.

At first we tried throwing more QA's and more QA related process at it. Seemed logical but did not help much. In fact intense QA and QA process meant that story cycle time went up.

Then we started analyzing the bugs, and found fairly distinct trends based on the nature of the bug report.

We had a higher percentage of bugs caused by :
* Implementation defects.
* High levels of customer feedback coming in as bugs from UAT.
* The customer expecting more than the story scope.

Our actions:
* Return to core XP practices. Much more focus on pairing and pair rotation.
* Spend more time on story analysis. Get the programmers to pair with BA's on story definition.
* Tightened story acceptance criteria.

The results are trickling in now. Looks like we got our actions right.

Lesson: Pay attention to the nature of your bugs, not just the bug count.

Labels: bugs, projects, software

 

When you love what you do, its not work.

Sunday, August 9, 2009

People tell me I'm a workaholic. They base this on the fact that they see me on my PC late into the night, in the office.

What they do not always understand is that I choose to spend that time in the office. I do not stay because I have work to do. I stay because I'm doing something I love. I do not believe I have ever complained about having too much work.

Some people work on side projects in their own time. I used to do this too. Until I realized that the reason I did that was to have the joy of building something that people liked and used.

I get this same joy that on projects. I build little tools and code bits that could make my team more efficient, that they could use and be happy. Even make my own day easier. No context switching to deal with either.

I'll go back to working on side project someday. But till then I've found a happy middle ground.

Laziness - The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful. - Larry Wall

Labels: consulting, thoughts, work

 

Some IE6 users are just irrational.

Sunday, July 12, 2009

A senior user experience architect at Digg blogged the results of an IE6 usage survey they conducted on their users.

I can't help and feel a pang of pity for the 7% who said they use IE6 because they prefer it. You've got to respect their opinions and I'm sure its all familiar and nice for them, but at some point they are going to have realize their cheese is very stale.

Labels: browsers, digg, ie6

 

Forget browser wars, bring on the OS wars.

So Google blogs about the promise of a Chrome OS. I'm salivating at the thought of the Microsoft response, which will surely come.

Until now, the product lines of Google and Microsoft have always just about crossed everywhere except the OS. If the browser wars kick started an amazing generation of invention, I foresee exciting times ahead.

Sure Linux and Apple have been in the fray for a while, but what Google is doing is taking the best of both those two and rolling them into one. The technology revolution aside, Google is rolling together the price value and ideology of Linux with the user experience focus of Apple products. Microsoft are going to have break the mold with their response to compete effectively.

Whee...

Labels: google, Microsoft, os wars

 

Are you asking yourself the right questions?

Tuesday, January 27, 2009

At certain points in your career, you're going to look at what you are doing, what you have accomplished and what you want to accomplish.

At times like that, there are bound to be some core questions you ask yourself. I'm not going to add much to a topic best covered by people far more experienced than me.

I will however add a couple of questions that I have found tremendously useful:



1) Do I want to be a big fish in a small pond, or a small fish in a big pond.

2) Do I want to be challenged and afraid, or safe and within my limits.


In the words of Don Juan (culled from Freelance Switch):

Look at every path closely and deliberately. Does this path have heart? If it does, the path is good; if it doesn’t, it is of no use. Both paths lead nowhere; but one has a heart, the other doesn’t.

One makes for a joyful journey; as long as you follow it, you are one with it. The other will make you curse your life. One makes you strong; the other weakens you.

A path without heart is never enjoyable. You have to work hard even to take it. On the other hand, a path with heart is easy, it does not make you work at liking it.

Labels: career decisions, thoughts