Friday, November 26, 2010

Scrum is not Agile Enough

During my career, I had done my share of hacks in waterfall projects to maintain the initial monster design done by an architect who only had 10% of needed information. Needless to say, the first reason for me to fall in love with agile, is to do things ‘later’ when it is absolutely necessary.

For some time I have been a part of Scrum team and enjoyed doing things when it matters. For me Scrum has solved the problems of ‘big design upfront (BDUF)’ and ‘big requirement upfront’.

Still something was troubling me for quite a sometime. I knew I wasn't really happy about everything, but it took a while to realize what. As now I know, it was the way Scrum do 'planning' made my agile senses uncomfortable. When everything else is done late, why Scrum requires planning to be upfront in a sprint?

Common progress tracking in Scrum is through the burn-down chart, and tasks with ETC (estimated time to complete) are made at a upfront planning meeting. It is these ETCs that are burnt throughout the sprint to form the burn-down chart.

But for someone to create tasks and accurate ETCs at upfront planning, he needs considerable technical knowledge on the story work. This often results planning meeting ending up being a design meeting. Doing design at planning is going back to legacy BDUF.

Other alternative is to ‘only’ create design related tasks at planning. Rest of the tasks are then created by the developers doing the design within the sprint. This looks the way with agile, but then burn-down chart is to suffer. 
You ends up with a saw tooth chart (as above) which effectively remain flat until the last few days of the sprint.

I do not take any glare off the Scrum. No doubt, Scrum (the widespread agile) had taken the industry to a new field. Just that it is not good enough. When it comes to choice, I go for agile over Scrum!
[tag: 99xp ]

Saturday, October 09, 2010

All you are told about 'soft skills' is bullshit

Think for a minute... over the past years, what are the skills you wanted to improve to be successful in your job? Let it be the advices from mentors, appraisal results, manager feedback or any other, I can guarantee 90% ends up at soft skill improvements.

Is that what will take you there? Unfortunate truth is that the most of the ‘soft skill’ hype is actually made by the training institutes to get a better share of your organizations training budget. Think rationally. If you are to promote your subordinate to take over your position, what is the most important skill you look for?

It is not some soft skill... but it is obviously ‘how dependable the person in delivering what you have delivered so far’. This is the truth most of the employees fail to understand. Look around the industry.. how many brilliant minds get beaten by average minds in job promotions. Many think organizations are unfair when that happens, but always there is a reason behind. You promote the one who is most dependable in the given delivery responsibilities but not the one with greatest abilities. The reason is.. the one who is dependable knows/finds what is takes (including technical skills what he doesn't know + soft skills what he doesn’t have) to achieve the goals. He/she will ensure those are smoothly available to achieve the deliveries as planned.

That is management. Where did that all begun? At soft skills? Not really... All begins at taking responsibility of deliveries. If you are a beginner, start with the task level. If you work on a task, take the responsibility that the feature is delivered to the release. Do not wait for someone in the team to come around and ensure your task is integrated with other tasks to make the feature integrated in to the release. Similarly take the delivery responsibility of what ever you encounter with.

Finally here is the golden rule of promotions. When you promote some one, he should be the one, to whom if a work is given, you can close your eyes and be guaranteed to get the work be delivered!


[tag: 99xl ]

Friday, August 20, 2010

You know it is immature, when...

It was in the middle of another planning day. A quite simple story is on the discussion table. Story was about downloading an activity log after performing some data import. When it came to the design for the story, the team seemed to be discussing too deep into details. Many technologies and concepts ranging from ‘associating different logger frameworks’ to ‘using a logger facades (e.g. http://www.slf4j.org/) were thrown on to the table in a matter of minutes.

Something was smelly! We were not simple and stupid enough anymore. Our first thought was that we were over engineering the solution. Without a conclusion we decided to break for the day. But I couldn't stop thinking on what had actually gone wrong in that discussion.

About an hour later I realized that it was nothing to with design or over-engineering. The requirement was not concise and story wasn't matured enough to be taken-off. The team and product owner was not able to conclude the file types, message formats, viewer extensions that will be demanded by the users. The result was that team had to design the functionality to be really generic to cater for ‘any’ type of user demand!

Most of the over engineering we do in our projects actually could be due to immature requirements.I learned a lesson of the day. "Think two steps backward, when something is smelly in your next design discussion!"
[tag: 99xp ]

Sunday, August 15, 2010

Ad-hoc to ISO to CMMi to Agile

Process journey of Eurocenter from its inception to date is touching my senses on how teams behave under different process styles. It is interesting to see how a project that required 25 member team at early days is now possible with 8 developers in agile.

Eurocenter processes were ISO certified for about a half a decade now. Those first generation ISO processes were mostly based on RUP practices and assumed ‘big design upfront’ methodology. Quality and productivity is delivered through rigid review/control mechanisms. Feedback loops were of high process importance and the quality actions were mostly reactive and corrective. Still most importantly, ISO brought in predictability to the projects in Eurocenter. With ISO, the effort was reasonably estimated and quality was well controlled at a release to the customer. The risk of never ending chaotic projects was not much seen in Eurocenter after ISO era.

Company moving towards CMMi brought a new dimension to the picture. Rather than being reactive, CMMi shaped the processes to be more "proactive" to achieve quality. An obvious result was a reduction of “rework” effort. We know that reduction of any form of effort meaning more productivity. Important observation is that there was no notable difference of actual amount of work performed in ISO and CMMi based models for a given project. The team composition, role/reporting hierarchy remained more or less same.

Today, most of the Eurocenter projects run with agile/Scrum methodologies. With agile, we have experienced further increase of productivity, but wasn't by reducing the rework as CMMi did. Productivity increase in agile is by reducing the amount of "work" performed to deliver a given requirement scope.

Following diagram shows how effort patterns evolved from ad-hoc processes to agile processes today.

How is this actually possible? Can a methodology reduce the amount of work to perform in delivering a given scope. We know that technology frameworks is capable of doing that.. but a process methodology?

To answer this question let have a look at how a traditional hierarchical team operates in delivering a project. There are typically few guys front ending and a massive machinery is in operation behind the scene (called the back-office). Work, instructions, feedback, reports everything flows up/down the hierarchy. Often in projects, the ones at the bottom of the pyramid never meet the ones at the top.

In this formation, most of the members in the team are actually “creating” work for the others in the team. Instead of delivering value to the customer, there exists small ecosystems that create work and resolve work within. For example, some processes may exist in a way that QA and Dev go in cycles without actually adding any value to the end objective. Dev and QA then make work for the PM, and PM pays back by making more administration work for Dev and QA.

Scrum/agile has actually changed the way teams are structured. Every member gst exposed and gains better visibility to the business requirements. It isn't possible for team members to hide behind others to fool around. Customer/management has good visibility to the work performed by each individual in the team. Teams started getting tuned and developers who were unable to cope up, had to be replaced by better candidates. In overall, around 50% of work performed in mini ecosystems disappeared with agile methodologies and work performed became more relevant to the business needs!

Disclaimer: This is purely from my own observations of my company's process journey. The numbers and information shared here is only for the explanation purpose and does not reflect any actual measures.  
[tag: 99xp ]

Saturday, August 07, 2010

A Dream!



I live not far from the city center, allowing me to drive to office in 30 mins despite the heavy city traffic. But on every average city day, I loose many things I enjoy, far most the nature. I had a dream of a house with big green garden, but in this city not an affordable option for me. Next best was to build the house near a green land, and here I am near a marshland, still not far from the city.

As any other thing, my dreams evolved. I started dreaming of a rooftop garden. After months of effort, I made that dream a true now.




It wasn’t a simple task to make the rooftop water proof. When I consult the specialists doing rooftop gardens, high-tech mechanisms and material was quite expensive to deal with.

I decided to go on my own with the low cost alternatives I would find around. Following is a cross section of my installation.


  • Bottom is the concrete slab structure. it is important to level the slab surface with appropriate tapers for water drainage.
  • Now the water proofing has to be done. I have tried with several water proof coatings without much success. Finally decides to lay a thick polythene sheet on top of the concrete surface to water proof.
  • Then it was evident that this sheet is subjected to get damaged easily. Also it was easy for the water to flow under the sheet from the edges. I decided to lay a very thin concrete layer (0.5 inch) on top of it.
  • Now the water proofing is complete. But before the soil layer, it is important to have a water drainage layer that allows any additional water to flow out. 1-2 inches of concrete gravel layer was good enough to handle that.
  • If soil is directly placed on the gravel layer it can easily block the drainage. Therefore I placed a filter net on top of the gravel layer.
  • Finally the soil layer and plants on top of everything.



It was a bit of experiments to get everything right with available alternatives. But it is quite rewarding to be close to the nature with a bird’s eye view to the marshland.



More than me, little Dinuda is the one enjoying the new space at its best!
The chief architect and team lead of the project was not actually me! it was my father who took the majority of the weight of the project.



[tag: 99xl ]