Agilistic

What I've learned while working with Scrum and Agile software development.

Scrums seems surprisingly easy. With only five 'Events', three 'Roles' and three 'Artifacts'. But teams frequently get confused by the terminology. Not to mention all the terminology that is related to Scrum, like 'User Stories', 'Epics', 'Technical Debt' and 'Pair Programming'. To help teams better understand the terminology and how everything ties together, Barry Overeem and I have created '40 Seconds of Scrum'. Inspired by the Dutch boardgame '30 Seconds' and based on the first version of Barry Heins. Its a simple cardgame that you can use to practice with Scrum in a fun and quick manner. How do you…

For my english readers; an English translation of this post ('How to start a Great Scrum Team?') will follow soon. I apologize for the inconvenience. This post was initialy published on the blog of Kreischer & Partners IT recruiment. "Hoe zorg je dat Scrum Teams een goede start maken?". Het is een vraag die ik vaak van klanten krijg, en waar ik als Agile Coach veel tijd aan besteed. Heel veel tijd. Want het is een misvatting om te verwachten dat het voldoende is om een paar mensen op Scrum Training te sturen, ze bij elkaar te zetten, en…

"Ok, so Agile is a great way to develop software", you say, "but how do I sell it to my customers?". Most pricing models that I've seen don't balance risks fairly between the customer and the supplier. Either the customer or the supplier carries all the risk, which doesn't sufficiently push both parties to take their responsibility. In this post I describe a simple pricing model that I've applied succesfully, and that - I think - balances out risks more fairly. The 'fixed-price, fixed-scope'-model The 'traditional' approach is to agree upon a set of requirements with your customer, estimate the…

This is a re-post of an older post. This version has been revised and extended with more strategies. The downloadable cheatsheet has been updated accordingly. Teams that have mastered Scrum know that the key to success lies in a just-in-time, increasingly refined, breakdown of work on the Product Backlog. They prefer Sprint Backlogs with many small (functional) items instead of just a few large ones. Smaller items improve flow, and reduce the risk of failing the sprint. In this article, I will explain why the break-down of work is important, and why it should be done across functional - instead…

One of the biggest challenges for a Scrum Team is to switch from a technical to a functional perspective on their work. The former focuses on the 'how' of development - which components must be changed, what code is touched - whereas the latter focuses on 'why' and 'who' - what do we want to achieve and for whom are we building this software. The locus of these questions lies in the Product Backlog. Assuming that the Product Owner and the stakeholders represent 'business' and/or 'customers' (which they should), the Backlog should be readable by all. Not only for…