Detailing Backlog Appropriately

On one of the projects I am managing currently, I noticed that the product backlog was actually growing rather than shrinking as we were progressing through sprints. At one point, there were close to hundred and fifty stories in the backlog, all detailed and ready for planning. Some were even accompanied by ready UI-designs. The reason for the increasing backlog size was that everything under the sun was being thrown into it for future development. While this might sound fine (you would want to write down somewhere the features you might need in the future and what better place to write them down than the backlog), there was something definitely going wrong.

I realised that every time we would plan a new sprint, instead of picking previously written stories from the backlog, we were writing new stories as the client had come up with a new feature that had priority over rest of the backlog. This is completely understandable and even recommended. After all, you would like to use the feedback you are receiving from the market to add new features. If the window of opportunity for a new feature is now, no point putting it on a backlog for later. It requires attention now. But what about all the stories (and the effort invested in detailing them and designing the UI for them) in the backlog? Soon they would become obsolete. They would never see the light of the day. If at all their turn would come, they would require changes (in both the functionality and the UI expected) as the current functionality would have undergone a change by then. In terms of Lean thinking, this was clearly muda (“waste in Japanese). I could have done better things with the time I invested in detailing those stories and helping create their UI-design.

The other day, I was watching a show on some television channel (I think it was Comedy Central) and I noticed the way they presented their schedule:

• Now (the show currently being telecast)
• Later (the show after the current one)
• Never (the show after the “later” one)

This was a fun way to provide a relative schedule, especially the “never” part. Considering that I am always in a “meta” state of mind looking at things above their current context and trying to correlate aspects from different contexts, the schedule format hit me as a solution to my backlog problem.

While the stories in the current and immediate next sprint (“Now” part of the backlog) would be detailed enough, the stories in the next two to three sprints (“Later” part of the backlog) would be relatively coarse grained. Stories even further down in the backlog (“Never” part of the backlog) would have no detail whatsoever. They could be as simple as a single line, five-word statement (similar to epics in Scrum parlance). This would help the backlog stay current and sharp, help me focus my time on more important tasks, and reduce waste. Of course, we would continue to add to the backlog any item we “might” need in the future but it would not be as detailed as before, it would simply be a reminder, like a to-do.

If Scrum was a Motorbike

Scrum and motorbikes, two things that I am very passionate about. Subconsciously, I could sense a parallel between them. When I actively thought about it, the picture became clearer.

Consider the Team (developers, UI designers, testers) in Scrum. Its mandate is to deliver a working increment each iteration. It is what powers the product / project. It is similar to the engine of a motorbike. It converts stored up energy (in the form of fuel) into motion that drives the whole. Akin to a Scrum team, it delivers usable power each cycle of the n-stroke engine. Similar to a Scrum team that iterates over the backlog, the engine iterates over the strokes in each cycle. The way an engine gobbles up fuel to deliver power, the team completes stories from the backlog to deliver a working software.

Now you don’t need to be a gear-head to know the importance of keeping the engine well oiled. That is where the ScrumMaster fits in. He is the engine oil. The oil keeps the engine running smoothly, lubricating it, ensuring that there is no grinding against the metal. Similarly, the ScumMaster keeps the team protected of outside interference, ensures that there are no impediments in the progress, that the team is not overloaded, that there is no grinding between the team members. He keeps the team running smoothly. A good engine oil keeps the parts well lubricated even when the engine is running at a high RPM, the temperature is high, the stress is high. Similarly, a good ScrumMaster ensure that the practices are followed even when the team is under stress (the scenario of the team being under stress is infrequent but possible when the team commits to deliver more than they can complete so as to meet the aggressive goal).

Where does the Product Owner fit in? I believe he is like the handlebar of the motorcycle. The product owner provides direction to the team. It leads the team to the intended goal. If the team deviates, it provides correction (during Sprint Reviews) so that the overall destination can be reached. The way a handlebar can be used to avoid obstacles along the path, the product owner can clarify the doubts of the team to keep them focussed on the right goal.

Of course, there are a lot of other parts in a motorcycle, and many more and varied parallels can be drawn, but this is what struck me. If you keep the above in prime condition, you can assure yourself of a smooth journey. Ride hard, ride well.

Becoming a Certified Scrum Professional

Considering the increasing number of companies practicing Agile, getting a ScrumMaster on the rolls has almost become mandatory. Consequently, lot of people (including PMPs) are getting themselves certified as ScrumMaster (or Certified Scrum Developers / Certified Scrum Product Owners) . After two days training and passing the exam, they consider the job done. If you are one of them, then your journey has only started, my friend.

While becoming a Certified ScrumMaster is relatively simple and straightforward, becoming a Certified Scrum Professional is a different ballgame altogether. If you pay attention during the two day training, you can pass the CSM exam with flying colours. CSP, however requires constant practice. If the input for the CSM exam was theory, then its practice is the input for CSP exam. Consider an analogy – most of us would have studied trigonometry in school or college; how many of us can find the distance to an object close by using triangulation. The inability stems from lack of practice.

CSM training throws a lot of jargons at you – product backlog, burndown chart, sprint planning, etc. It all sounds great during the training. You understand it and take the exam. Get certified and then sit back and relax. Not so fast, mate.

The two-day training should act as only an appetiser. You are yet to enjoy your full course as part of the on-job-training when you practice what you have learnt. You may have a product backlog but you don’t’ spend enough time grooming it. You practice sprints but every once in a while you let it extend for a day or two as the team wasn’t able to finish everything they had committed. You estimate stories but the estimates are not provided by the team. I remember talking to a friend who, on knowing that my company practiced Agile, was boasting about the Agile practices at his company. I simply asked, “who estimates the stories”. Prompt came the reply, “the client”! I wish we were talking face to face rather than on phone and he could see my jaw drop.

Even though the title of the certification has only “Scrum” in it, it also requires a fair brush with methodologies that go well with Scrum, for example eXtreme Programming (XP). I don’t really think that Scrum talks about automation or test driven development but you can’t be fully Agile without it. Lean thinking again works well with Scrum. “Lean inventories” is mirrored in Scrum by having stories detailed just enough to drive conversations, to have stories only higher up in the backlog as detailed and the lower ones as coarse grained. Yes, you learnt about it during your CSM training, but are you practicing it?

ScrumAlliance provides a list of books / articles, one should be well versed with before taking the CSP exam. But that is only a guideline (just like the Agile Manifesto). You need to have a good exposure to Agile practices if you want to earn your certification. The questions are not from a theory book. They are based on scenarios. And most of the times, all the options provided are right. Your experience would tell you which option is the best.
When I got certified as a CSM about 3 years back, I thought I knew it all. But today, after receiving my CSP certification, I can say with full confidence that the CSM was only a spark, the noodles were cooked by a steady practice, observing and stirring (or in terms of Agile – inspecting and adapting).

If you have noticed the number of times I have used the word practice in various forms in this article, you would realise what I am trying to tell you. So my humble suggestion to you is to earn your CSP certification by going through the motions of Agile practices. Follow the road amigo, not the steps.

Faster is Slower

We have all read that story during our childhood where a fast rabbit (or was it a hare) was beaten by a slow, yet steady, tortoise. The importance of sustainable progress was taught to us well in advance but we forgot the lesson while growing up.

We are so rushed about everything that we have forgotten the pleasure of enjoying the moment. Hang on, this blog post is turning into a lecture on “living in the moment”. Well, that’s not what it is going to be. It’s going to be about the challenges I have been facing with some projects while trying to match an aggressive timeline set by the client.

At present, I am managing two projects for a client based out of Nigeria. One of the two projects is a daily-deal web application and the other is an e-commerce site. Both these applications are doing fairly well and generating a sizeable revenue to the client. And the company I work for is happy too, well, at least financially.

But these projects are becoming a death march despite my desperate efforts to the contrary. (I didn’t know Wikipedia had a page on death march in project management).

I can see the development team working till late everyday. The code quality is going down. Time is being spent more on fixing bugs than writing features.

My initial thoughts on this state were that perhaps the team is doing a shoddy job, delivering poor quality work that too late. Which is why they are having to work late to meet the deadline. But I was wrong. Mea culpa.

The whole problem is with the deadline. The word has actually begun to signify a point in the future beyond which lies death.

The whole situation starts like this: the client has a brilliant idea (every month or so) that needs to be taken to the market immediately. The team is expected to start coding even before they have a firm grasp of what they are working on. All this can still make sense as Agile is meant to allow, in fact welcome, frequent change. But not when all the 3 sides of the iron triangle (scope, resources, and time) are set by the client thus strangulating quality that lies within the triangle.

The developers (considering themselves a part of the same team as the client and equally responsible for its success) agree to the deadline often factoring in extra hours in a day and a few Saturdays. Even at this juncture everything looks possible; a stretch goal but possible.

While they are in the middle of the release, suddenly a mail comes announcing some hotfixes (a fix or a quick feature that needs to be deployed to the production site ASAP and has priority over current release / features). The team, again feeling responsible for the application, does those fixes. But the tragedy of this whole story is that the darned deadline doesn’t move a minute!

Mike Cohn, a highly respected writer, speaker, and practitioner of Agile, wrote the following in his book Agile Estimation and Planning:
Leave some slack. Especially when planning an iteration, do not plan on using 100% of every team member’s time. Just as a highway experiences grid- lock when filled to 100% capacity, so will a development team slow down when every person’s time is planned to be used.

This is where we are going wrong. Not only we factor the full eight hours per day of each team member, we also include a couple more so as to meet the deadline. Which is why we never have enough time to write good code in the first place, do a thorough code review, or test the app well. In some cases, unit tests are skipped altogether so as to deliver on time.

This is why I have begun to realise that in trying to become faster, we have become much slower. While we somehow manage to deliver on schedule, a lot of issues that should have been taken care of before releasing to production are looked at after the release. Thus the point of stability moves to well beyond what could have been a justified release date or the deadline with a reduced scope. And it causes heartburn to everyone: to the users who face issues due to buggy code, the client who faces user’s complaints, and the dev team who work day-in day-out.

I have actually experienced an automobile analogy of the above. I had to meet someone at a destined place and time. In order to avoid being late, I rode my motorbike much faster than I normally would only to get into an accident. The meeting got cancelled, my motorbike got damaged, and I got hurt. Faster became slower and expensive.

Considering the software context again, the client frequently gives the example of Apple as a benchmark of quality. However, in trying to attain that benchmark, I would not let my organisation become Foxconn. The team has had enough and I have had enough. It’s time to take a stand even if it means like the one below:

Image Source: http://www.wsm.ie

Buying an SUV

I have always dreamt of owning an SUV, one of those big bad automobiles that seem so invincible. Because dreams don’t have price or other constraints built in, I had my heart set on Hummer. As reality dawned upon me over the years, I realised that I would have to settle for something more practical (and less expensive).

The desire for Hummer was gradually replaced by that for Honda CR-V, a powerful and sporty SUV. However, it lost its appeal over the past couple of design changes and the more compact it grew, the less I liked it. In the meanwhile, I had begun to take a strong liking for Ford Endeavour. The very name made my heart skip a beat. It was simply huge. It actually defined the term SUV for me. Big and powerful.

So when I finally had the purchasing power to buy a car (an SUV to be specific), Endeavour was my first priority. But, because, a lot many SUVs had arrived on the scene by now, I actually had a long list of candidates. The following is a list of models I started with.

Brand	Model	Verdict	Notes	Price – Low (Lakhs)	Price – High (Lakhs)
Mahindra	Thar	Pending	Too brash	5	6
Tata	Safari	Pending	Too common	8	13
Mahindra	XUV 500	Pending	Too common	12	14
Skoda	Yeti	Pending		14	18
Ford	Endeavour	Pending	Too large	15	20
Suzuki	Grand Vitara	Pending		17	19
Chevrolet	Captiva	Pending	Small	19	25
Mitsubishi	Outlander	Pending		21	21
Toyota	Fortuner	Pending		21	22
Mitsubishi	Pajero	Pending		21	25
Hyundai	Santa Fe	Pending		22	25
Ford	Escape	Pending	Awaiting launch
Mahindra	Bolero	No	No visual appeal	6	7
Mahindra	Xylo	No	Not a SUV	7	10
Renault	Duster	No	Small	7	11
Mahindra	Scorpio	No	No visual appeal	8	13
Force	One	No	Not impressive	11	11
Mahindra	Rexton	No	No visual appeal	20	20
BMW	X1	No	Small	22	30
Nissan	X-Trail	No	Not impressive	23	27
Mitsubishi	Montero	No	Too expensive	41	41
Toyota	Land Cruiser Prado	No	Too expensive	60	60
Toyota	Land Cruiser	No	Too expensive	98	98
Land	Rover	No	All expensive models

However, I eliminated almost half of the models (the ones with Verdict as “No”) on the list based on preliminary research.

You might ask why did I put those models on the list in the first place. To answer simply, I didn’t want to look back and think that I left out a model that could have been a good candidate for purchase. Also, I wanted to know for sure that the model I would choose would be better than the others (at least, in my view).

So what are the key factors that I would be basing my decision on? I would list them as under (not necessarily in the order of importance)

• Powerful
• Tall body / high seating
• Muscular looks
• Ample leg room

Once I had the complete list and a set of parameters to rank them on, I decided to take the plunge and started requesting test-drives.

Here’s how it went… but before that a disclaimer:

Please note that the findings below are not based on scientific / statistical information. They are purely my personal experiences and do not attempt to define the vehicle in any way.

Toyota Fortuner

Image source: http://www.toyotafortuner.in

Date of test-drive: 30 Sep 2012

Dealer: Galaxy Toyota

Model driven: 4 x 4 MT

Model preferred (from purchasing perspective): 4 x 2 MT

On road price: Rs 25 lakhs (approx.)

Engine: 3 litre (approx.)

Chassis: Monocoque

Test-drive Results

Details:

Smooth drive despite a potholed road. Perhaps this comes from a good suspension and monocoque body.

Easy manoeuvrability. I was able to turn with a small radius and the power steering greatly helped.

The beast was found wanting in leg room though. When I sat comfortably in front, the passenger behind me was not left with too much space.

Interiors:

The dealer did not have a 4×2 MT to show so I could only superimpose the salesman’s words onto the interiors of 4×2 MT.

The sales person wasn’t very knowledgeable on what features are available in what model of the car. He actually told me that the base 4×2 MT version had SatNav while it doesn’t! Thankfully another sales guy joined us who knew a lot more and could project an honest picture of the car.

Verdict:

Despite the price being on the higher side and the car doing just OK on leg room, a major factor for me, I would still consider it a strong contender.

Ford Endeavour

Image source: http://www.india.ford.com/suvs/endeavour

Date of test-drive: 30 Sep 2012

Dealer: Harpreet Ford

Model driven: 4 x 2 MT

Model preferred (from purchasing perspective): 4 x 2 MT

On road price: Rs 21 lakhs (approx.)

Engine: 3 litre (approx.)

Chassis: Ladder-frame

Test-drive Results

Details:

The ride wasn’t very smooth. I could feel the jerkiness of the vehicle. This could have been because of the ladder-frame chassis. The gear shift was hard and the brake pedal made a noise when pushed. There was no rear camera or even a parking mirror for backing up / parking.

Interiors:

There were no controls on the steering wheel. The control panel extending from the dashboard to the gear level was sadly basic.

However, all’s not doom and gloom with the Endeavour. One aspect where it beats all the other SUVs is leg room. The leg room was more than enough for a giant.

Verdict:

Despite the performance being so-so, I would still consider it in the list of contenders but it is way down in the list.

UPDATE:

Because I had loved the Endeavour since long, I wasn’t going to write it off so easily. So I took another test-drive of it. The car shook when I drove it over the potholes and I could hear lot of thumping and banging from the rear end of the SUV. (No, it’s not what you might be thinking). Owing to the long tail of the car and ladder-frame chassis, the rear end bounced like crazy. Had there been any passengers sitting there, they would have experienced a roller coaster of sorts.

So here’s my final verdict on the Ford Endeavour: No

UPDATE:

Mahindra XUV 500

Image source: http://www.mahindraxuv500.com

Date of test-drive: 1 Oct 2012

Dealer: Sri Durga Automobiles

Model driven: 4 x 2 MT

Model preferred (from purchasing perspective): 4 x 2 MT

On road price: Rs 14.2 lakhs (approx.)

Engine: 2.2 litre (approx.)

Chassis: Monocoque

Test-drive Results

Details:

The ride was surprisingly smooth owing to the monocoque chassis perhaps. Gear shift was easy and the car responded well to accelerator. Easily manoeuvrable. The 4×2 MT model doesn’t come with alloy wheels. And there is one point about the XUV500 that I must mention.

Its overly done.

It is a good car at a good price but, from its looks, it appears as if all the designers woke up one day and decided to add all their design ideas to the same car. The car could have done with less fanciness.

Interiors:

The plastic used in the interiors is not of great quality. There is no rear camera or a parking mirror. Basic interior in general.

Verdict:

A strong contender especially given the performance and the price. Don’t be surprised if it emerges as the final choice.

Tata Safari

Image source: http://www.tatasafari.com

Date of test-drive: 1 Oct 2012

Dealer: Malwa Automobiles

Model driven: VX Dicor 4 x 2 (Manual)

Model preferred (from purchasing perspective): Not sure owing to multiple models going out of production and an expected launch of Tata Safari Storm

On road price: Rs 10 – 11.5 lakhs (approx.)

Engine: 2.2 litre (approx.)

Chassis: Ladder-frame

Test-drive Results

Details:

The ride was ok. Response to acceleration was ok too. Manoeuvrability is wanting. Turning radius is large. Either my foot or the clutch pedal stuck more than once. Lacks important features like airbags.

It was the first SUV in India but it doesn’t seem to have improved much since its first launch. It is the general public opinion that Tata vehicles are similar to commercial trucks that ferry goods. After driving the Safari, I knew why they think so.

The above notion about Tata’s vehicles perhaps carries through to their dealerships as well. The salesperson was rustic in his approach, wasn’t very knowledgeable and the dealership was out of brochures for the Safari.

Interiors:

No steering controls. Control panel is very basic. The plastic used in the interiors is not of great quality. There is no rear camera or a parking mirror.

Verdict:

Given the ride performance, the verdict is definitely a No. I would test-drive the Safari Storm too but unless it makes up on where Dicor falters, the verdict stays.

UPDATE:

Hyundai Santa Fe

Image source: http://www.hyundai.com

Date of test-drive: 5 Oct 2012

Dealer: Hans Hyundai

Model driven: 4 x 2 MT

Model preferred (from purchasing perspective): 4 x 2 MT

On road price: Rs 26.8 lakhs (approx.)

Engine: 2.2 litre (approx.)

Chassis: Ladder-frame

Test-drive Results

Details:

It was an exhilarating ride. The engine was really responsive to the acceleration and the pick-up was good. No jerkiness in the the ride despite an uneven road. Great manoeuvrability too. The SUV comes with 18″ wheels, the largest among the SUVs test driven till now. The SUV doesn’t look as meek as I had thought. Gear Shift was a little hard or maybe it was the hard clutch pedal.

The dealership didn’t even have a brochure explaining the features of the vehicle. On top of that, the salesperson was not really interested in showing me the vehicle and did so as if he was doing me a favour. Gradually, he warmed upto me but understanding the features that actually come with the vehicle was a little tricky as a lot of custom modifications were done to the SUV.

Interiors:

2-3 controls on the steering. Leg room was less. When I sat comfortably, there was less space behind. From the inside, it doesn’t look too big. They say its a 7 seater but I doubt it unless the ones sitting behind are midgets.

Verdict:

Its a great SUV but given the price, the size of the SUV and that of the engine, I would consider it an over priced SUV. My final verdict on it: No.

UPDATE:

Skoda Yeti

Image source: http://www.skoda-auto.co.in

Date of test-drive: 7 Oct 2012

Dealer: Arshia Motors

Model driven: Ambition 4 x 2 MT

Model preferred (from purchasing perspective): Ambition 4 x 2 MT

On road price: Rs 17.6 lakhs (approx.)

Engine: 2.0 litre (approx.)

Chassis: Monocoque

Test-drive Results

Details:

I perhaps had a bigger image of Yeti than it turned out to be. They call it a compact SUV but I believe it is no larger (or powerful) than some of the hatchbacks commonly available today. It is too low to be even considered an SUV. Had Skoda projected it as a hatchback, it might have done better. Acceleration was somewhere between OK and good. Ride comfort was good.

Interiors:

The interiors were OK with leather seats even in the basic model. But leg room left a lot to be desired.

Verdict:

Its a great SUV but given the price, the size of the SUV and that of the engine, I would consider it an over priced SUV. My final verdict on it: No.

UPDATE:

Mitsubishi Outlander

Image source: http://www.outlander.in

Date of test-drive: 10 Oct 2012

Dealer: Asian Motors

Model driven: P-Line Automatic (Petrol)

Model preferred (from purchasing perspective): I wasn’t expecting Mitsubishi to not have a manual or a diesel based SUV so no model preferred

On road price: Rs 23.5 lakhs (approx.)

Engine: 2.4 litre (approx.)

Chassis: Monocoque

Test-drive Results

Details:

There were two shocks that I received in quick succession when the salesperson introduced me to the Outlander. First, it is petrol-only SUV. Second, there is manual variant of it and comes only in automatic. My decision on Outlander was almost made at that moment. However, I still wanted to give it a benefit of doubt. So, I went ahead and test-drove it.

The acceleration was sluggish. This could be because of the automatic transmission as the salesperson told me (I haven’t driven any AT car before so I couldn’t verify his statement). Or this could be specific to the Outlander. Either ways, because it comes only in AT, this is a very real drawback for me.

In manual mode, I could change gears using pedal shift but there was no fun in it as the acceleration still left a lot to be desired.

Interiors:

Seating wasn’t as high as expected but OK. Leg room was good but the steering position was such that I had to push my seat way back lest it would almost rest on my thighs.

The interiors, otherwise, were good and the steering controls were good to have too.

Verdict:

It is a good looking SUV at an OK price but is missing key aspects like diesel and manual variants. My verdict on Outlander: No

Mitsubishi Pajero

As the dealer tells me that the earlier version of Pajero SFX has been discontinued and only Pajero Sport is available which is priced way above my budget. So, this SUV also gets crossed-out

Verdict: No

I would continue to update this blog post as I go about test-driving other models. So stay tuned, my friend…

My Way IS the Highway

Ever since man invented the wheel, he has been passionate about it. That passion has manifested in different people in different ways. Some people are head-over-heels with their cars while others swear by their motorbikes.

I haven’t been untouched by this passion. Since childhood, I used to love motorbikes. As I grew older and could discern different models from each other, I realised that my heart lay in Royal Enfield’s Bullet.

My grandfather rode it when he was in the British army, my dad rode it in his youth, and I was adamant to carry the tradition forward.

So I bought myself a top-of-the line Bullet. Bullet Machismo 350. And that’s when I became a Bulleteer.

Unlike the lower models whose thump is too loud and annoying, Machismo’s thump is just right and sounds music to the ears (okay, I may be a little biased here). Listen carefully and you can hear the sound of tappets, the chain rolling, the silencer thumping, all rolled into one smooth melody. Powerful, yet sophisticated.

Its been 5 years since I have been riding her and I have been maintaining her rather well as you can see in this picture. My neighbours see me spending half an hour every morning cleaning and scrubbing it before I leave for work. Once an elderly neighbour finally walked up to me and said, “You take care of it as if it were your son-in-law” (Indian tradition has it that son-in-laws were really respected and cared for). I responded with, “No, I take care of it as if it were my WIFE”!

And my relationship with my Bullet has been like that. We have taken care of each other well and, occasionally, like a real wife, she has hurt me (I have two burn marks on my leg caused by its silencer) and has been burning a hole in my pocket (with rising fuel costs and frequent maintenance)! But, overall, I am quite content with her.

Unlike those who race their plastic toy bikes on the roads to derive pleasure, I simply ride it at an easy speed because the ride IS the pleasure. As I once read on some social network page on Bullet, “You may zip ahead on your toy bike. Your girl still can’t take her eyes off me“. Riding it slowly one feels like a king for whom the peasantry gives way and the commoners turn their heads to get a glimpse of the majestic.

Of late, I converted her to a single-seater as the rear seat has rarely been used in the past 5 years. And a single-seater Bullet looks all the more beautiful.

Given my passion for engines and everything mechanical, I have been trying to tinker with it in order to keep it ship-shape. As a result, I have become friends with a lot of repair shops around as I keep asking them about the Bullet’s internal mechanics.

Most of the roads in New Delhi being chock-a-block with traffic, I relish the early morning ride to Gurudwara every Sunday as I can always enjoy the open roads and the cool weather. Tomorrow being a Sunday, I am already looking forward to the ride. And I am hoping to ride the recently opened highway from New Delhi to Agra soon. If its even close to what is being said about it in news, I am sure I am going to love it.

This blog post won’t be complete without mentioning an incident that happened about two years ago. I was riding along the Upper Ridge road when I realised another rider on my wing. Both of us looked at each other’s ride, admired it, and then gave each other a thumbs up almost synchronously. My ride: Bullet Machismo 350. His, ditto.

Ride on, my friend.

Product Owner 2.0 – Ownership and Beyond

I had the opportunity to present on this topic recently at a ScrumIndia Conference organised in NCR, India.

As part of my current role of a Project Manager, I have been playing the role of Product Owner for all the projects I have been managing. I started as the vanilla Product Owner that Scrum outlines; continuing to improvise when hit by an obstacle or looking for opportunities to improve. It has been a tremendous learning experience while working with all kinds of clients and teams of different maturity levels on projects of various complexities. My presentation at the conference talked about such practices / beliefs / views.

My experience has primarily been on client projects rather than on internal projects / products. So, to that extent, my perspective might be skewed. But, in my humble opinion, the points I illustrate are independent of the sponsor of the project (external or internal).

So lets start…

Summarising the literature that is available on Agile, one can define the typical role of PO as follows:

• Responsible for maximizing the value of the work that the Team does
• Owns the vision and overall goals
• Owns the prioritized list of what needs to be produced to achieve maximum value and ROI (the Product Backlog)
• Decides when product is ready to ship

Now, lets see what would separate a PO 2.0 from a PO:

1. PO stands for Proud Owner

PO doesn’t stand for just Product Owner. It also stands for Proud Owner.

PO 2.0 doesn’t consider a project as just one of the many. He is proud to be a part of it. Like Harley owners who consider themselves privileged to own one (I am a Bulleteer myself so I know the feeling), the PO wears the project name on his sleeve and at times even flaunts it (I have done that a couple of times )

2. Says NO to Feature Requests

How frequently features built into a software are used

A PO is meant to define the product by prioritising the features that would go into a product. While a traditional PO would blindly go forward with a feature request from the sponsor, PO 2.0 would actively say no to features that he feels would not add significant value to the project. So, he wouldn’t go by the sponsor’s whims and fancies but base his decisions on logic and past experience. The above graphic illustrates why its best to say no to some feature requests.

Many a times I have had feature requests that I have found to be frivolous or for one-time use only. I have always preferred simplicity in such scenarios. For example, instead of providing an email editing functionality to the admin for an email that would be sent only once, I preferred taking the content and design from the client and having the devs trigger it themselves.

3. Takes Input from the TEAM

A PO is expected to take his inputs from the client and prioritise that for devs to work on. However, PO 2.0 also takes input from the team. They are where the rubber meets the road. Sometimes, they can provide critical insight into what feature to add and what to remove in order to make the whole product sharper.

On a recent e-commerce project, the team pointed out that we should include the product categories and brands into meta tags for products as that would be helpful on the SEO front. Quite a sensible advise, I would say.

4. Creates for Himself

PO 2.0 doesn’t work for someone else. He works for himself, even when he is the surrogate client. He takes the term “Product Owner” to its literal meaning. It is this belief in his heart that motivates his decisions. When the guys at 37Signals went about creating a project management tool for themselves, they ended up creating one that has now earned the love of millions of people around the globe. Ditto with Blinksale.

When I am envisioning the Information Architecture of a project or ruminating about a feature, I alway keep in mind, “how would I like it; how would I prefer to use it”.

5. Defends the Product

This ties in closely with my points 1 and 4 above. PO 2.0 is as passionate about the product as the sponsor / client. Which is why he considers it his responsibility to defend the product. Its his baby too and he would not let any harm come to it.

Sometime back, we had launched a project that drew a lot of attention, some good and some bad. I came across this blogger who was ranting about the application while knowing zilch about it. I wrote back to him clarifying all his points with links to the relevant sections on the app. Never got a response back from him but further comments from readers were heartening.

6. Is the SCRUM MASTER

I would wait while you get some air ‘cos I know you would have gasped on reading this!

Scrum framework details the roles and responsibilities for a Product Owner and a ScrumMaster. However, I am yet to find a scenario where they contradict each other. It is widely held that the PO and SM should be different persons but I have been performing these 2 roles for so many years now and on so many projects and have been successful all along.

I don’t subscribe to the view that the PO is supposed to be pushy about features and at loggerheads with the SM. I have tried to balance these two roles and successfully so.

I would take your leave now so that you can ponder over that last thought…

You can download the slide deck I had presented here. (size: 3.2MB)

Image Sources:

• http://www.patchstop.com
• http://www.bbc.co.uk
• http://www.sodahead.com
• http://www.redalpaca.com