agile – Page 3 – Rajat Bhalla

Don’t Snooze Technical Debt

Beep! Beep! Beep!…. goes your alarm clock. Yawwwwn! (what the hell). Snooze!
After 15 minutes…
Beep! Beep! Beep!….. (the darned clock). Snooze!
After 15 minutes…
Beep! Beep! Beep!…. (damn it, I am late)!!!

Sounds familiar? Most mornings (especially the ones on Mondays) are like this. I am wondering if this behaviour of being lazy has made its way to other aspects of our life too, particularly, software development.

We are in a mad rush to meet the launch deadline so we decide to skimp on some quality, cut a corner here and there, essentially creating a product held together with gum and baling wire. We agree to attend to those quality issues later, replace those quick-fixes with a better solution in the next release. The product launches and is well received. And in the process we receive some rich feedback on what new features to include. Or maybe the launch isn’t as exciting as we had anticipated and we consider some features to add more teeth to the product. Either way, we are in the mad rush all over again to quickly add the new features to our product. So we decide to postpone replacing those quick-fixes again and in the rush to release soon, we accumulate some more quick-fixes and cut corners. The release happens and thereafter we create another list of features to include in the next release. We also include, rather grudgingly though (as we are in a rush again), some quick-fix replacements that we had promised earlier. But now, while working on this release, we realise it is getting difficult to add new features. The product breaks at unanticipated areas whenever we make a small change. Those quick-fixes have rendered the product unmaintainable. So we are spending more time managing the mess rather than making improvements / changes. In the process of becoming faster, we have actually become slower. In short, we are having challenges repaying our technical debt that we have accumulated and now the interest for the debt is more than the principal. This is what happens if you keep hitting the snooze button on your technical debt.

While it is acceptable to prioritise quality issues and work on the most urgent ones for now (do some quick-fixes for now), it is imperative that those quick-fixes get replaced by more elegant solutions as soon as possible. If you fail to keep a check on the accumulating technical debt, the product soon turns into spaghetti that no one can segregate (or even eat). The old adage “a stitch in time saves nine” emphasises the above points. Looks like our forefathers were wiser than us after all.

So, if you want to have your product grow continuously, you would have to keep the technical debt low.

Don’t snooze, wake up!

Agile

Prioritising Product Development

I want a big car (well, more than one), a large mansion, and definitely a yacht too…NOW! We have all had this dream (or maybe you have better sense than me). But we know we can’t get all of it at the same time. We may get some of it gradually. So what do we do? We prioritise. And we work with what we have. So instead of a big car, I am happy to have a car big enough for my family. I am okay with an apartment that can house my family comfortably for now. I will work towards getting a bigger house but that would come later. The yacht might never come. This is true of the physical universe we occupy.

Software dreams aren’t very different from regular dreams. We want a beautifully designed app and having all the features we can think of (including a hair trimmer and missile launcher). Now. And guess what. Software reality isn’t different from the physical reality too. So, we prioritise. And we iterate over things improving them continuously till we achieve the desired result.

An Agile Development Plan for a product starts with the strategy and vision at the highest level. The next level consists of feature releases in-line with the high level strategy. The next lower level breaks down releases into iterations that build the features planned in the release bit by bit incrementally. There are two ways to look at the schema of things. Vertical drilling would involve peeling layers of the strategy as above. Horizontal panning would involve prioritising features across the timeline of the project development schedule. The whole gamut is prioritised – what would be required when entering the market to attract early adopters, what all features to build thereafter to strengthen the hold and enhance the customer base, and finally, how to add value to the product iteratively and incrementally.

You start by creating a Minimum Viable Product (MVP in short). An MVP is not a low-quality, half-baked product. It is a subset of the whole product with main objectives of getting initial traction and generating feedback. That feedback provides input into the prioritisation process (and release strategy) on what features need to be included in the next release. Each release generates more feedback that is fed back into the system for improvement. Within each release plan are features that are improved iteration by iteration. Each iteration encompasses a list of user stories which are again prioritised for delivery within that iteration. So even if something doesn’t make it to the release, it is always the lowest priority item for that iteration.

The key points to remember are:

You do not plan everything in detail all at once. You plan in layers.
Not everything has the same priority. Features and releases are prioritised along the development cycle.
More emphasis is laid on the feedback in order to laser focus the product to the market rather than initial all-inclusive feature set of the product.

Agile

Better Sprint Planning

A Sprint Planning meeting produces the following artefacts

A Sprint Goal which is a short description about what the Product Owner (PO) and the team have agreed to achieve in the Sprint.
A Sprint Backlog which is a set of prioritised and estimated user stories and their respective tasks that the team has committed to in order to achieve the Sprint Goal

The team needs to have full clarity on both the above artefacts in order to deliver working (shippable) software in accordance with their Definition of Done at the end of the Sprint. So that the Sprint is worth the while of the team and worth the money the client is spending for that Sprint, each member of the team needs to understand the Sprint’s stories and the tasks included therein well. This also includes the UI designs or wireframes for each story included in that Sprint. While the stories describe the functionality, the UI designs / wireframes describe the form.

Let’s look at the Steps of a Sprint Planning meeting:

1. Review the Product Backlog

The PO starts describing the stories from the top of the backlog along with their respective UI designs/wireframes. The team usually asks questions regarding the stories being discussed which the PO answers. Once the team has complete clarity on what needs to be done to complete the user story, the team creates a list of tasks (usually technical in nature) for each user story. The QA person (if you have a specific person for this role) also mentions some test cases he would use for black box testing. However, he is free to include them during the course of the Sprint too. What is relevant and what is not can always be discussed among the team and the PO.

2. Estimate the Sprint Backlog

When the team feels they have discussed enough stories from the top of the backlog, they start estimating the same. The preferred way is to estimate stories in Story Points and use Planning Poker so that everyone is on the same page and the estimate has acceptance within the team.

3. Commit

Based on the team’s current velocity and the time available within the Sprint, the team makes a commitment on what stories it would complete at the end of the Sprint as per the definition of done without skimping on quality.

Now let’s try and understand a Sprint Backlog in depth so that we know the expected output from a Sprint Planning meeting. A Sprint Backlog has the following attributes:

It is a subset of the Product Backlog
- Whatever the PO/Client feels needs to be a part of the product forms the Product Backlog. The Sprint Backlog is a subset of it i.e., it cannot include anything that is not a part of the Product Backlog. Sometimes, there is a need for some technical housekeeping for which the team can request the PO to include (and prioritise) in the Product Backlog. They can be included in Sprint Backlog too provided they are a part of the Product Backlog first.

A Sprint Backlog requires a commitment from the team on what would be delivered at the end of the Sprint. This team commitment needs to:
- be clearly understood and agreed upon by every single member of the team and the PO too
- be achievable without sacrificing quality
- be achievable without sacrificing sustainable pace (it is okay to stretch once in a while but not every time)

So now we know what is expected out of Sprint Planning and what are the steps thereof. Let’s now consider some salient points that contribute towards a fruitful Sprint Planning

Fixed Start and End Days

A Sprint needs to start and end on the same days (I am considering Sprints that are 1-week, 2-week, n-week long). So if your Sprint cycle is Monday to Friday, it should never change. This helps get into a periodic rhythm that is felt by the entire team. All Sprints are equal sized and this never changes. A Sprint is all inclusive. Apart from the project development, it also includes Sprint Planning at the start and Sprint Review and Retrospective at the end.

Include Everyone

A Sprint Planning includes everyone on the project – the PO (and the client too if possible), the Team (including the developers, QA persons, UI design persons), and ScrumMaster

Sync Sprint Plan With the Client

If the client is not present in the Sprint Planning meeting and the meeting is chaired by the PO, it is imperative that the PO syncs up with client to apprise him of what all has been committed to in the Sprint Planning. The client might have a rough idea initially as he had prioritised the backlog but this sync up would make sure he knows for sure what to expect at the end of the Sprint.

Include Spikes

As it happens on most complex projects, there are functionalities / technologies which no one in the team might have experience with. Such functionalities require researching and building a proof of concept perhaps. For such unknowns, it is good to include a small time box within the Sprint (one or two days for example) for researching and checking the viability. This is done a Sprint in advance. Such a spike reduces the uncertainty when the team comes across implementing the functionality actually and helps them estimate the story appropriately.

Abnormal Termination

There may be a rare case that the Sprint Goal that the team is chasing becomes irrelevant in the middle of the Sprint. In such a case, the Sprint can be terminated in the middle and then a new Sprint is planned. However such terminations should be exceptions, not rules. Whenever you have changes being requested to the current Sprint, they should be prioritised to be taken up in the next Sprint. Only in the extreme case should one consider terminating a Sprint in progress.

Now that we have a good hang of what a Sprint Planning (and Sprint) includes, let’s look at Five Commandments for Sprint Planning

1. Thou Shall Stay a Sprint Ahead of the Team

The PO should stay a Sprint ahead of the team grooming the backlog, making sure that the epics are broken down into user stories, arranging the UI designs / wireframes for the stories in the upcoming Sprint, and identifying stories that might need Spikes to be included in the current Sprint.

2. Thou Shalt Not Extend the Sprint

It’s possible that the team is left with an incomplete story at the end of the Sprint. They might consider extending the Sprint by a day or two to complete the pending work and fulfil the commitment they made at the start of the Sprint. This should never be done. Never, ever. Sprint delivery includes completed stories and incomplete / pending work gets put back on the backlog for prioritisation. The Sprint is never extended. This ties in with the point above of having Fixed Start and End Days.

3. Thou Shalt Not Include Extra Time

Never factor in extra time (apart from working hours) in a Sprint. PO / team might be tempted to consider after hours or weekends to meet an aggressive target or complete stories committed in a Sprint. This can be considered only in the rarest of rare cases and should never be encouraged. This ties in to the principle of sustainable pace within a Sprint. While it can be permitted for a couple of days in the project, any longer than that and the team would be setting itself up for failure and lower productivity.

4. Thou Shalt Not Add More Work

Adding more work in the middle of a Sprint is something that Agile is strongly against. The team commits to a set of stories according to their Definition of Done that makes their Sprint Backlog. That backlog should not be messed with. The PO should not try to add / change stuff that is already a part of the Sprint Backlog. Only if the team agrees can the PO swap some item in the backlog with another equally sized item provided it doesn’t derail the Sprint. Any changes can be considered in the next Sprint. But no work should be added to Sprint. However, if the team finishes early, they are allowed to pull in more stuff from the Product Backlog into their Sprint Backlog but not otherwise. Adding more work to a Sprint in target would amount to hitting a moving target and is a sure shot recipe for disaster.

5. Thou Shall Deliver After Each Sprint

The team should deliver working software as per the Sprint Backlog and the Definition of Done after each sprint. No exceptions. This should be delivered to the PO / client for User Acceptance Testing and any changes / feedback should be put back on the Product Backlog for prioritisation.

There is the concept of a Sprint 0 that is a double edged sword. It can have its benefits if handled properly else it can cause you to slide back into Waterfall. The purpose of a Sprint 0 is to:

bring the team together and give them a high level overview of the project
set up tools (code repository, project management, story board tool, etc.) for the project
check tech feasibility of risky components of the project
get UI design and wireframes done for the first Sprint
break down epics into user stories for Sprint 1
arrange resources like App Store developer account, servers for development / testing, emails for support, etc.

Sprint 0 should not be mistaken for a mini Waterfall wherein all stories are attempted to be defined in detail upfront, UI design completed upfront, etc. All these tasks happen Sprint by Sprint (being one Sprint ahead of the team). The focus should be on emergent design (both architecture design and UI design) during the course of the project and not everything upfront.

Though the above seems like a lot (and probably it is) but once you get into a rhythm of doing it, it becomes natural. It is similar to learning to drive a car wherein you have to do a lot at the same time – control the steering wheel, keep the foot on the accelerator, change gears occasionally while pressing the clutch, look in front, look in the rear view mirror, look in the side view mirror, be ready to hit the brakes! After some time it gets so smooth that you can do all the above (and more *wink*) with ease. Same is true with Sprint Planning. If you learn to do it well, the project execution would be very smooth.

Agile

Scrum Roles

Scrum is by far the most popular framework under the umbrella of Agile software development frameworks. It allows for greater visibility to product sponsors while allowing the development teams to build incrementally and iteratively.

For Scrum to be successful, it needs a certain degree of discipline. That discipline requires that team members have specific roles and responsibilities even when they are encouraged to be cross-functional and support other team members from time to time.

Scrum defines 3 roles – Product Owner (PO), ScrumMaster (SM), and Team.

The PO is what it sounds like. This person owns the product from a functional perspective. He writes the user stories and puts them into the backlog. Before each Sprint, he refines the backlog to ensure that the stories are the right size in terms of effort and complexity for the development team to work on. He ensures that the backlog is prioritised at all times (highest priority stories at the top of the backlog and lowest at the bottom). He frequently grooms the backlog akin to grooming a garden – removes stories which would not be required in the future, adding new stories to the backlog, and refining the ones already on it. Whenever, the team seeks any clarification on the functionality or the priority of the stories, he is their go-to guy.

The way a PO owns the product, the SM owns the process. While the PO ensures that the team build the right product, the SM ensures that the team builds the product right. He works with the PO in ensuring that the all meetings required to make the product and process smoother (Sprint Planning, Daily Scrum, Sprint Review, and Retrospective) are held regularly and in the right spirit. He makes sure that the development team is not pressurised into taking on more work than they can handle. While the PO is busy gathering and giving feedback about the product, the SM does so for the process.

The third and equally important role is that of the Team. The Team comprises of anyone and everyone working on the product technically. It includes developers, UI designers, and testers. They are responsible for building the product as per the acceptance criteria specified by the PO while following the process set by the SM. They own the quality of the product. They have a right to take on only as much work as they can finish in a Sprint without compromising on quality. They are also welcome to request the PO to include stories that would benefit the product quality and maintainability.

Together, the three roles in a scrum form the 3 sides of the project pyramid and offer great stability to the development process. Together, they ensure that the right product is being built right. If any role takes on a weak or a dominating stance in the team, the project suffers. Thus, it is imperative for each of these three engines to fire consistently in order to move the ship forward.

The team is also referred to as “Pigs” (because they are committed to the project) while the PO and SM are referred as “Chickens” (because they are just involved). The following image lends context to this nomenclature.

Agile

Agility @ Appster

As on today, I am working with Appster as an Agile Coach and Senior Project Manager. Here’s what I have to say about the process we are following at Appster.

In order to build a great product, you need to have a greater process. A process that is simple yet flexible. A process that lays emphasis on quality yet allows change as you go. Agile emerged as an answer to this need. It is a software development framework suited to humans – people cannot predict the future accurately and would like changes to be accommodated in their plans; humans can focus only one or two items at the same time and not the whole gamut. A quick look at the Agile Manifesto assures one to the flexibility inherent in an Agile development environment.

At Appster, we are trying to imbibe the spirit of Agile in its purest form. It all begins with the signing of an Agile contract with the client. The client is not bound into an iron-clad contract (reminiscent of the Waterfall model of software development) but allowed to make changes to it as long as the primary constraint (scope / time / cost) is unaffected.

The client’s requirements are captured not in an exhaustive document covering reams of paper but into high level User Stories (called as Epics). Epics allow the client to express the desired functionality easily while leaving enough room for change / discussions.

Then the dev team breaks down these epics into smaller User Stories that are the right size for development and planning. The entire development is broken down into two-week long iterations called Sprints. At the beginning of each Sprint, the highest priority User Stories are discussed in detail and planned to be completed during that Sprint. The design, development, and testing for each User Story is encompassed within the Sprint only. This is in sharp contrast to Waterfall development wherein each of these was a phase in itself. At the end of the Sprint, the client is presented with working software in the form of a build. While the client does User Acceptance Testing of the build, the team retrospects about how it performed in the last Sprint and what improvements it can include in future Sprints.

During the development, the client is welcome to change any requirement for which work hasn’t started already. The client is free to make changes inline with the scope / timeline agreed upon. The team approaches client interaction with a mindset of collaboration rather than contract negotiation. Even changes that are beyond the contract are acceptable if both the parties are willing.

The above process allows the dev team to deliver working software frequently and in increments. It allows the client to be deeply involved with the development process and see his app take shape and grow like a tree. It also allows (and even welcomes) changes to the application that make it relevant to the current situation of the market and competition.

Agile

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.

Agile, Automobiles

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.

Agile

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.

Agile, Productivity

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

Agile

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

Usage of Features — 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: