Archive for the Business Value Category

How to Prioritize Requirements YouTube Video

Posted in Agile, Business Value, Project Backlog, Release Planning with tags , , , on July 24, 2010 by vikramadhiman

I have written about how to prioritize before:

As Agile Product Managers, you are constantly prioritizing requirements to get higher value items out sooner. One approach I saw recently, seems very promising. Here is the video. Go ahead and watch it.

Basically, divide your requirements into four quadrants with Y-axis being Business Value and X-axis being Complexity. Hence, you would ideally do quadrant number 1 first and quadrant number 4 last. You can take a call between quadrant number 2 and quadrant number 3 – depending on what your current business strategy/ pull is. Simple. Do it over and over again and we will always provide higher value first.


Good Enough Software Does Not Mean Bad Software

Posted in Agile, Business Value, Collaboration on December 17, 2009 by vikramadhiman

Software to be released should be just “good enough” and not perfect. You hear that a lot these days. “Good enough” from whose perspective? From the perspective of people who release software or from the perspective of the people who will use software? If it is latter, then who decides what comprises “good enough”?

The thought for this post came from one of people I follow on Twitter @enkerli. In the time I have known Alexandre, I have found him to be extremely patient [he is a teacher of repute and of some experience too]. Yesterday, he tweeted -> “enjoys draft æsthetics yet wishes more developers would release stable products. / adopte certains produits trop rapidement.” You can not but realize that he must have signed up for some web application [we will be using web application scenario in this post] expecting the best, only to be let down by an application where either things are either not there or just do not work. Personally, this happens a lot. I type out the web address of this supposedly great web application after reading a review, blog post, news article – and immediately see tonnes of HTML issues – inconsistent fonts, links not linked [with a # key that seems a favorite of development teams these days], pages that are under construction [with no dates of when you expect these to be working], server bandwidth issues [with web applications unable to handle a few thousand users], forms that won’t submit no matter what you do, pages that go haywire when error messages appear at the top and emails that confuse you further. It is almost as if the teams are not asking if it is “good enough” but even if it is “bad enough”, we can always claim that this is “good enough” for now, more is coming later.

I understand the rush of releasing now than tomorrow, why teams would want to adopt this. If you see lot of people using your application, you know the major risk “Are we building the right thing the right way” is minimized. Further, if the major feedback is on product direction [what the heck is this, abandonment rates are high, XYZ do this better], it is nice to be able to figure out these issues sooner than later. There are multiple ways of checking that [for instance focus group meetings, stakeholder meetings, exclusive previews and private beta]. Probably, like all things that mean no harm, “good enough” is being used by people in a way that suits them. Hence, it is important to understand what exactly “good enough” means. One of the good definitions of “good enough” can be found here. It is more a measure of software quality [and code] – simple, correctness, consistency and completeness. Another good definition can be found here: good enough software is the best software we can write given all the external constraints (money, time, resources, inadequate information, etc) placed on us. It’s certainly not the best software we can write before we clock out to go see our son’s ball game or the best software we can write because we don’t understand the problem space and can’t be bothered to ask. James Bach of Satisfice Inc. describes “good enough” software as making rational choices in the face of market-driven projects. The idea is that it’s okay to ship with bugs as long as you ship with the “right” bugs; that, given enough benefits, the minor problems will be overlooked. You have to be able to distinguish between important and unimportant, necessary and unnecessary. According to Pete McBreen, “The decision to ship is based on the risk of shipping a software product that will be seen as low quality. Once that risk is low enough for the organization, the software is good enough to ship. Conversely, if there are not enough valuable features in the software, even if the defect count is zero, the risk of shipping is too high and the software is not good enough.”

Now, that we saw that “good enough” is not a cosmetic 2 minute pop philosophy concept – the next argument would be “it takes time to write such a software”. Yes, it does. All software needs time to think and write. How much – depends on competence of the people. Like most things Agile, it takes maturity and courage to accept shortcomings to write software that is “good enough” – in a true sense.

Product Vision : The Key Role and Responsibility of Product Owner

Posted in Agile, Business Value with tags , , , , on October 19, 2009 by vikramadhiman

Continuing with the discussion on Product Owner role and responsibilities, and based on two excellent comments from Martizza and SJJH, let us review the key role and responsibility of the Product Owner. One can argue that the four skills/ competence areas highlighted in the Who can become a Product Owner post along with people management and interaction skills, help the Product Owner articulate, defend and refine the Product Vision. One can also argue that this is a separate skill and competence area and some people can just be better at this job even if they do not have the domain knowledge, are not technically sound or have the necessary experience. What will these people then typically possess? I think it would be a mixture of ability to learn [learn very fast], a highly analytical mind [capable of drawing analogies], intuition [strong emotional connect with real and abstract] and a thinking mind [one that can think even when it does not know it is thinking]. These people would generally believe hopelessely in what they are working on – and it is this belief and the conviction that helps them exude the product vision. Hence, when one is looking to appoint or hire someone for Product Owner position, one should see if they identify with the product and what are the ideas they bring to the table. If the connect is established, the rest of the work would flow a lot better.

So, what exactly does a Product Owner do with the Product Vision. They do 03 things:

1. Define the Product Vision – This involves close connect with the customers and market needs. Hence, domain expertise and exposure to tech support/ marketing comes in handy. Further, exposure to some sort of modeling methods helps the Product Owner define the product vision. Often, the Product Vision phase can take long. As a Product Owner, you may consult other domain experts, technical team or embark on marketing feasibility studies to confirm and reconfirm the vision.

2. Articulate the Product Vision – This is more important than 1. Typically, the Product Owner should be available to the development team anytime and everytime. The Product Owner should be able to sit down with different team members – together, in groups or alone – and discuss aspects related to the product – what will happen in 02 years, 02 months and what do they think could happen. This helps build the trust and orients the developers from a Product Owners perspective – a key requirement to build a great product. One of the means available with the Product Owner, to articulate the Product Vision is Product Backlog and ceremonies like Sprint Planning, Sprint Review help achieve this too.

3. Refine the Product Vision – Each time the Product Owner meets people from marketing, sales, technical support, development team, testing team or customers – they will keep uncovering new things about the product. It could just be new technology [Google Wave was launched a few days back for instance] or a new trend [micro-blogging and social media]. This can represent opportunities or threats. Product Vision is not stagnant. It is dynamic.

If a Product Owner can take care of the Product Vision, the Product would largely take care by itself.

Scrum and Agile in a Fixed Price Project Environment

Posted in Agile, Business Value, Contracts with tags , , , , , , on January 16, 2009 by vikramadhiman

A lot of people have been writing that they like what they read and hear about Agile and Scrum. They then give presentations to their senior management about Agile and they seem to like what they read and hear too. However, the biggest stumbling block is fixed-cost environment. This is primarily true for almost all services companies [and these outnumber new product development companies by a margin – my guess]. An amount of funding is bid for at the start of a project. The problem is how to come to a number for these bids.

Here are a couple of approaches to tackle this [which work for me]:

Approach One : Try using Scrum as a management tool without changing your current bidding structure. Once the team has experience with Scrum, then you should have some metrics collected. The team(s) should have an idea about their velocity and more people involved at bidding stage [think of planning for a fixed-cost project as any other Scrum planning session], the team should be able to give a good estimate for the first 2-3 sprints, even for the full
project if that is what’s required. More importantly, they will ask the Product Owner/ Manager/ Client very pertinent and relevant question about priority and testing to evaluate the story. The fixed costs are based on the knowledge you have at time of planning, so you can post these on the contract too. As time goes by, and your sprints commence, the requirements will change and so will your estimates. You can negotiate them using the existing negotiation framework. However, at the end of your budget [fixed price], the product should have these functions implemented that she wanted the most.

Approach Two : Try bidding low, not in price but what are you able to give to the customer as well as be aggressive on the date when you can launch the product. Most customers and product owners/ managers would give their right leg for the same. Try it on a low risk project/ low risk client [one where you have an option of trying]. If you are bidding low, chances of getting the bid right are higher [again that’s just my guess]

You may also like to read Myths about Agile Software Development and Scrum, Agile Collaboration Schemas, Agile Contracts, Contracts in Agile, Business View, Learning and Evolution and Agile Estimating.

Prioritze tasks for web and software development : Issues

Posted in Agile, Business Value, Release Planning with tags , , on September 15, 2008 by vikramadhiman

Any product manager or business analyst has always been stuck with how to prioritize stuff and development work.

The basic approach that people generally use to prioritize development tasks:

  • Write down all the pending development items, as and when you think of them at a common place.
  • Assign them a priority of high, medium or low [or something fancier] and pick up the high priority items first.
  • Keep compiling the list of most high priority items as you go. There are many problems in this kind of prioritization.

The major problem is that any decent sized project/ product would have a lot of development items as open. And most of these items are always high priority or medium priority but not low priority. Hence, you have to do a nested priority tango [where you prioritize between high priority items further with something like Very High Priority, Super High Priority etc], till you are left with the items you can pick up for the next release.

Although very simple to look at, as the data grows, this method becomes a complete mess for you to manage your priorities and also takes a lot of time for managing the priorities. In addition, this gives some items with low priority a wrong interpretation – these are not important, and even worse, confuses the high priority items as the most important. Another major problem that development teams face is classifying the items as bugs, defects, new features, revision of old features etc and sort of prioritizing within this.

Hence, the main problems in the main approach is:

  • As the data grows, managing the priorities becomes an issue
  • Making an item/ task as not important, low priority, can wait, not urgent, good to have – makes people take those tasks/ items lightly
  • Prioritizing within the items/ tasks – bugs, defects, new features, revision of old features

A quick review of Internet threw up some variations of this approach:

  • suggests that you should prioritize the stuff between must do, should do and would like to do. The only problem with this approach is that different arguments can convert a would like to do into a must do.
  • OpenBravo has a delicious looking approach to development process management and takes a linear time bound approach for each task. I have not used OpenBravo as yet but probably this would probably work well in some circumstances as long as you make sure you enter the right data.
  • A common approach in Scrum Projects is to have teams gather around for a Sprint Planning Meeting and arrive at a consensus on what they would need to develop in the next sprint. Everything else waits. This is a good approach. However, the work involved in estimation of the items/ tasks and discussions can sometimes extend. This is not a problem with the approach but signifies something else [communication gap between the teams and product owner]. Unfortunately, not many people would see it like that [I will cover this topic in more detail later].
  • Another very effective approach [again borrowed from Scrum/ Mike Cohn’s work] is to first draft coarse grained requirements and refine the ones that are immediate priority. This takes care of not having too many requirements/ items while still having enough detail for meaningful priority for the tasks / items at hand.

Now that, we have discussed in brief what we probably already know, I will try and analyze why these problems appear.

  • No single product owner
  • Too long a time before priorities can be changed
  • Wasted effort on not so hear horizon tasks [which might never get done, or are changed when those are picked up]

However, the biggest issue is that prioritizing the above way gives you a false sense of security that you understand how the future would unfold. You lock yourself up in decisions [based on a prediction of future, and a growth path/ evolution of product or features]. This is the exact mindset and belief which Agile [or “a”gile ???] seems to correct. The product management teams and development teams, both need to be open to all possibilities. Unless the mindset which develops the products is open, we fight keeping the natural progress of the product [based on customer requests and inputs] at bay.

Now that we have seen the issues in prioritizing using conventional techniques, lets try and see an alternative approach to prioritization.

    SCRUM for Marketing

    Posted in Business Value, SCRUM with tags , on December 9, 2007 by vikramadhiman

    Responding to someone named Dmitry Beransky on SCRUM Development Yahoo Group made me realize that you can use SCRUM pretty much for any of the field. His specific question was regarding how to use it for marketing. Here is what I wrote:

    1. Identify the business goals marketing team would have to meet within a set period – say 06 months [remember the goal should be something like increase the leads inflow by 25%, increase brand awareness in Europe, reduce marketing overhead per dollar of profit by 4% etc etc and not attend 10 trade fairs and write 50 sales flyers]. Prioritize these goals. The Marketing VP/ Head can act as a Product Owner for this.
    2. The second step would probably be very critical. You will need to break down the goals to achievable steps. You will not probably increase leads flow by 25% in one sprint of six weeks [ideal sprint length]. So you need to break it down to something like 4-5% depending on what you think is achievable. Similarly, do it for the rest of goals. Marketing teams generally need to be very responsive and hence, shorter sprint length would be advisable. However, the marketing results typically take longer to appear – hence, longer sprint length would be advisable from that perspective. Focusing on a suitable sprint length will help you focus on specific goals and allowing the team to aim for those uninterrupted.
    3. Divided goals go into specific sprints and now you need to divide goals into activities/ tasks, which will help attain the goal [write flyers, attend fairs, make online presence and what all]. The only difference in getting these sprint tasks is that you might sometimes need to do a planning of 3-4 sprints in advance [fairs might need a stall booking 4 months in advance and getting microsites built might take about two sprints as well]. It is probable that the product owner who can be the marketing VP or similar person sits down with the team dividing the goals into specific activities. Whether or not he assists the team while maintaining their self functioning/ organizing skills, is something the SCRUM Master would need to see.
    4. You might have many distributed marketing offices. You might want to check out “distributed SCRUM” thread for more ideas on that.
    5. After 06 weeks or whatever your sprint length is, do a review and retrospective and start.
    6. One of the key things you might want to see/ keep a check on is the Marketing / Sales is usually a fiercely individualistic and competitive domain. Devising appropriate performance feedback/ results achieved metrics might be useful.

    Of course the final advise as is with all the teams I work with – above are just some pointers. These are supposed to help you in making a suitable start for discussing this internally.

    However, the above outlines the fact that implementing SCRUM in a non-software environment can be a very engaging experience and would be a great place to be a team, Product Owner and a SCRUM Master.

    Potentially shippable code – continued

    Posted in Agile, Business Value, Release Planning, SCRUM with tags , , , on October 15, 2007 by vikramadhiman

    In the last post, we discussed how not to meet potentially shippable code. However, we never really addressed the question as to why is the potentially shippable code that important anyways. It is often argued that the relentless focus on getting to potentially shippable code, is what sets Agile apart from other incremental and iterative processes. This is partly correct. Partly, because there are certain values which Agile stands for and if those are not used for the development, you are not really doing Agile.

    Potentially shippable code as discussed in the previous post is always just one sprint away from shipping. Why this is important is because:

    1. It keeps the focus on priorities for the customer. She knows that all she needs to do to get the product to the market is announce a pre-release sprint and she will get it. After the first few sprints are done, the incentive to organize the product backlog to develop the product in a manner where it could be released any time focuses product owner to provide value to the project by prioritizing the items based on importance, ROI and risk.
    2. The team can think of an iterative and incremental mode of development – with preference to get to overall product structure as soon as possible. In fact is the product backlog has been priorotized well enough, enough value would be got early in the development rather than later, and actually the value added in future sprints could be much less. This provides tremendous ROI for the product owner and again – focuses them on considering priorities on an incremental and iterative level as well.
    3. It focuses the team to install engineering practices which will help them get to really done. Some of XP practices like refactoring, unit testing and code sharing help the teams really perform extremely as well as at a sustained pace.
    4. Overall, it provides an opportunity to get feedback and adjustment.

    One of the tests of whether teams are doing Scrum in Nokia, include reference to “do you provide potentially shippable code at the end of the sprint?”. I have found focus on potentially shippable code really good way to help provide focus for all concerned on product success.