In an agile context, we use metrics to set performance goals, measure current conditions, define small improvement experiments and measure the effectiveness of the experiments in order to inspect and adapt goals and determine the next steps.
Metrics need to be chosen with care because when poorly chosen, they create an illusion of control. The metric data might deliver green dashboards while in reality, our organization is not performing very well. This article aims to give you a couple of tips to become more aware of your metrics.
In summary, some tips:
…ancial or time sense under certain circumstances (one is enough) and then we may suspect that it is appropriate in following cases:
scrum works best to reduce risk when doing complex work. Complex work has more unknowns than knowns (requirements, technology and people-wise). Building a house is complicated, but not complex. Scrum will create process overkill when applied on complicated work.
I work in “the transformation business”. The Agile transformation business to be more precise. The value I aim to deliver is: Improve the internal organisation of companies so that they get better at making their dreams come true. My core activity is coaching focused on Agility, i.e. influencing people to move towards (a (higher) state of) Agile. I want to share my opinion on what makes an Agile transformation successful.
I need three things: a goal, mandate, and specific knowledge.
The goal is brought to me by the organisation’s leaders: They have a problem that needs to be fixed (and…
Do you think working from home will never be as good as working together at the office? You probably draw such a conclusion based on your experiences during the pandemic. But hey, this is a new dimension to teamwork. So what if we’re simply not good enough at it yet? What if we underestimated what it takes to bring our teamwork online?
Instead of concluding that working at the office is better than working from home, I want to discover what can be improved to our current virtual collaboration approach.
In pre-pandemic times many people (mostly managers) had doubts about…
I think the Sprint Retrospective is the most challenging event in Scrum. This event is for the whole Scrum team to inspect and adapt everything but the product itself.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. (SG)
The 2020 Scrum Guide acknowledges that applying Retrospective improvements is not always successful:
The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. (SG)
Many articles have been written about Retrospectives: How to make them efficient…
On November 18, 2020 a new version of the Scrum Guide has been released. This article aims to inform people in less than 2 minutes what has changed.
The 2020 Scrum Guide revision:
Does not change Scrum. You do not need to change the way you work.
I was hired by a bank to help them to get started with agile and Scrum. The Business Loans department had assembled business employees to become three teams. I was asked to be their Scrum Master. Most people who see the value of the Scrum Master role will agree that a seasoned Scrum Master can support up to three experienced teams when sprinting. But is one Scrum Master enough to start up three teams from scratch simultaneously? Yes! In this article you will read how I achieved this.
We organized a four hour kick-off session to introduce the change. This…
The Sprint duration should be no longer than one month. The reason for working in Sprints of short duration is to deliver a “done” product in the hands of the customer at regular intervals to create opportunities for receiving feedback. This feedback can be used to alter the course of development to ensure we maximize value delivery.
If the Sprint duration is too short, the amount of overhead will have a negative effect on productivity. Also, there might be simply too little time to deliver something of value.