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. 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 ]