Student memeI am really sorry to have to say it but words do matter, they change the context of conversations and impact on culture. Imagine overhearing your manager speaking loudly on the phone “Yeah John, I can allocate some resource for the weekend to fix your problems” – are you happy being that resource?

We should all respect the highly skilled unique people that we have working for us and not treat them as interchangeable assets that we can move around like chess pieces. People are not fungible, even those with the same skill set have different personalities, fears and aspirations. Everyone works, communicates and collaborates differently; you cannot simply replace someone and expect identical results.

Many companies avoid the dehumanising language of resourcesbodies, heads or even units. Starbucks has partners, Toyota has team members and IU Health has colleagues. There is even an annual #WorldNoResourcesDay on May 1st to highlight the issue.

Start treating people like people by using more thoughtful alternatives such as “I will ask Tripti and Chris if they can pick this up” instead of “I will put some resource on it”.

So please repeat after me – people are not resources, people are not resources, people are not resources…

I want to leave you with a mental image for the next time you say resource:

BillGates Resource

Thanks, ScrumRonin

What is a Product?Product Magnifying Glasst2


Many companies are moving towards a product model with product managers, product visions, product strategies, product roadmaps, product backlogs, product increments and even minimum viable products but do we all agree on what a product actually is?

Without a clear understanding and agreement on terminology we can get impede alignment and stall change initiatives. Within this post I have attempted to clarify what a product is and how it differs from traditional projects.

Product Definition
Definition: A product is a tangible item produced to create specific value for a group of customers and to the organisation that provides it.

Product Model

A product solves a problem (think DropBox which provides an easy way to store and share files) or provides a benefit (such as discovering new places and locating your friends in FourSquare) to the customer.

Additionally, the product creates value for the organisation by directly creating revenue (e.g. Microsoft Office), helping to develop other products (e.g. Visual Studio), providing marketing (e.g. Google AdWords) or selling another product (e.g. AppStore or iTunes).

And lastly:

  • a product needs a name people can remember and relate to
  • it has clear and communicable benefits for the customer
  • it is adaptable with time, trends and changes in market segments in order to keep it relevant and maintain its revenue stream.

The difficulty is finding a worthwhile problem to solve and creating an innovative and valuable solution to address it. Lean Startup helps in creating and validating the product model prior to the general product life cycle stages of development, introduction, growth, maturity, saturation, extension and decline.

Project versus ProductEverything in a trolley

Definition: A project is a temporary and one-time endeavour undertaken to create a unique product or service, which brings about beneficial change or added value.

Projects have definite beginning and end points, and thus have a limited duration. Products continue to be developed and supported until they reach their end of life and are discontinued.

Project success is determined if the scope is met within the time and cost commitments. Products are considered successful if they meet the customer needs and business goals. Product-market fit typically takes longer to achieve prior to the profitable growth stage.

An example product is OS X, the operating system for Macintosh computers which was launched in 2001. Since its launch there have been twelve major releases of OS X including most recently El Capitan in June 2015 which could be viewed as a project that focused upon performance, stability and security.

Products versus Features, Components, Services and Capabilities

People often confuse products with features, capabilities, components and services:

  • Product – a tangible item produced to create specific value for a group of customers and to the organisation that provides it. Example: AmazonFresh offering perishable and non-perishable groceries delivered directly to the customer’s home.
  • Feature/Capability – a product characteristic that customers can interact with to perform a specified task. A feature or capability does not solve a problem on its own, it requires additional features to address customer needs. Features/capabilities are typically listed on a product website or box in order to promote its usefulness. Example: a search feature on allows customers to locate books by title, author, ISBN, publisher, keywords, format, reader age, seller or publication date. You do not go to Amazon to search for books, you visit to buy a book.
  • Component – an architectural building block developed for a product. Individual components do not create measurable value for the organisation but instead are constituent parts of the product. Example: a compound interest calculator within a financial application or the checkout component within
  • Channel – the method used to interact with customers. A channel may be a website, promotional event, a product package or in-person consultancy.
  • Service – “any act or performance offered that is essentially intangible and does not result in the ownership of any thing”- Egellond. The wider ability to fulfil a customers need, either in its own right or as a significant element of a product. Services can be abstract and intangible and include physical evidence (“the environment in which the service is delivered, where the firm and customer interact, and any tangible components that facilitate performance or communication of the service”- Zeithaml), people (those involved in the customer experience and how the service is delivered) and process (how the service is carried out). Example: providing a pension via initial consultation, evaluation of options, review with customer, provision of agreed solution and providing ongoing support for the provided package.

Other Factors

Life is never black and white and there are many complications within the area of product engineering.

Features and components can be unbundled from an offering to create new products. For example, the checking-in and real-time location sharing aspects of FourSquare were separated into a new application named Swarm. This creates new opportunities and enables market segmentation.

Often multiple products are offered together in a Product bundle, for example the Amazon website includes many products such as Amazon Drive, Kindle Unlimited, Prime and LOVEFiLM.

An alternative view of a product is an item, service or idea consisting of a bundle of tangible and intangible attributes that satisfies consumers and is received in exchange for money or some other unit of value. In this view a product can include a service as described above, it is usually simpler to keep the definition of product as the tangible item and service as intangible.

ConclusionStrategize Book

Products are developed and supported long-term within an organisation to address a customer need and provide benefit to the business.

Restructuring companies to follow a product model can remove inefficient short-term optimisations and avoid the issues associated with people task switching. This enables value to be maximised by addressing customer’s needs and solving market problems.

For further information, see the excellent book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age by Roman Pichler.


150 Books Read MedalIt is important to celebrate life’s milestones however small they may be…

I have just finished reading and reviewing my 150th Agile book!

I have a fair bit of time available whilst travelling and like to learn from others working in the same field as me. My broad definition of Agile also encompasses Lean, Lean Startup, innovation, change management, Management 3.0, organisational transformation and other related topics.

I have added reviews and ratings for all 150 books on the Book Reviews page. These are purely my personal view at the point of time that I wrote them but I hope they will help to guide others on which books are useful.

I would love to hear from you on which books you value so I can add them to my reading list.

Agile Transformation RoadsignOverview

Let me start by stating that Agile transformation is hard. There are many different schools of thought on creating organisational change and in this post I wanted to take you through some of the options from a conceptual level.

In this era of unprecedented change, organisations need to rapidly change and adapt to market conditions and customer’s needs. Working in a traditional company model is palliative care with organisations that cannot change replaced by those that are smaller and more flexible. We should constantly be learning more about our customers and market, and develop our skills and capability to meet their needs.

I could start by discussing vision, big hairy audacious goals, change management, adoption curves, servant leadership, ADKAR model, Satir change process, Kotter’s eight-steps, Bridges’ transition model, Switch framework, cultural change, Agile mindsets, product management, feature teams, tool-led initiatives and process-led change but let us instead look at different Agile transformation models in order of difficulty.


Osmosis ModelOver time there is a gradual and unconscious assimilation of ideas and knowledge from the wider industry. Companies that learn and change continue to operate, others do not.

Advantages: No effort is required and change, if it happens, is natural and led by interested individuals. If people are unable to initiate change then they will leave – “you have to change your company – or change your company” (Martin Fowler).

Disadvantages: High risk model, business as usual and risk aversion generally win over disruptive change. Also it takes too much time and there is no consistent approach or understanding.

Pilot & Grow

Pilot and Grow ModelInitially form an Agile team and demonstrate success. Publicise this success (formally or via word of mouth) to develop more Agile teams (duplicate, split or seed). Trust on their continued success to grow an Agile culture progressively throughout the company.

Advantages: Organic growth based on team success is easier to embed. Success breeds success.

Disadvantages: This approach takes time to prove success and spread Agile. Any setbacks reflect badly upon the entire transformation and potentially impede it. Additionally non-Agile teams and partners will create difficult impediments to progress.


Portfolio ModelConvert one portfolio at a time whilst collaborating closely with stakeholders and all those involved. Portfolio change is typically performed after the pilot stage has already proven the domain specific model. Provide portfolio-wide transformation effort for a fixed period in order to make the change happen and protect the portfolio during the transition.

Advantages: Very clear vision for each incremental transformation effort, divide and conquer across the company and internal competition between portfolios can be a positive effect.

Disadvantages: Messaging must be very clear to give an overall roadmap with checkpoints and to avoid any ‘them-and –us’ attitudes emerging.

Maturity Model

Maturity ModelA more refined and aspirational approach where proven practice is clearly defined and a maturity model is in place for teams to self-certify themselves against. Training, coaching and mentoring are all available on a pull basis and communities of practice reinforce and anchor change.

Advantages: A detailed and progressive path to improvement is given and support is available to make it happen. The pull nature ensures change is self-organised and the certification used provides good metrics upon the change.

Disadvantages: Messaging must be very clear to communicate the overall roadmap and progress made.

Done/Not Done

Done Not Done ModelThis model is similar to the Portfolio model but differs by moving projects/teams across individually and having a hard-line viewpoint of the converted (done – Agile) and the unconverted (not done – traditional).

Advantages: Easier from a transformational point with training and coaching applied to each small area prior to moving on. Work is made progressively across the company until everyone is Done.

Disadvantages: Divisive model to push change through an organisation, mindset and process regression is likely and will disrupt the transformation.

Horizontal Slice

Horizontal Slice ModelA common incremental approach to Agile transformation where each department is transitioned in turn. For example, the software department changes, followed by the test department, systems department, project management, portfolio management etc.

Advantages: Easier to implement with only one focused department effort at a time. Leveraging of departmental success to drive change through the next department. The simpler technology change is performed first followed by later business inclusion.

Disadvantages: Fails to realise benefits of Agile for a considerable time with local sub-optimisation. Also a lack of business involvement and a lack of drive for end-to-end customer value can hamper overall effectiveness.

Vertical Slice

Maturity ModelMany view Agile transformation as running too slowly within organisations due to many existing impediments including the frozen middle, power structures, FUD (fear, uncertainty and doubt), risk aversion, business as usual etc. In this model a new organisation is created with an entire slice of the business from the top stakeholders downwards including all departments required. This Agile organisation works independently; the legacy part of the organisation is then gradually transferred across. Any parts of the organisation (products, process and people) that are not capable of working in an Agile way remain in the original organisation as it is run down and closed. Companies often use a new building or site to do this process cleanly.

Advantages: A clear line in the sand is drawn with a distinction between what is acceptable and what is not. The culture and mindset of the new organisation starts “right”. The usual impediments to organisational change are all removed in one big step with a new modern company created. This is hard-core transformation with the view – “if you can’t change your people, change your people(Dan Ariens).

Disadvantages: Massively disruptive with a clear impact on the entire company (but fun to do!).

Big Bang

Big Bang ModelTreat the organisation as a single entity, provide all required training and then provide a date for making a single clean break to a new way of working. Provide coaching and mentoring to reinforce the process and provide feedback opportunities via ‘inspect and adapt’ cycles to ensure that the change is embedded. Also use communities of interest/practice to normalise spikes.

Advantages: This is a simple model with clear goals and acceptance criteria. Consultancies often favour this model as they can bring in a large number of trainers and coaches (£££) to make a rapid transformation in process and practices.

Disadvantages: It is difficult to anchor change in a short period, business is disrupted and people can push back against the rate of change causing it to relapse. Creating a positive value increment using this method also takes time as the disruptive new process needs to bed in across the entire company simultaneously.


“All models are wrong but some are useful” (George box). The models represented above are all high-level simplifications of the difficulties and intricacies of dealing with real organisational change. Hopefully they provide insight into the variety of methods and options available.

Traditionally guerrilla Agile was implemented by teams to produce success prior to informing management of the method used. This changed to gaining initial stakeholder buy-in to use Agile, with financial and transparency advantages. ‘Middle-out’ adoption followed this to prevent fear of change from middle management causing regression or cancellation of change programs. This provided good results by combining stakeholder buy-in with team-led transformation. Lately there has been a move to tool or practice led transformation, for example implementing DevOps in its entirety and relying on it to bring in all of the required change. Additionally scaled approaches and push-backs to the ‘heart of Agile’ are still competing for space.

Piloting Agile teams is still useful to determine tailoring and show domain-specific success prior to wider transformation efforts. Following this, portfolio level change enables large groups to be transformed removing the frequent dependency impediments experienced by the pilot teams.

Pilot and Portfolio ModelVertically slicing the organisation by creating new sites, buildings or divisions and running them in an Agile way is a brave and successful method if you can gain sufficient buy-in and short-term protection from your stakeholders.

Big bang change is always disruptive, high-risk and burns massive amounts of energy, money and change capital. Without the change in mindset and culture there is always the likelihood of people reverting to more traditional forms when under pressure.

The model that you use will depend upon your company culture, stakeholder buy-in, desire for change, time and budget available plus many other factors. Good luck and please let me know how you progress.