Agile Practices for Increasing Requirements Quality
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.
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.
Agile retrospectives zijn een geweldige manier om continu je werkwijze te verbeteren. Ze helpen verbeteracties te vinden die er toe doen en ze ook daadwerkelijk uit te voeren. Ze ondersteunen teams om continu te leren en te verbeteren. In een retrospective gebruik je oefeningen waarmee teams inzicht krijgen in wat er speelt en verbeteracties te definiëren. Deze blog beschrijft 2 oefeningen: De zeilboot en de 1-woord Retrospective.
Change is often hard. But it is also important and much needed. That is why agile software development suggest to frequently inspect and adapt and promotes the usage of retrospectives to continuously improve the things that teams do. Retrospectives help teams to make changes that stick in the organization, leading to sustainable improvement.
Organizations want to have insight in the values that Agile can bring to them. They want to know if and how Agile can help to satisfy customer needs more quickly, and what they can do to increase productivity and reduce development and operations costs. It is important to know the value that Agile can deliver and to be able to measure it. At the event Impact and Value of Agile, organized by the Agile Consortium, I presented the State of Affairs in Agile Value creation.
In December 2013 we published Getting Value out of Agile Retrospectives: a pocket book full of Retrospective Exercises. More than 1000 readers have downloaded this book in the first five months after publication from Leanpub and many more have downloaded it from InfoQ: there are 5000++ readers worldwide of our book on Valuable Agile Retrospectives. A big thanks to all of our readers!
The key Scrum ceremony that helps the team reflect on its behaviour is the retrospective. In my view, this is not any new concept or jargon the team needs to master -- but yes, in reality it sometimes becomes challenging to keep the momentum lively at all times! Let us look at the reasons why this happens and discuss a few ideas for making these meetings effective.
As a retrospective facilitator it's important to have a toolbox of retrospective exercises which you can use to design a retrospective. Before having a retrospective meeting, you want to prepare yourself by considering which exercises would be most suitable. That depends on the team, the situation at hand, and on what the team would like to work on. Here are some tips for designing valuable agile retrospectives that help addressing specific situations.
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.
In an ideal world agile teams are working with one product owner or customer. But there are also teams which have more than one customer, maybe even multiple product owners. Due to that all the team members are often not working together on a daily base. Is it useful for such teams to do a retrospective together? How can they define actions that will be beneficial for the complete team?
Our book Getting Value out of Agile Retrospectives has reached 500 readers on Leanpub. There are also many more readers that have downloaded our book from InfoQ. Readers have rated our book 4.6 out of 5 on Goodreads. A big THANKS to all of our readers from Leanpub and from InfoQ: having so many readers interested in doing Valuable Agile Retrospectives makes use very happy!
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.
Root Cause Analysis can be used in software development to build a shared understanding of a problem to determine the first or “root” causes. Knowing these causes helps to identify effective improvement actions to prevent similar problems in the future. You can also do Root Cause Analysis in agile to stop problems that have been bugging your team for too long.