The DNA of CHAOS. Why software projects, peace negotiations and football games all come up short on occasion and the true value proposition of agile

Why Business analysts, Product Owners, negotiators, political reformers, scientists and many others are doomed to repeat the same mistakes until they drown in in their failures.

  1. Most people in a work situation, and indeed in most situations, live in a consciousness that is deliberately falsified to reflect (a) what they believe is expected of them by peers, and (b) what the asker of a given question wants to hear. This is a conditioned response and nobody’s fault.  Terms like “Group Think” attempt to explain it, but none really explain the phenomenon well and the long version is just beyond our scope in this piece. Market researchers are trained to try and avoid it, Politicians and advertisers learn to harness it. If you have the role of finding out what  a business wants to do so you can get the software designed to support, it, you will be faced with the same  aggravated problem. Asking and listening simply won’t get the job done.
  2. For reasons I don’t claim to understand fully, most people have a favourite solution in their minds for most problems they are aware of. Expensive  housing – they may say; “Stop immigrants coming in”.  The call centres is too expensive and eating our profits- they may say; “ Close the call centre and let them use Twitter”. Always there is an obvious political, or financial gain for the responder from this solution. If it is a senior executive, or politician, there will be cleverly argued points and tables of figures that make her pet solution look like a no-brainer.
  3. Michael D Cohen  coined the phrase “Garbage Can Theory” to describe this phenomenon which permeates politics, business, the playground and just about every area of human life crippling every endeavour to improve our lot century after century. If you are trying to get your proposal through programme and investment boards, or trying to agree a solution closer the coal-face you will drown unless you understand this phenomenon and take steps to work with it.
  4. Many researchers and writers have agreed strongly that the human brain makes virtually all decisions in a matter of time between milliseconds and 1 to 3 seconds, but then spend enormous amounts of time and effort researching in order to prove their decision was correct. Most people are entirely unaware that they do so.  This of course is not news to Scientific researchers who often publish the theory before beginning on the research.  In the academic world where we have to start somewhere this can be a useful approach. Product managers and entrepreneurs also start with the theory and are difficult to budge even when wrong, yet these leaders are necessary to get something started at all.
  5. People are conditioned to follow a strong leader and will convince themselves of their support for any theory put forward by this leader. This is largely an extension of  point one, but worth being aware of all the same when venturing into any group to arrive at a shared view.

These Five forces combined thwart just about every effort to form a good business strategy with technology in mind, agree a solution and still be in agreement when the solution is completed to specification even a few months later, let alone after a year or more. Waterfall and other methods of managing the software delivery process all rely on a simplistic view that if you gather enough requirements from users and stakeholders, you can then haggle over priority and build the killer solution to solve everyone’s problems. In reality, there is rarely any agreement, there is even less concern over business outcomes and near- total focus on the many garbage can solutions. Nothing this project could deliver is ever likely to meet the satisfaction of more than a small proportion of stakeholders, the others are always going to be loud in their dissatisfaction and only by sheer luck is their ever going to be serious business benefit.  This project, however well the techies perform will be added to the list of “failures” and the cause will be placed at the CIO’s door. Failure to focus on goals Developers and technical architects are driven by developing exciting new toys. That is their package in the garbage can. Techies ultimately want and are entitled to, clear definitions of what they must build.  They then build and test precisely what you asked for and give it to you working  very well. Few people would try to argue with that, let alone succeed.  The problem is that what you asked for does not always address the problem you needed solved and in fairness the developer or indeed the CIO is not to blame. There is one technique that all accomplished negotiators agree on whether brokering peace in a war zone or negotiating a business contract. YOU MUST KEEP THEM FOCUSED ON GOALS NOT SOLUTIONS! If you don’t, the garbage can will take over.
One cause  of the problem is not using the effective solutions we already have,
The need to focus on goals rather than solutions is not  new to the software industry by the way.  MSP, Prince2 and TOGAF are frameworks I am personally very familiar with, all of which, when used correctly, focus on outcomes required, the solutions that will best deliver those outcomes and the details of each solution, in that order. BABOK and the ISEB framework for business analysis also follow these same principals and are very clear about it. The problem is that few people make any attempt to use their training effectively, the training is rushed and focused only on answering multiple choice questions to gain a certificate and of course the majority of people involved in the business have no training at all. This same scenario, by the way, applies equally to Scrum. Scrum solves some of the problem Scrum attempts to alleviate the problem in a different way and with a similar level of success. Scrum is invented and owned by the technical community as a direct response to these issues plus the difficulty of communicating the complexity of technology with business people. The Scrum team wants only to be given an unambiguous requirement so they can do what they studied for, build great software. They place the onus on the business to appoint, or work with a Product Owner who will be seconded to their team and take all responsibility for the definition of the Product/System.   Communication issues are solved by very short Sprints of just two weeks typically and using prototypes and working software to describe things to the product owner in place of documents. Initially this arrangement solves the problems for the Scrum team, there is no ambiguity about what they must build, they do as much work as the Product Owner wants and stop when he is satisfied. There is no room for dissatisfaction with the IT team. Likewise for the Product Owner, if he is unsure, he can build something , test it on real world scenarios and then make adjustments until it delivers the right outcomes or scrap it altogether.
Inspect and adapt solves problems with lack of knowledge, but also masks others Scrum tries to tackle the strategic questions by replacing strategic decisions and documents with Inspect and adapt. For online products and for certain internal systems, this works extremely well because you can build the minimum, get it working and in use, learn from success or failure and add a little more, remove some, or start again. The risks are lower, failures are smaller and less expensive and the problems with groupthink, daydreaming and garbage cans are alleviated by an early sobering splash of cold reality that comes with release of a Minimal Viable Product. What is often wrong with this approach and fatally dangerous, is the lack of a strategic layer to the thinking process. Inspect and adapt is a close cousin of the OODA loop as defined by Colonel John Boyd. The principal is very simple that in a dynamic environment, he who has the most clear view of the situation always wins given a reasonable ability to make decisions.  Pilots flying inferior jets were seen to consistently win dogfights  because they had a better view from the cockpit and could make better decisions faster.  Developing OODA  (Observe, Orientate, Decide, Act ) and teaching it to pilots made significant improvements over giving them a detailed instruction, or a faster Jet because as the military have always recognised, in the field, the operative has superior knowledge in the heat of battle and must have the right level of autonomy and confidence to decide and act. No military  has ever cut loose a person, or team, or unmanned drone to inspect and adapt and just stay out there. There has to be a clear goal, a Definition of Done, Principals that guide it in the field and a strategy for completing the mission. Then Inspect and Adapt comes into play and in the same way that the human brain itself learns,  the actions  in the field can feed all the way back to sometimes cause a change in strategy or even a revision in Principals, but  actors in the field DO NOT  GO AWOL. Principals and strategy come first and Inspect and Adapt is a response to exceptions , it is not the  plan.

The real reason why Agile/Scrum is winning friends in the world of software and gaining attention beyond these confines

I say Agile/Scrum because when most people speak of agile they are really referring  to Scrum. However Scrum has encompassed much from other Agile implementations and definitely does not hold the sole franchise on Agile methods. The first problem Scrum had to address was the great chasm between Business leaders and Technology leaders.  Various versions of the same solution see the business seconding someone to the Scrum team, or colocation of business and technical people working on the same project. This is a perennial problem sometimes referred to as silos and secondment or colocation of cross discipline teams is a useful technique that helps, but doesn’t alone solve the problems. In the case of Scrum it forces the business into making decisions for better or for worse and living or dying by them. That helps techies to get on with building stuff, but it doesn’t, of itself, help the business much with getting the strategy right. I.E they produce more stuff, but don’t necessarily solve more problems. The next problem Scrum had to address is helping the business in dealing with the unknown. The speed of change is much greater in the past few decades driven by the fast pace of disruptive technology. Organisations are faced with problems they can’t analyse easily and therefore can’t solve. They also find that when they know the problem, they don’t have an obvious solution. This is the situation Scrum was designed for in its entirety. A Scrum team can make a best guess and very quickly get a potential solution in front of customers, Inspect and Adapt and return quickly with an improved effort until the right solution is reached by trial and error and then it can be built upon until it reaches its optimum scale. The biggest problem addressed by Scrum and that one that is causing all the excitement is the almost  total  lack of leadership throughout modern businesses (the past 10 years). Few would lament the passing of the great Command and Control organisations, but with them went whatever semblance of leadership we had in organisations. In the Flat organisation leadership in name is often cited, but leadership in deed is sometimes frowned upon or even punished. In the 80s and 90s business leaders bullishly wrote books about leadership and motivation. These were charismatic people with an instinct for what made others tick.   Kenneth Blanchard, Peter  Drucker, Stephen R Covey and their like gave us the ideas and the passion to change things and build things. We somehow lost this passion and insight in the transition.  Scrum is a beacon in the dark, because it values people and their interactions over trails of evidence. It values achievement over promises and it values self-improvement  and job satisfaction. Here and there Scrum teams are springing up that capture attention by their high productivity and ingenuity and win the envy of their colleagues for their enthusiasm and Joie de vivre.  People who see a good Scrum team in action want to be part of it or learn how to make that happen in their business.  That is the real reason why the buzz of excitement continues and why Scrum experts are being invited into other areas of business.

How to implement Scrum while keeping your sanity and your Job

Cost overruns, missed schedules and quality issues. These were the reasons cited for the development of Scrum.
Management also wants to harvest the business value expected from new software sooner, while using fewer resources

Breaking a traditional process up into small increments solves all of these problems. MSFis a wonderful example of this apart from the fewer resources bit, that is a myth. MSF encourages the business to develop a long term vision for the solution, but then it is broken into a series of small deliverables that build up in timeboxes to a full solution, or stop when time or budget run out.

The benefits are significant because; a. A proper Enterprise Architecture, style and vision is agreed first. That means that we don’t start off with one approach then half way through have to scrap it all and start again in order to scale. B. It means that at the end of the first timebox there is something of business value to show to the customer.

MSF differs from scrum however, in that it still depends on some basic documentation and designs and formal testing in a way that is familiar to most software engineers. MSF also lends itself well to procuring systems which I can’t honestly say about Scrum.

The downside is that MSF does not greatly improve communication other than the fact that it keeps the timeboxes short and encourages a collaborative agile team of peers, but the documentation still poses a threat to communication.

Scrum is a very different kettle of fish.
Scrum is designed to address a number of other problems:

  1. The Product Owner is a response to the lack of communication in traditional projects caused by remote stakeholders and by the sheer challenge of communicating a business idea from an executive to a programmer or architect accurately. Putting the business person in the role of Product Owner broke through this barrier.
  2. Demotivated and remote “techies” interested only in playing with gadgets is also a perception that still exists and it is countered by empowering them, making them into generalists and putting them in daily communication with their customer in the business.
  3. Fear of not knowing what “they are doing in there” is still an irrational fear that plagues the relationship between technology and the business. Delivering demonstrable pieces of functionality at regular intervals lets the business see proof that they are working and usually sends them off to sleep within a few months.

Aspects of Scrum that pose serious threats to success of a project

  1. Scrum was designed for writing code for fairly small projects. It was never designed to be used for many of the other unbelievable uses it is put to. The reason for some of these ridiculous applications of Scrum may be that Project management skills have been deprecated in favour of” the new thing”. The chances are they were not great to begin with and hence the adaption of Scrum
  2. Scrum is NOT Project Management, it’s designed by software engineers for software development. In small projects, the Product Owner could carry in his head all the stuff normally entrusted to a project and the scrum master can run the development, but this does not translate to bigger projects.
  3. Scope creep. Yes, we thought we had beat this one but in fact the reality is often that Scrum introduces a crippling level of scope creep. Three reasons mainly are to blame:
    1. No formal change control, nobody to say ” you are kidding?” so everything goes on the backlog
    2. No formal end date, so as long as it is all cosy, the business customer will keep on going, why should he stop?
    3. Bugs and millions more of them. Scrum teams don’t do formal testing and if you ever developed software you know what this means . Scrum teams also decide which bugs to fix and which to ignore. Naturally this becomes a tool when meeting the end of sprint deadline, it may be that the system works, but only just. That is acceptable by the way.
  4. A Scrum of Scrums is like replacing a big house with a tower block. It isn’t smaller or more manageable, it’s a mess. We spent the last twenty years turning old fashioned command and control organisations into flat collaborative ones. Now the scalable Scrum has built them back up again with a cell of cells like a medieval army. I’m not saying its impossible, just that it needs improvement and it’s not always worth the effort.
  5. Estimating is very difficult and Sprints are far worse at predicting their time and scope than traditional projects ever were. Costs are sometimes spiralling rather than falling, they just are not visibly so.
  6. Frequently the techies dominate the Product owner to get their own way and the collaboration is little more than a nice theory, the difference is he won’t tell anyone.
  7. Scrum was designed to be done by very experienced engineers all of whom were trained in Scrum. In reality few team members are even certified and the engineering skills are generally not good enough for a self-contained empowered team
  8. If any of the team members leave it can have a serious effect on the outcome.
  9. Scrumbut is a major problem. It refers to the practice of leaving out key parts of the process because you don’t like them, or whatever excuse. The problem is that velocity charts, retrospect and all the other rituals are there for a very good reason and when left out you end up with a traditional bunch of techies running amok with no controls, planning, or performance improvement strategy.
  10. The hatred of documents and authority figures really hurts when it comes to architecture.
    The team gradually becomes braver and makes more unqualified assumptions about the underlying infrastructure they are building on until eventually disaster happens and when it does there is no documentation, the designer has left and there is chaos.

 

So what should do you need to do if you are considering a Scrum implementation in your organisation?

  1. Begin by spending as much time as necessary to be very clear about what problem you hope to resolve with Scrum, or what benefit you want to reap.
    Don’t implement Scrum to deliver major projects, it was never designed for this. If you want to add some of the elements of incremental delivery etc, go ahead and introduce them to your traditional approach, or explore another method such as MSF.
  2. Define your criteria for deciding whether a project should be approached in a traditional way or via Scrum. Get advice if needed and especially in the first year, be very careful to tackle only projects that lend themselves to Scrum. As a guideline I would say:
    1. They should have a small element of invisible work, i.e. if there’s two months work to implement stuff you can’t demonstrate, don’t tackle this one with Scrum at least not till you are very experienced.
    2. The solution must be something that lends itself to incremental delivery and can be meaningfully demonstrated.
    3. The whole team including Product Owner can be located in the same building and I would try to get the Product Owner relocated to sit with the team.
  3. Define a clear framework for Enterprise Architecture and let the Scrum team clearly understand what they can touch and what they can not and don’t budge on change control mechanisms when it comes to mission critical systems and those that impact them.
    In TOGAF terms a good approach might be to say that only the Organisation specific technology can be touched and within that I might label parts of it uniquely for agile access.
  4. Don’t start with a team who have let you down at traditional approaches and read an ebook on Scrum. Send them away for a few days to be trained and hire an experienced person to coach the team through at least their first project.
  5. Put in place a QA process to monitor Scrum and their performance. Make sure that all the rituals are being done and in a meaningful way. Make sure the velocity is being monitored, monitor the accuracy of estimations, watch out for debt in the bugs department.
  6. Most of all, when you have a good plan in place and you are satisfied that you have the answers to hand, present your plan to your colleagues in the business in the context of how it will be impacting them, how they will benefit and how they will be expected to change the way they engage. Make necessary changes and then plan for the launch.
  7. This is really important. Take a cold look at your existing project management processes and ask yourself what is it that made you so keen to try an alternative approach. If some of these issues are not going to be solved by Scrum and I predict that will be the case, then set about resolving them in another way.
  8. Make sure you have a clear interface defined for how Scrum teams will interact with traditional projects and Programmes when asked to do so. There must be no them and us, but on the contrary, the two disciplines must support each other. You will need your programme and project management capabilities for many things and it will be beneficial to be able to interface a Scrum project with part of a project or a programme without ruffling feathers. This will also save you from the ignominy of trying to deliver huge projects via Scrum

 

Product Ownership the great let down

The Achilles heel of Agile is without question the Product Owner role, or lack thereof.

In this two part blog I will discuss the role of the Product owner in internal teams and the very different role of the Product Owner developing for a competitive market place and I believe I will shed considerable light on the issues plaguing so many IT functions today who are less than enamoured with the benefits of their agile implementations.

First of all let me say yet again that Agile was never intended to be the band aid of all band aids. It was created to solve a specific problem which it did/does effectively and it has since been overhyped and misused to the point where in a high proportion of implementations all that is left to recognise it is a few rituals and a lack of any structure. I’m not talking about these latter implementation, but genuine agile teams building products for the mass market and internal teams building small systems for internal stakeholders, but failing to do any better than those who went before them.

In theory, a good agile product team can be highly effective if asked to develop a small system for an internal client and prepared to adjust to the different environment before releasing the handbrake. The job is considerably less complex, communication and feedback more readily available and little to get in the way. In reality, though, it is rare that anyone with such a prized asset as a high performing agile product team would let them spend very much time on internal systems.

The difference between a Product manager/Product Owner and BA/Product Owner is significant and accounts for the bulk of the problem I set out to discuss today.

BA/Product Owner

Within an organisation the problem to be solved is a complex one, but one IT departments have greater experience with. A cross-section of the organisation need to work collaboratively to achieve a business goal such as entering the correct data and preparing end of month management accounts. They need a system to reduce the effort and help them achieve the goal more effectively. They are probably operational people, or maybe marketers or accountants. They have no experience with systems. Additionally they are most likely not a team and there will be tensions and politics all heightened by the potential disruption of a new system. The will to agree and cooperate is weaker generally than the will to adapt a defensive stance.

Someone needs to ask the right questions in the right way, record it turn it into a design, bring people along sometimes, dictate at other times and know which reaction is right for which situation. The work to define a product is also and more importantly the design of a process and a new or slightly changed team which is far more significant than the binary stuff. Does anyone still remember the mantra: People, Process then Technology

This is the territory of a skilled Business Analyst and the role should normally represent the customers and oversee UAT to ensure continuity into live and provide a measure of support and adjudication to get it into smooth operation. Sadly few BAs are qualified to do this and come from a wide variety of backgrounds, the majority technical in some way, but amongst the ranks are some very good ones who have self taught. A skilled and experienced technology project manager is able to hire and to guide and oversee where necessary. That’s a whole different blog though.

A good BA, working with the support of an enlightened organisation will be preparing a business case and tracing benefits back to features as far as possible. He will trim the scope with stakeholders to fit time and or budget and give the incoming Project manager a well groomed document of requirements and a charter with a clear definition of what to deliver, the estimated costs and expected benefits. In the course of the project all of this will be further refined before design and development of the technology begins. By that point there is a very good knowledge of the scope, the costs, risks and stretches available and generally only a small allowance for deviation is needed. Skilful project managers can deliver these projects day in and day out with reliability and there is little room for significant failures.

A skilful Product Owner will do a very similar role, the main difference being that he won’t stress himself trying to plan the maximum benefits and predict the end product and he won’t get involved in process design or change management, he will just define a minimum viable product, i.e. the smallest working subset that is delivering a useful function and then start adding features. He will keep a sprint ahead of the developer asking the stakeholders to decide what they’d like next.

Depending on the organisation, the final outcome may differ widely, but in a mature organisation, I would expect it to be very similar. I sometimes think of Agile in this context as IT’s revenge on bullying businesses. In many organisations It is like giving the addict a truck load of heroin instead of nursing him, but in many it keep both sides happy and there’s a lot to be said for that especially if the alternative is stalemate.

In the internal scenario, therefore, I would have to say that the Product Owner role is also a weak point, but not always with really significant costs.

 

Product Manager/Product Owner

The true Product Owner is a close cousin of the traditional Product Manager a role that is not itself that well understood by many.

The traditional Product Manager either was a dual role or specialised in one or the other of Product Planning and Product Marketing.

The Product Planner owned the product Roadmap. This meant expertise strategic marketing to understand markets, gain and maintain competitive insight within the market, build a competitive analysis and pricing analysis and position an offering that had a powerful chance of succeeding in its market . All this was represented in an MRD. Market Requirements Document. A high proportion of bright ideas never make it through this process because it becomes acutely obvious that it is flawed in some way and can’t possibly be a commercial success. The value therefore of this process is immeasurable.

The Product Planner would then expand this product proposition into a set of detailed features and produce a PRD which went to the development team to develop and test the product and the documentation, help files etc, while he worked with support, distribution, and other teams to prepare for launch and life after launch. A good Product Planner brings continuity to the process and produces rounded user experiences as well as defining feasible profitable business propositions.

The Product Marketer, builds on the strategic proposition to define market segments, messages, approaches and tactics to launch the product and drive ongoing sales and providing critical feedback to the product planner on how the market reacts and how its attitudes change so that the offering remains competitive.

Another common breakdown of the role was between a Technical Product manager who had a sort of CTO role in the product team, a Marketing Product Manager to handle launch and ongoing marketing and Strategic Product manager who was very similar to the Product Planner.

The skill of product management is very significant. Product Managers develop an insight and instinct for their market through immersion over time and they instinctively come up with ideas for potentially winning products based on this deep knowledge.
All product managers understand the importance of stage gates, even if sometimes a little too rigid by design, in the process of whittling down potential products to come up with winners worthy of investment and to cut out the low performers early. Great Product managers know when to persevere with a slow starter and let it grow, weak product owners keep on long after the product has died wasting effort and diluting the brand. It’s an art as much as a science and the most valuable knowledge is often tacit.

Enter the Scrum Product Owner

First of all let me say that there are many product managers who have adapted Scrum as a replacement for the PRD and this has proven a tremendous addition to their armour, but sadly there are far too many who have been given the role because the company is implementing Scrum and it demands a Product
Owner. I have met a great many of them who had no background at all in product management or product ownership and in fact the most common ting is the head of the business unit, not having the time for this close working with developers, delegates the role to a fairly junior person. Despite working with more than 25 different businesses in the past decade, I have yet to see a single product owner with anything approaching suitable skills for this very important role

“Certified Scrum Product Owners® have been taught the Scrum terminology, practices, and principles that enable them to fulfil the role of Product Owner on a Scrum team. CSPOs are typically the individuals who are closest to the “business side” of the project. They are charged by the organization to “get the product out” and are expected to do the best possible job of satisfying all the stakeholders. CSPOs maintain the product backlog and ensure that everyone knows the priorities.” Scrum Alliance.

 

The Product Owner is responsible for:

-Establishing the high-level vision in terms of creating value for stakeholders

  • Obtaining budget

  • Getting input on features to be provided and understanding their relative value to the business-stakeholders

-Providing the team with context as needed to help them with development of the sprint

-Agree with the team a reasonable commitment to outputs for a sprint

-Inspect sprint outputs and if necessary suggest improvements

-Evolve the product backlog from Sprint to Sprint

-Decide when to release software to market or to internal stakeholders

-Maintain clear release criteria, dates scope, burn down charts etc

-Take responsibility for return on investment

-Make clear decisions when asked and not constantly need to refer

What you may have noticed is that that there is an almost nonchalant dismissal of so much of what is vital to make products successful.
Scrum training spends typically half an hour talking about how to develop an elevator pitch and write a short vision to paste on the wall near the scrum team. As far as strategic product planning goes, that was about it in my case and most people report a similar experience.
Again don’t read into this a push back against Scrum, I have a lot of respect for intelligent usage of Scrum to develop spirally, what I am simply pointing out is that this most pivotal role in Scrum is not the want to cut corners on.

In fact, if you accept the common argument that agile came about as a solution to the problem of technical teams always being blamed for delivering late and by association with that for cost and profit issues etc, then you must surely realise that the one part of agile actually addressing this issue directly is the person who owns that relationship between the business unit and the technical team. i.e. the Product Owner.

Following that same thread of thought, It is not hard to arrive at the assumption that techies solved their problem once they handed the product owner responsibility over to the business and eliminated the big schedule gantt with a hard date and furthermore that perhaps they had got the measure of their business colleagues after all.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Intelligent use of Scrum to develop spirally

Bulls eye product management
Spiral product development with Scrum helps you hit bullseye and stay on target

I wrote previously about the Product Ownership in my blog Product Ownership the great let down in that blog I discussed the importance of stage gates as a safeguard when developing products for a crowded marketplace, especially new or very different products.

The MRD is typically the final output of a Product Manager exploring a new product idea and it sets out the product vision along with the estimated demand for such a product by way of unmet needs in the market. It will size that market and make estimates of break-even and the likelihood of achieving it and going on to establish a healthy product lifespan. At the end it will make a recommendation. The stage gate will consist of a review when product, technical, financial and other strategic stakeholders will consider this information in the context of their own knowledge and risk appetite and a joint decision will be made to proceed or not. This not very different to the way an internal project might begin other than the type of information being considered and the type of risk and opportunity profiles involved. I find it very hard to visualise a situation where this work should not be done.

The risk are simply too great. Changes happen daily in global markets, finance, economics, local markets, disruptive entrants and so many other potential parameters that without serious initial and ongoing assessment the likelihood of burning large amounts of capital regularly is just too great.

Most product organisations now and in the past would have a series of stage gates which allowed them to develop the proposition in increments and then reconsider it based on the new information. For many, the extra security offered by this method is outweighed by the level of formality and constraint.

For those very reasons, agile can provide excellent solutions to fast moving environments, changing information and uncertainty. Agile follows an incremental method of developing the proposition and the product in tandem. I often refer to it as the Onion Plan.

It begins with the product owner defining a Minimal Viable Product ( MVP) or Minimal Marketable Product ( MMP).

Marty Cagan gives my favourite definition of this in his blog when he says “I have long defined minimum viable product as the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.”

I have also often heard it defined as the minimum product that delivers on the product vision. This is also good but it misses the important point about being marketable. Otherwise people won’t get it and it can do just because of that. E.g. A three wheel car works fine, but its hard to get customers excited about it and their reactions say nothing about the four wheel version you are planning later in the year

This initial product forms the core of the onion, at least as you initially see it. That does not mean t forms the core of the product, because the whole point in getting it out there is to react to feed-back and make changes, so the core could be moving this way or that before and while building up the further layers of the onion. Needs versus features

 

 

When we define products we discover a need in the market, it represents a pain point for our customer for example. E.g. Customer tell us they need their cars to burn less fuel, so we respond by designing a car that that runs on half the amount of fuel. Then we discover that thy are not willing to live with the smaller size and they must have a minimum accelerations so we revise our product to save 10% of fuel without losing any comfort or acceleration. They like this, but now it is more expensive than a better one from Japan and they won’t pay our price so we go back to the drawing board. Eventually we reach the right compromise and release a simple model that has a broad appeal to our most important segment of the target audience. We are able to sell this to real customers paying with real money and get their feedback. That in my view is when the Onion core has been built and now the layers start to be added as we address the extra needs of our more sophisticated segments, watching at all times for a change to the core proposition through a new competitor offer or an unexpected macroeconomic change etc. Either the need or the potential solutions can change in our market environment at any time as can the macro environment such as their ability and willingness to pay and all can have can rapid and serious consequences for our offering.

 

The skill of the product Owner in this circumstance was to identify the potential core product, address the right segment, get good feedback and understand it then come back rapidly with a better offer and keep doing this till he hit bulls eye before building on extra layers of features or addressing other segments. Understanding a need is a particular skill, but meeting that need in a competitive way that can drive strong market performance is another entirely separate skill and both are inseparable from each other.

This does not sound at all like a bunch of techies huddling over a wall covered in scribbles, but it is in fact a very effective use of all the principals of Scrum as long as there is enlightened and capable Product Ownership.