It’s your life, UTrack it!

I’m not one for endorsing products but this particular tool is a life changer. I downloaded UTrack onto my iPhone and loved the application to the last ‘byte’

Being an agile fiend I like to do my day to day chores in-line with the agile mindset, and UTrack allows me to do just that!

UTrack is essentially a ‘To-do’ list manager that has a very user friendly and simple interface comprising of 4 columns; To-Do, In Progress, Verify and Done.

You can initiate a To-do task by simply creating a new post-it and it is automatically placed under the ‘To-do’ column. As the name implies, the tasks under To-do show you all the chores that you need to take care of. Once you start doing something from your ‘to-do’ list you can easily drag-and-drop the post-it from To-do to In Progress. Similarly once the task is done you may either move it to Verify (if you want to double check it), or move it straight to Done.

Trust me, when you are able track progress of your day to day chores in a  ‘tangible’ manner (in this case literally) as opposed to just checking things off a list, it has a HUGE psychological impact on your attitude towards work. You feel empowered and it feels good to have control over your life.

What’s more, you can share your To-Do track board with anyone by taking a snapshot of your to-do wall and simply mailing it to someone.

All in all I’ll give the app 2 thumbs up! And I’m anxiously waiting for their paid version to come out. I’m hoping the new version would have some more goodies to enjoy.

If you can’t beat ‘em… burn ‘em!

A lot has been discussed about which mode of reporting and tracking progress in Agile projects is better… Burning points up or down. In my opinion Lee Richardson hits the nail on the head in his article. 

Agile projects traditionally use burndown charts to visually show work remaining over time. This could be for the current iteration or it could be for the duration of the project. Either way they can help managers (or the Project Owner in Scrum) track velocity, estimate either the project or iteration completion date, or find trends in past performance. But burndown charts have a major shortcoming: they fail to show what makes agile projects agile: new requirements. And that’s where burnup charts come in. But first let’s examine burndown charts.

The Problem with Burndown

A typical burndown for the life of a project might look like this:

It shows the project started with 100 points of work in the backlog; it’s completed eight iterations; the team accomplishes about ten points an iteration; and if everything continues at the current velocity the project will complete all work within another two iterations. Great.

But what happened in iteration six? Very little appears to have been accomplished. Maybe the team all took a vacation. Maybe there was a major problem or the team incorrectly estimated complexity. Or perhaps a large set of new requirements were added to the backlog because the customer decided what they thought they wanted wasn’t what they really needed: namely the exact scenario agile was designed for.

Burnup Charts

The problem is that burndown charts lack two essential pieces of information. First, how much work was actually accomplished during a given iteration (as opposed to how much work remains to be completed) and second how much total work the project contains (or if you prefer how much scope has increased each iteration). A burnup chart for the exact project above might look like this:

We can now clearly see that the team did not take a breather in iteration six. They continued to complete about ten points per iteration, but during the sixth iteration the scope increased by about twenty points.

One could imagine the opposite happening as well. Later in the project the team might delete old user stories that were envisioned during project inception and thus decrease the total scope. The burndown chart would incorrectly show such a scenario as a sudden increase in velocity.

Summary

Either way the burndown chart hides essential information. I propose we throw it away and show the slightly more complicated, but infinitely more useful burnup chart. After all you wouldn’t want upper management thinking you were lazy in iteration six would you?

What Agile is NOT: New!!!

After I started my series of blog posts on Agile and it’s need in the current software development ecosystem I started receiving a lot of emails and comments saying what you are talking about isn’t new, we have been ‘following’ agile for a long time… etc etc. Well, I’m not sure what the argument is for or what it proves, but yes Agile is not new. All of us have been following one Agile principle or the other in our day to day work. Be it daily communication with a client or a ‘project postmortem’ or iterative/phased development. But following one agile principle or practice is not equivalent to following agile. Agile is so much more than just daily stand ups and continuous iterations.

If you wear a helmet, a fire-proof jacket, gloves, racing suit and ride around the city on a donkey cart, it would not make you a formula1 driver. You still need a sports car to go with your gear!

Scrum, DSDM, RAD, Crystal, FDD, XP have all be around for over a decade, but it was the masters the gurus of light-weight development methodologies themselves who joined heads and came up with, what is now called “the Agile Manifesto” which talks about the very principles on which software development ‘should’ be done.

Here’s a very interesting story of how agile manifesto came into existence.

On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground and of course, to eat. What emerged was the Agile Software Development Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.

What emerged from this meeting was symbolic, a Manifesto for Agile Software Development signed by all participants. The only concern with the term agile came from Martin Fowler (a Brit for those who don’t know him) who allowed that most Americans didn’t know how to pronounce the word “agile”. *hehehe* which is so true!

Alistair Cockburn’s initial concerns reflected the early thoughts of many participants. “I personally didn’t expect that this particular group of agilites to ever agree on anything substantive.” But his post-meeting feelings were also shared, “Speaking for myself, I am delighted by the final phrasing [of the Manifesto]. I was surprised that the others appeared equally delighted by the final phrasing. So we did agree on something substantive.”

But while the Manifesto provides some specific ideas, there is a deeper theme that drives many, but not all, to be sure, members of the alliance.

Kent Beck tells the story of an early job in which he estimated a programming effort of six weeks for two people. After his manager reassigned the other programmer at the beginning of the project, he completed the project in twelve weeks and felt terrible about himself! The boss of course harangued Kent about how slow he was throughout the second six weeks. Kent, somewhat despondent because he was such a “failure” as a programmer, finally realized that his original estimate of 6 weeks was extremely accurate for 2 people and that his “failure” was really the manager’s failure , indeed, the failure of the standard “fixed” process mindset that so frequently plagues our industry.

In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the crap out of traditionalists . Quite frankly, the Agile approaches scare corporate bureaucrats at least those that are happy pushing process for process sake versus trying to do the best for the “customer” and deliver something timely and tangible and “as promised” because they run out of places to hide.

In the end I would like to say, don’t shun this ideology just because it isn’t what you were taught at school or because it isn’t what you read in “Roger Pressman”. Try to look beyond processes and look what principles and values agile tries to inculcate. It would start to make sense.

My two cents worth!

I want everything.

As a business analyst when you ask the customer what he wants in his custom built application his response is always either “I’m not too sure, but I have a general idea” or “I want everything”. Both are vague and generic answers and don’t leave much for you to base your project plan on. What do you do? you go ahead and scare him a little by saying: “Will you please be more specific, because if you request any changes down the road they will be charged”. Now the customer tries to think of every little detail that he can and jots it down on sheets of paper, so much so that he starts thinking of features that ‘may be good to have’ or even ‘may come in handy in future’ and that’s when things start to get messy both for you and the customer.

Here’s a figure showing you how most applications built, have features so abundant that most of them are either rarely used or never used.

So here’s what ends up happening at the end of the day.

1) Along with 20% feature that would actually drive value, you also plan for 80% features that would rarely be used.

2) You account for those 80% features in the proposal and your budget increases 4 folds.

3) Your time lines extend unnecessarily and your QA plan becomes more and more complicated and extended.

4) Your application becomes more bulky and chunky.

All this because we want to be absolutely certain that we nail all the requirements day one. And I can’t stress enough on the one fact that nobody denies or can deny… requirements from a client ALWAYS CHANGE. I have never once seen a case where at the end of the project the customer went “that’s exactly what I wanted, you read my mind”.

A value-driven agile approach on the other hand switches the whole mindset. It assumes from the start that whatever requirements exist up front are not fixed and that they will change. The agile mindset also assumes that you have to deliver by a certain date (just like in any non-agile approach). But this approach fixes the time and resources and leaves the requirements undetermined. To us, this approach more closely resembles the reality of creating software. Now the whole notion of value-driven makes perfect sense. When you have a fixed amount of time in which you aren’t sure whether you can deliver all the requirements (because they will change and hence the time needed to finish them will change), the natural reaction is to prioritize the requirements and finish first those that add the most value to the customer.

So now the questions that you ask the customer are not restricted to just ‘what’ they want but also ‘why’ they want them, and from the list of ‘Whats and Whys’ you prioritize which requirements a client cannot live without and which ones can wait slightly more than others. This brings us to the concept of what we call a product backlog populated by user stories.

I’ll be elaborating on both backlogs and user stories but much later in the series of blog posts that I have planned. Right now I’m talking about concepts one at a time so that you’re able to swallow the ‘red pill’ more easily than most people.

The whole gist of my article is to make you understand the very nature of software development. It is an empirical process and not a defined process. Next time I’ll try and elaborate on this very notion with examples and case studies.

Till then, bon appétit.

Acknowledgment: Some of the references in this article have been taken from Dr. Sidky’s famous book ”Becoming Agile in an imperfect world”. I thank him for sharing his work with me.

Agile readiness: Ready or not, here I come.

“If you take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.” — Matrix

Converting from one religion, ideology or methodology to another is a very tough thing to do. Especially when you’re fed only one thing all your life, its going to be hard digesting anything else.

Similarly with non-agile methodologies we as engineers, analysts, and managers have repeatedly seen loop-holes, failures, fiascoes but continue to use them because that’s what we were taught in college, that’s what we opened our eyes to in the corporate world and that’s what we are most familiar with.

On the flip side, there’s another kind of people who read things from a book and start following it blindly. It would perhaps work fine if you’re reading something from a cookbook and trying it out, but it would be a disaster if you read something like ‘How to fly an aeroplane — for dummies’ and thought about giving it a shot.

The latter is the kind of people that give agile a bad name. As a project manager I interview a lot of people applying for various positions in my company, and a huge percentage out of those claim to be followers of agile. Their idea of agile? Daily stand-ups, no documentation, requirements in the form of stories and estimates in the form of story points and that’s it. To top it all, almost all of them believe this recipe does not or would not work with complex or large projects e.g. ERPs etc.

First of all there are SO MANY things just plain wrong with the definition above. And yes, if that was how agile worked, it would be a horrible choice for even small projects and websites let alone ERPs. Second of all no two organizations are alike, no two teams are alike, and last but not least no two projects are alike. So you can’t just follow a checklist of principles and call it agile, you have to take into account SO MANY other things before you even THINK about adopting agile.

For instance: How empowered are your employees? How good is the level of communication/collaboration between the management and the development teams? Does your company have cubicles? Do you know what concerns your developers and testers have rght now? (even before proposing ‘Agility’) etc etc. Like I said there’s a whole plethora of factors you have to consider before adopting Agile (or any methodology for that matter).

To help you with an adoption strategy you have to have an experienced agile coach who would evaluate your strengths and weaknesses as an organization and analyze your overall agile readiness.

I would recommend the website http://www.dragile.com to all those people seeking help with agile adoption. Just take this 3 minutes readiness assessment as see how ready you are for the agile transition.

So if people tell you they tried their hands on agile and came to the conclusion that it sucked, it’d be wise to first find out their definition of agile before forming an opinion about agile itself.

If a ferrari crashed in a tree because it was being driven by a toddler, don’t blame the car blame the driver (or in this case balme the parents for letting a kid drive )

My two cents worth.

I shall resist change… *crack* oops!

Referring to one of my earlier blog posts where I talked about how Agile welcomes change… today I would like to elaborate on WHY Agile tries to inculcate a mindset that accepts constant change using real life examples.

Have you ever, at any point in time during your lives, heard some of these phrases:

- “Gochange your clothes, you’ve been wearing them for 2 days now”

- “Dang, a flat tyre, now i’ll have to change it”

- “if you don’t change your eating habits, you’ll die of obesity”

- “Boy, your school is horrible, you better change it or it’ll ruin your future”

Now let’s try and change these sentences so that they negate change.

- “Don’t change your clothes, you’ve been wearing them for 2 days now”

- “Dang, a flat tyre, now i’ll have to keep using it”

- “Don’t change your eating habits, you’ll die of obesity”

- “Boy, your school is horrible, you better not change it or it’ll ruin your future” (this one doesn’t even make sense :S)

Now, I know some of my examples were loaded just to prove my point but still what I’m trying to show is that we cannot, I repeat we cannot plan for every little thing that may happen to us during any particular day. If we can’t plan every thing in advance for even a single day, how can we as human beings expect to plan in advance, the entire length of a project (that may span from weeks, to months to even years) and assume nothing would change along the way.

In Pakistan there are two methods of travel from point A to point B in a cab. Let’s call one method ‘the Alpha way’ and the other ‘the Beta way’. The Alpha way is to get charged via a fare meter on the basis of number of kilometers you travel from point A to point B. The Beta way is to do a rough calculation of the distance you would have traveled going from A to B, and negotiate on a price. Once that price is decided you sit in the cab, go to point B and pay the pre-settled amount.

Now, consider the following scenario. You opted for the Alpha way. The cabby starts driving but half a kilometer down there’s a blockade. He drives back half a kilo meter and takes another route, 2 kilometers down the road he runs into another road all dug up, and so he takes a third route (I’m not exaggerating, its an every day thing in Pakistan), all the while your meter is running like a high-on-dope gerbil spinning a small ferris wheel and you can’t help but stink the entire car with salt water dripping down from head to toe (in short you’re sweating). When you reach your destination, for what would have cost you 200 bucks, you end up paying 550 or so. You pay extra money for all the routes that you changed, just to get to point B which was your initial plan all the while.

If you had taken the Beta way, you probably would have had to settle for 300 bucks or so, but, road blocks or no road blocks ALL you would have paid was 300 bucks for going from A to B.

Do you see where this analogy is going? We as engineers, project managers, business analysts and especially entrepreneurs do the exact same thing with our customers. When we’re gathering requirements we expect the customer to:

A) know ALL the requirements that he’d ever have, day one!

B) somehow plug a mental usb flash drive and transfer all the knowledge from his brain to ours…again to the last detail.

And then we plonk all the requirements in a document, label it SRS (Software requirements specifications) in block bold letters and put a gun on the customer’s head saying, “These are the holy words spoken by you and inscribed till enternity in this holy book called the SRS. If you Godforbid tell us anything later which is outside this holy book of requirements you will pay for it~~~” *Loud devilish laughter MU HU HU HAHAHAHA*

And that’s that. If during the course of a project a customer runs into a ‘road block’ and HAS to change routes, even if the ultimate goal remains the same i.e. getting to point B, we the ‘helpers’, the ‘solution providers’ hold the customer by the scruff asking him to pay… Why did he not have the miraculous ability to anticipate the unknown we wonder… after all he is the customer!

On that note I’ll end my banter for today. I’ll continue from the same note next time I blog, explaining how if we start thinking like a customer we can really excel in the software development business.

Call it Agile… call it what you will… at end of the day, it’s commonsense.

My two cents.

Nothing but chaos? Anything but.

Agile: PHB's way!

I love Dilbert! Some of the strips are really ‘in your face’ type and this is surely one of ‘em.

It is true though, if you do not know a lot about Agile (except for stories from people who’ve tried and failed at it), from a distance it would seem that it’s just development of code, devoid of any planning, contract negotiation, risk management, documentation, blah blah and what not… it is in fact, anything but! Agile believes in all of the above PLUS MORE! that’s right, its as meticulous a methodology as any other out there.

The difference is, Agile tries to jog your commonsense (that’s why a lot of people fail at it if you know what I mean). It tries to break the mental block that most of us have against change. In short, Agile is not a process that you need to follow blindly… it is a mindset.

Repeat after me: “Agile is a mindset”… *echoes* MINDset.…MIndset…Mindset…mindset…mind..

It is a mindset that inculcates a culture of leadership amongst team members… a culture that appreciates face to face communication (as opposed to confining yourself in silos) and a culture that does not believe in the word ‘rework’, instead all work is considered ‘new work’. I’ll elaborate on this last bit in my future posts.

So to put it in a nutshell, if your commonsense dictates you document your work, document it. If your common sense says it is absolutely imperative to plan each and every detail of the project day 1, do it. But doing so would have both pros and cons. Right now I’ll just leave you with the idea of how receptive Agile is to change and more importantly receptive to ‘whatever works for you‘.

Some food for thought… Bon appétit

The Agile Manifesto:

I just wanted to share the agile manifesto with all of you because I’d be referring to it quite often while talking about various agile practices and real-life project management experiences.

The gurus of the software development world said the following:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. ”

I’ll shed more light on each value in my future postings. But right now I just want you all to take a minute and ponder on what’s being said in the Agile Manifesto and perhaps even debate on why items on the left are better (or worse for those who disagree) than the items on the right.

The ‘Not-So-Big’ Bang!

I have at last decided to come out of stone age and start blogging. I may be 10 years too late but who on earth cares…  you guys certainly didn’t miss anything (‘cuz I wouldn’t have blogged about anything worthwhile anyway).

I’ll mostly be blogging about agile values and concepts but more importantly the ‘human’ aspect of the agile mindset which many books and blogs do not talk about.

*To myself* “Happy Blogging!”