What is Taylorism, and why Waterfall is just the tip of the iceberg!
For many people the traditional project management methodologies (see PMI / PRINCE2) are the root of the problems that birthed Waterfall. I assert that this is the tip of the iceberg. These methodologies are just a symptom of a greater problem that has its roots in the changes made during the industrial revolution. These changes, while they generated great amounts of wealth and many jobs around the world, dehumanised work and destroyed the essence of value and discovery that brought humanity to where it is now. It created processes that turned people into little more than sophisticated robots and enshrined that thinking into the very core of how we do things.
Sprint Goal is an Immediate Tactical Goal
In the The Evidence-Based Management Guide we talk about the Intermediate Strategic Goal and I likened that to the Product Goal in the 2020 Scrum Guide . If we also think of each Sprint as a tactical move towards fulfilling that Product Goal then the Sprint Goal becomes an Intermediate Tactical Goal that moves us towards our current Intermediate Strategic Goal.
Story Points & Velocity are a sign of an unsuccessful team
Story Points and velocity have been used for many years in the Scrum community and have been engrained so much in the way that things are done that most folks believe that they are part of Scrum. The accepted wisdom is that Scrum Teams are supposed to use User Stories, Story Points, and Velocity to measure their work.
Evidence-based Management: Gathering the metrics
Gathering the metrics for Evidence-based Management in software organisations can be a strenuous task and I have a number of customers that are fretting on what to collect and from where. Here I try to create an understanding of the ‘what’ that we need to collect.
There is no place like production
Value is such a subjective thing that we will often be wrong, and there is no way around that wrongness. In order to minimise the wrongness and maximise the amount of value that we deliver we need to have a clear understanding of what our users need, how they are using the product, and validate our new value as soon as we can. Without validation we only have assumptions and assumptions can be dangerous.
Product Goal is an Intermediate Strategic Goal
The Evidence-Based Management Guide describes not only a Strategic Goal but also an Intermediate Strategic Goal that is needed to evaluate and adapt your progress towards your intended visions of your product.
If your backlog is not refined then you are doing it wrong
Most Scrum Teams that I encounter don’t do refinement of their Product Backlog and try to work on things that they don’t understand correctly. However, if you get to the Sprint Planning event and your backlog is not ready, then you are doing it wrong. If what you build is not of good quality then you should read about Defenition of Done .
Getting started with a Definition of Done (DoD)
In my last post about Professional software teams creating working software David Corbin made a good point. How do you determining what “Free from fault or defect” means? Since that is different for each Product and may change over time you need to focus on Quality and reflecting that quality in a Definition of Done (DoD).
A better way than staggered iterations for delivery
There is a better way than staggered iterations for delivery that will keep you on the path to agility. Staggered iterations lead to more technical debt and lower quality software.
You are doing it wrong if you are not using test first
Many teams are struggling with delivering modern software because they are not building with Test First Principals. Test First gives us the assurance that we have built the correct thing, that what we built is what the customer asked for and that when we change things we don’t break anything inadvertently.
