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:

  • OrganizeIt.com 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.

    7 Ways to Fail to Deliver Potentially Shippable Code at end of Sprint

    Posted in Agile, Business Value, Release Planning, SCRUM with tags , , on September 30, 2007 by vikramadhiman

    Before we address the question of how to *not* deliver “potentially shippable code” at the end of the sprint, it would be interesting to define what is “potentially shippable code“. I don’t know where I read this definition – “potentially shippable code” is only a sprint away from release. Whether or not the code is actually shipped or not would of course depend on does it make *business sense* to ship the code right now or after doing another sprint or two. As you are developing based on prioritized set of features and delivering “potentially shippable code”, you are never far from release. However, you are not reading this blog to find out how to produce “potentially shippable code” at the end of each sprint. Rather, we will discuss how you can through lot of “painful, slow and planned” effort not deliver “potentially shippable code“.

    1. Step 1: Do not define DoneLet everyone define what “done” means without communicating on it
      Customer expects to see a tip top UI that functions perfect
      Team is busy building backend and code behind files with lousy UI
      Management thinks the team is building the code that can be supported
    2. Step 2: Departmentalize and Compartmentalize work to be doneYou have to make sure that work is divided in various departments who can blame each other at the end for a job not done. Here are some steps you can take to ensure that:
      Take Quality out and place them in another department with procedural barriers to collaboration among the two teams
      Do the exact thing with UI designers
      If you can do it, divide the work along horizontal layers like database design, business logic design, interface coding etc – the more you can, the better it is
      Do not forget to add ceremony and processes on how different departments should communicate with each other
      You don’t need to include technical writers, UI review surveyors and other support functions in each sprint – have them learn about your months long project in 10 days and churn up some documentation and reviews
      Doing it last minute and hurriedly without a review is the most important thing here
    3. Step 3: Insist on elaborate upfront design documents and architecture designs – Ensure that team worries more about “how they will achieve goals” rather than goals themselves. You can do that pretty easily. Think of the latest modeling techniques and use it to model. Other steps you can try:
      Define all the tasks and their dependencies upfront
      Think about the design rather than what the design should help achieve
      It will help if you can spend a lot of time defining the architecture
      Make developers just Architecture to Code converting units
    4. Step 4: Write crappiest possible code that no one would dare to touch in future – This one take special art, after all by the time anyone will touch the code you wrote, you would be in your third job already. Still, you must plan out in great detail processes which help you write the crappiest code possible:
      To ship potentially shippable code, the team not only needs to work on prioritized features, but also maintain a good velocity – so do everything to ruin it
      Write crappiest possible code [no comments, no standards, no reviews]
      Drive developers to guard their code like treasure
      Make developers horrified of others code [success: this was not my code, why should I fix these bugs]
      Make sure your code breaks the build when you check that in and try doing that the last thing in the day
      Make sure your code has low cohesion and high coupling so that any change in any part of code goes and affects totally unrelated part of the code
    5. Step 5: Code first and test later and if possible leave testing for another sprint – Who wants to do any testing, thats the lowest possible denomination of tasks in a project. Testing is not as sexy as design, analysis, coding and processes. Also, what value does testing provide to the organization or project. Hence, you should make sure your team treats testing as just a necessary evil that has to be done because processes say so. You should try the following to keep this evil as away and as low as possible:
      Testing should be done at the end of the sprint or if possible in the next sprint
      Make sure you don’t write any test cases so that testers have to go through the code and functionality manually each time they do the testing
      Ask testers to test even the smallest change you make to any functionality
      Make responsibility of testing only the QC departments – you are here only to code
    6. Step 6: Change and chop team/ developers – Who wants stability? Management wants flexibility and pre-sales team wants to show developers for new projects. Hence, take as many developers as possible and get new work or shouting customers out of the way. The silent and steady projects mean that they are just too easy to manage and can do with resource snatching. Hence, its important that your developers are constantly changed and chopped between projects between sprints if you want to fail. Additionally, make sure testers, designers etc are changed as well. If you can manage to change SCRUM Masters and Product Owners between the sprint as well, nothing like it
    7. Step 7: Make the same mistakes over and over again - This is important. It’s going to be no use if you make the carefully planned mistakes outlined above and then go about fixing them. Make sure you only discuss what’s going to be served in next sprint retrospective and blame every one else but yourself in Sprint Retrospectives. Do not focus on above issues.

    If after trying all of the above, you can still produce “potentially shippable code” at the end of each sprint, then please call me. We will create a new software development methodology :-)

    Business View, Learning and Evolution

    Posted in Business Value with tags on July 14, 2007 by vikramadhiman

    Viewing IT project [howsoever small] as business projects is one of the fundamental shifts that we as a team have noticed since we have been exposed to agile methods.

    Earlier we used to treat all projects from purely technical viewpoint, not considering enough the problem what we are trying to solve from business perspective. Our role as solution providers was about how we implemented a cool AJAX feature; used service oriented architecture or used n-tier architecture successfully. Rarely, if ever did we consider that will the system attract many users, will users browse beyond the first page, would search engine bots come to the website and get so confused that they would never index more than 5 pages. All this has changed ever since clients have been sitting next to us as we develop and the focus has been on people who will use the system to do the tasks rather than on “users”.

    Another offshoot of the business thinking has been to plan activities using concurrent design methods from first sprint itself. We do not optimize the website for search engines/ usability only after the website development is over. It is an on-going process. Although it means that something does not get built overnight, but when it does, it’s generally robust and scalable.

    We do however realize that we can not possibly get everything done at the outset itself. Some things you learn only after the system has been in use. However, we are happy that we are on a cycle where we do learn it each time and have something new to contribute every time. It keeps the team morale high and the client is more than delighted. Now only if we could learn to get there just right enough each time and on time, it would be great.

    Release Planning and Business Value

    Posted in Agile, Business Value, Release Planning with tags , , on July 4, 2007 by vikramadhiman

    Is it important to think of Release Planning in the same breadth as Business Value? Our readings and discussions over the last week seem to suggest – Yes.

    Generally speaking, a release can comprise of one or more sprints/ iterations.

    • Can we make an assumption that a sprint really is a release?
    • Can we release something every sprint? Also, is release a product release or just a demo to a client ?

    Like all Agile Development practices, it seems that the idea of keeping track of sprints and releases separately has its origins in product development. However, it also seems true that all the projects can probably benefit from this not so subtle difference. Even in these days of software as a service [http://msdn2.microsoft.com/en-us/architecture/aa699384.aspx] the importance of planning a release can not be overlooked. Release planning really is just a collection of stories organized in order of priority and bunched together so that each such collection can be released [i.e. end users can start using the website]. The sprint however is just a collection of stories that the team hopes to complete within a given time period. However, even at the end of a successful sprint you might not have a product or software that you can release for use by potential users or subset of users.

    This is where Release Planning comes in. The emphasis of release planning is business value. The team should not think that a sprint and building features by priority is enough to give a business value. The business value comes from getting users to use the software [or probably want to use the software]. Anything else, no matter how organized and dynamic an environment it creates, does not work from an Agile perspective.

    Follow

    Get every new post delivered to your Inbox.