Hi. You've reached Nigel.in
What you have landed on, possibly inadvertently, is the website of a certain curious character a.k.a Nigel Fernandes
The aim of this page was to serve as a landing point for those of you who want to know a little more about me. The links on the right and left will take you deeper my world, or possibly on to different exciting things.
Its a big web out there and this is just one more street for you to saunter down. I hope you like it.
Close this.
About Me
- Name: Nigel Fernandes
- Location: Panjim, Goa, India
Crazy, dancing, programming, Goan.. I'm a computer geek and proud to be one. I program in Java, Ruby and .Net, PHP, Javascript. A lot of my recent work has been about CSS and UI design practices for large scale websites and Agile teams. I still while away hours dreaming up a web startup.
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 Vp = V/N
Let us assume the values of Vx and Nx hold for an iteration Ix. 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 Ix+1 is as below
If C is the co-efficient of (ramp up time,communication overhead etc..)
∆V can be defined as C * Vp
By Paulo's formula : Vx+1 = V + ∆V
i.e. Vx+1 = V + (C * Vp)
i.e. Vx+1 = V + (C * V/N)
I've seen that a good co-efficient C for Ix+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. Vx+1 = V + (Cx+1 * V/N)
Vx+2 = V + (Cx+2 * Vx+1/Nx+1)
where Vx+2 corresponds to the iteration Ix+2
In such cases values Cx+1 as 0.3 and Cx+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