I met Hugo Messer a couple of years ago, when I connected with Bridge Global who started publishing guest posts from me. We talked about working with remote teams to find out that our thoughts on this are quite similar. In this guest post Hugo explores how Scrum can help distributed software development teams.
NO and YES are two simple words, yet practice shows that professionals often have difficulties in using them. Actually it's very easy, certainly when you want to work in an agile way. Dare to say NO when you are unsure if you can do what's requested. When you say YES it means that you will deliver the product, on time with the right quality.
Do you have a question about doing agile retrospectives? Need some help on how to do them? I'm there to answer your questions. All you have to do is ask :-)
Agile teams gebruiken retrospectives om hun manier van werken te reflecteren en te verbeteren. Veel Scrum teams sluiten iedere iteratie af met een retrospective. Teams die Kanban gebruiken doen veelal wekelijks een retrospective of doen zo vaak als nodig is een mini-retrospective om van een probleem te leren en in kleine stapjes te verbeteren. Hoe vaak doen jouw teams agile retrospectives?
Over the years I've had some situations where I couldn't get a team to come together in a retrospective to meet and reflect on the sprint. I've seen two different kinds of reasons for this. One was that a team wasn't convinced that agile was suitable for them, so they questioned doing agile retrospectives. The other situation was that the team believed in agile and Scrum and wanted to do a retrospective, but was looking for an alternative solution where they would not have to meet physically. Something that also a dispersed team would consider when travelling isn't an option. Let's explore how you can recognize these situations and deal with them.
SwanseaCon is a technical event for Software Developers, Software Architects, Project Managers, Analysts and Consultants in Wales.
I recently received a question whether Product Owners should participate in agile retrospectives. An interesting discussion took off about how "it should be by the book" and "common sense" which I have summarized in the below blog post.
A new chapter which explores how agile software development can be deployed to deliver high quality software has been added to my second book What Drives Quality.
Regularly I get questions if you can measure defects and if you should measure them. The short answer is: You can measure them, and it can have value to do so, but only if you take action. Quality matters, and defects can provide you with valuable information about the quality of your product, but measuring alone doesn't improve quality. You need to dive deeper to have a good understanding and then act upon that.
In April and May I'm giving several workshops on Agile in Eastern Europe. Tickets are on sale for these workshops, don't wait too long!
We've teamed up with the Agile Retrospective Kickstarter book to help you to do better retrospectives. Retrospectives that your teams love to do, that will help them to improve and deliver value to their customers and stakeholders.
Who should be handling and solving impediments? Should it be the Scrum master? The team as a whole! Their agile coach? I prefer that team members recognize and solve impediments themselves. For most of them they don't need a Scrum master or coach. So if they see a problem, I expect team members to take action and solve it.