Essence

In this series of posts we wil explore the Events that either perform, schedule or track the activities that affect the Lifecycle of an Epic. This first post looks at the activites that the Portfolio needs to perform in order for it to make progress.

If you try find a definitive description of ‘The Spotify Model’ you will most likely end up frustrated. There are some old videos and blog posts, and lots of internet articles claiming that it isn’t a ‘proper’ framework and that even Spotify doesn’t use it. Yet, it is reported as the fourth most popular scaled agile framework according to the 15th State of Agile Report and there are thousands of companies claiming to be using it.  So, what is it? And if you want to adopt it, where do you start?

Epics have a lifecycle, they don’t magically appear fully formed. There is work to be done to progressively elaborate a business case and if the Epic is approved then there is further work to progress the Epic through implementation. This post explores the Lifecycle of an Epic and the states it progresses through in that Lifecycle.

This article explores the synergy of Scrum and Essence, a domain model of software engineering processes, intending to become a common ground for software development methods, bringing clarity into the composition of methods from individual practices.

What do we mean by Quality? The word Quality is commonly used in software development, but it isn’t always clear what is meant by it. Teams create Definitions of Done, configure thresholds in their CI/CD pipeline, write performance tests and agree service level agreements, but are these sufficient for the level of Quality the customer expects?

The purpose of governance is to provide confidence that expensive development projects are progressing at a satisfactory pace and will deliver the required outcomes at the required quality. They are often applied at a ‘whole organization’ level, with all teams required to report into them in the same way. They have often evolved from traditional, linear project management processes, often with checkpoints, gateways, milestones and compliance documents. Which is fine if we believe that the solutions being delivered are relatively stable and unlikely to change. However, what if that’s not the case? How do they cope if the problem space evolves, the criteria for success are unclear or the stakeholders change their minds?

Developing technical solutions is hard work. To make things easier, a number of agile practices and frameworks have become popular. They provide structure and guidance to help teams develop their solutions more successfully. However, doing these things well is also hard work. Despite in depth training, books, conferences and certificates, people still struggle to apply these practices well. Jeff Sutherland, co-founder of Scrum estimates that 58% of Scrum implementations fail. Playing simple Essence games can drastically improve your changes of avoiding being in that 58%

Read one of our student’s testimonial regarding our upcoming course, Better Scrum through Essence.

This article is intended to people who are interested in successful adoption of methods / ways of working – an area of maybe as much as 50% failures. Guidelines on how teams and organizations are suggested to work have been proposed since we started to develop software. Such guidelines have usually been called methods or lately “ways of working”. Over the years we have had a large number of published methods.

Hapag-Lloyd are using Essence to provide proven agile practice options for teams to adopt and adapt, enable coaches to facilitate practice adoption and improvement, provide for tailored approaches for different types of project, and achieve transparency of status and health for effective governance.