|Door:||Barry Overeem, 29-09-2015|
This blog post is about a little box. A little transparent box. The box contained only one sticky note. A sticky note with a milestone. The milestone belonged to a a large project that concerned a comprehensive organizational change with multiple Scrum teams.
This milestone was special, because it was a milestone the team failed to achieve.
Today we had the first review with all the different teams that are involved with the organizational change. The review had the structure of a "marketplace". No PowerPoint slides. Every team prepared a flip-over & market stall with the most important deliverables, ups & downs off the previous period and deliverables for the upcoming sprints. With short demo's of 12 minutes every team presented & discussed their progress with the other teams and stakeholders.
On itself the review was already great, this little box of one of the teams however made it awesome!
|Door:||Barry Overeem, 28-09-2015|
Although the Daily Scrum seems to be a simple and straightforward event, I still encounter a lot of teams struggling with it. In this blog post I'll share my tips & tactics. You can use it as a checklist for you own Daily Scrum, and hopefully it helps you ensure the event to become (or stay) effective, fun and inspiring.
Purpose and Outcome
The purpose of the Daily Scrum is to inspect and synchronize the team's progress towards the Sprint Goal, discuss if anything impedes the team and re-plan the team's work to achieve the Sprint Goal.
The outcome of the Daily Scrum should be:
- An updated Sprint Backlog
- An updated Sprint plan to achieve the Sprint Goal.
Afterwards every team member should have a clear plan for the day ahead. Possible impediments that limit them from achieving the Sprint Goal should have been identified. After the Daily Scrum the team can spent some time to discuss the impediments in more detail and find a solution.
The members of the Development Team are the primary participants of the Daily Scrum. The Scrum Master (as a facilitator) and the Product Owner (providing clarity about Product Backlog Items) can join, but their attendance isn't mandatory.
|Door:||Barry Overeem, 23-09-2015|
|Onderwerp:||Scrum Values Leadership|
Update 23-9: my colleague Wiger Middelkamp gave me some feedback, this resulted in adding the third lesson learned.
Previous week I used the Spotify Squad Health Check model to assess a teams situation and condition. One of the cards the game contained caused quite a lot of discussing during the retrospective and also gave me some thoughts afterwards, namely:
Pawns or Players
Is Your Team a Set of Players?
We are in control of our own destiny! We decide what to build and how to build it.
Or is Your Team a Set of Pawns?
We are just pawns in a game of chess with no influence over what we build or how we build it.
Most of the teams I work with want to be a 'player', but how do you become such a team? In this blog post I've shared the three most important lessons I've learned. The team I have in mind is a Scrum team. This includes the Scrum Master, Product Owner and the Development Team.
|Door:||Barry Overeem, 21-09-2015|
This morning I read the interesting article 'The Agile Manager's Practice: Seeding and Cultivating Agile Champions' by Michael Hamman. It describes how growing and cultivating Agile Champions is a key practice of designing the desired environments. Michael emphasizes that it's about cultivating conditions in which agile practices can flourish.
My intention was to share some of the highlights of this article, but as a result I almost copied it as a whole... However, please check the original article for the entire context.
|Door:||Barry Overeem, 16-09-2015|
|Onderwerp:||Scrum User Stories|
The concept of user stories is a well-known tool for describing requirements. In a simple format it captures the ‘who’, ‘what’ and ‘why’ of a requirement. User stories have their roots in Extreme Programming (XP) and is an often used tactic within Scrum. In 2001, Ron Jeffries proposed the Three C’s formula as a guide to capture the essence of user stories: Card, Conversation, and Confirmation.
- A card is a physical token giving tangible and durable form to what would otherwise only be an abstraction;
- A conversation is taking place at different time and places during a project between the various stakeholders concerned by the given feature (customers, users, developers, testers, etc.), which is largely verbal but most often supplemented by documentation;
- The confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally.
The concept of user stories can be very powerful when the Three C’s formula is respected. Especially within a complex environment it’s crucial to understand the idea behind user stories and use it properly. The problem however is, that quite often this isn’t the case.
|Door:||Henk Jan Huizer, 09-09-2015|
|Onderwerp:||retrospective agile scrum|
Voorbereiding is alles
Als je helemaal aan einde van de dag de koelkast induikt om zo snel mogelijk iets op tafel te zetten, is de kans niet groot dat je diner wat bijzonders gaat worden. Dit geld ook voor de Retrospective, als je als scrum master 5 minuten vooraf begint aan de voorbereiding ben je te laat. Wat je vooraf zoal moet doen als voorbereiding? Dat vind je in de volgende tips!
|Door:||Marco Kroonwijk, 08-09-2015|
|Onderwerp:||Definition of Done Automation Continous Delivery development Extreme Programming Technical Debt Testing unit testing|
So … your organization has just decided to embark on a test automation journey. You are going to automate all your manual regression testing efforts with this magnificent automation tool that drives your application. It tests just like any manual tester would do, but without the lag of the actual human normally associated with the task. The tool vendor demoed a way to record the test activities and replay them automagically to the management team, and they are all excited about the ease of use (and potential cost reduction).
A few months later, reality has kicked-in. Your test automation project has come to a grinding halt. What happened?