What changed in the latest Scrum guide — a review of the changes and the global launch event.

Image for post
Image for post
Photo by Olga Guryanova on Unsplash

On November the 18th 2020 at approximately 10:00 AM Eastern Time (US and Canada) the 2020 version of the Scrum guide was published, replacing the previous 2016 version. I know this because 10:00AM EST works out to 4AM New Zealand time. So it was very early in the morning for me when I launched zoom to join the global launch event. …


From pyramids to nuclear missiles

Image for post
Image for post
By Nina — Own work, CC BY 2.5, https://commons.wikimedia.org/w/index.php?curid=282496

“A project is a temporary endeavor undertaken to create a unique product, service or result.”

Project Management Institute

The evidence that projects have been around for a long time is not hard to find. One of the most recognizable shapes on the planet, the Great Pyramid of Giza shown above was a massive project, and when one considers the basic technology in use at the time, over 4500 years ago, even more remarkable.

There is however a difference between achieving a feat, however difficult, and the body of knowledge that constitutes Project Management. Like much of our modern business knowledge today Project Management has its roots in scientific management — the application of scientific principles to the managing of work — and the works of Frederick Taylor (1856–1915). …


Understand how the “Discover > Design > Execute > Operate” pattern can help your team navigate uncertainty.

Image for post
Image for post
Photo by Fabio Jock on Unsplash

Pattern Summary

All projects and initiatives are different, however you will recognise four distinct phases in each. Consider the seasons: Summer, Autumn (or Fall), Spring and Winter. In some countries these are reasonably distinct, in others the transition from season to season is more blurred. Yet in all countries understanding the seasons and the weather they bring is helpful. So it is with initiatives and projects: these phases are not imposed on a project, rather they are a natural part of all projects, in fact if you look closely you will observe this pattern in all tasks, both big and small. …


Foundation Pattern: Use company bets to prioritize projects

Image for post
Image for post
Photo by Clifford Photography on Unsplash

Pattern Summary

A company bet in the context of this pattern is a potential project. The language comes from the world of gambling, where players will make bets, for example on the outcome of a sporting event, or a hand of poker. Implicit in the language of bets is the language of uncertainty and risk. For example when a bet is placed on a sporting event the bet is placed against set odds. The higher the risk the higher the potential pay-out — and of course the greater the chance you will lose your money.

This language is a good fit for the evaluation and selection of software projects. In a complex environment there is no certainty. The outcome of the project cannot be known in advance, nor can the customer reaction to the end product produced. Of course there are ways of reducing risk — for example by applying design thinking techniques before selecting a project. However the fundamental reality remains that no matter how many risk-mitigation strategies you apply the outcome of a project executed in a complex environment cannot be known in advance. All that decision makers can do is weigh up the odds. …


Foundation Pattern: Use projects and milestones to drive product development

The Pattern

The most effective way to develop a new product or make a significant improvement to an existing product is to plan and execute a project. This project needs to have:

  • An end objective. What is the project seeking to achieve?
  • Optionally, phases. A large project can be divided into a few defined phases. This is helpful to increase clarity and focus.
  • Milestones. Milestones are clear, agreed and significant points within a phase

To use a mountaineering analogy, in climbing a large mountain there are natural places to rest and regroup, known as camps. These are analogous to project phases.

Image for post
Image for post
Traditional Mt Everest ascent plan. In our analogy the routes between base camps equate to project phases. Image credit: conqueringdreams.org

Foundation Pattern: Have a product roadmap

Pattern Summary

A product roadmap gives clarity and focus to the team executing the roadmap. The roadmap is a high level plan for realizing the desired product objective. The roadmap is a living document, adapting to discoveries made during the course of development.

Example

Image for post
Image for post
Netflix 2020 roadmap (example) Gibson Biddle

References

One Product, One Team (Chris Lennon)

Product Vision and Strategy (Chris Lennon)


Foundation Pattern: Teams need a Product Manager

Pattern Summary

Software teams need a strong Product Manager with a passion for the product and the skills and connections to help the team bring the product to market. The Product Manager acts as CEO of the product and is accountable for the product mission, vision and strategy.

Alternative Patterns / Anti-patterns

Product Manager and Product Owner (anti-pattern)

This pattern describes a role, as in a hat that is worn. In some companies the role of Product Manager is known as ‘Product Owner’. The point is that this role should be filled by a single person. Having both a Product Manager and a Product Owner for a single team is an anti-pattern as it dilutes the product vision and introduces communication challenges. For more on this see Marty Cagan’s blogs on this: Product Manager vs. Product Owner and Product Manager vs. Product Owner Revisited. …


Foundation Pattern: Products of all shapes and sizes need a product mission, vision and strategy

Pattern Summary

An articulated vision is essential for products of all shapes and sizes, as is an agreed and clear strategy.

  • A product mission is the product North Star, this describes what makes the product special. It speaks to the ‘why’ of the product
  • A product vision carries the product mission and begins to translate it into a series of steps
  • A product strategy outlines, at a high level the approach that will take a team towards the product vision. It speaks to the ‘how’ of the product

These are living artifacts; the product vision may stay reasonably constant throughout the lifetime of the product but the strategy may need to change in response to discoveries made along the way, and to adapt to changing circumstances. …


Foundation Pattern: One product equals one team

From the author

This is the first in what may become quite a few pattern blogs. These are short summaries of a useful patterns in modern software product development. The idea is that they start off a bit ‘rough around the edges’ but are refined over time as I discover more and respond to feedback. The patterns will build on and compliment each other

Some of these patterns I have quite a lot of confidence in, others are still emerging in my thinking.

Pattern Summary

The most effective way of developing software is to define logical products and assign a dedicated self-managing team who own the product, from discovery to design and build through to, and including, operation. …


Silver bullet or consultants cash cow?

Image for post
Image for post
Image Credit: Blueprint Management Consultants

The origins of the word blueprint which today we use to signify the master design of a structure or process date back to the 1850's, when engineers would draw their designs on photosensitive paper which was then exposed to light. The light triggered a chemical process and resulted in a print that had a blue background with crisp white lines. Literally a blue print.

Today’s building designs are electronic, but the core concept remains — design the structure then build the structure according to those plans.

The arrival of computer software in the 1960's and ‘70’s presented a new challenge. Computer software is not physical. It cannot be touched, held, and observed way physical objects can. What then is the best way to build software? As computer projects grew larger and more visible this became an important question. The answer, it seemed, was obvious. We should build software the way we build large structures. Design the entire, completed structure then hand the plans — in the form of detailed specifications — to the boffins and have these technical folks build the software to the plans. …

About

Chris Lennon

Agile coach. Ways of Working researcher. I live in beautiful New Zealand and work for Fraedom — part of Visa. I am also the founder of a start up — voyzu.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store