After you've come up with several solutions to deal with an impediment, the next step is to decide which actions you will do with your team to solve it. Let's dive into who decides to take action and explore different approaches for how agile teams can decide.
This is the first blog post of a series on handling impediments in agile teams. It explores why being able to deal with impediments matters for agile teams and provides a basic "process" for effectively dealing with them.
One of the principles from agile and lean software development is transparency. Making things visible helps teams to decide what to do and to collaborate effectively with their stakeholders. It can also help to increase the quality of software. This post provides ideas how you can do that.
Agile verandertrajecten worden veelal top down uitgevoerd in organisaties. Zulke trajecten kosten veel tijd en energie van het management en de medewerkers, duren lang, en leveren vaak niet de verwachte voordelen op: de organisatie wordt er niet echt agile van. Een bottom up aanpak, gedreven vanuit de medewerkers, kan ervoor zorgen dat een organisatie sneller en blijvend hun agility verhoogt.
More and more organizations are implementing agile with Scrum. They define teams and assign Scrum masters to the teams to start working agile and become self-organized. Although agile looks easy, to implement the Scrum master role often turns out to be problematic. Let's discuss what makes it so difficult to work with full-time Scrum masters and explore the alternative of having technical people taking the Scrum master role.
Here's a story of a team that had a serious problem which it didn't recognize at first. The story shows that sometimes doing nothing can be the best thing that you can do to implement lasting change in organizations.
In the mini-workshop Experience new exercises to spice up your agile retrospective #RetroValue that I gave at Lean Kanban France teams experienced three different retrospectives exercises. They learned how retrospectives can help them to gain deeper insight in their situation and came up with actions to deal with problems and improve their performance.
The aim of an agile retrospective is to define actions for the next iteration that will improve the way of working and help teams to deliver more value to their customers. This retrospective exercise can be used within agile frameworks like Scrum, SAFe, XP or Kanban to have teams agree upon the vital few improvement actions that they will do.
To deliver high-quality products to customers, agile quality practices have to engrained throughout development. It all starts with ensuring the quality of the requirements.
There are organizations which think that Agile or Scrum can be the solution to solve all IT problems that they have. Senior management has decided that their whole organization has to become agile. To realize that they demand that all existing (waterfall) processes will be replaced by Agile processes. Even if they succeed to do that (which is often not the case) they are usually not getting the expected business benefits out of Agile. Replacing processes doesn't make an organization Agile.
Do your teams want to know how agile they are? And what could be the possible next steps for them to become more agile and lean? In an open space session about Agile Self-Assessments organized by nlScrum we discussed why self-assessments matter and how teams can self-assess their agility to become better in what they do.
We moeten onze kennis beter gaan delen, vaker leren van elkaar hoe je dingen kunt doen, hoe het beter kan. Kennis delen en toepassen, wielen (her)gebruiken om ermee te gaan rijden. Ben je benieuwd hoe je dat kunt doen?