Agile

Yes, you can generalize Scrum to non-IT work, such as marketing- and content-generation. And it actually yields similar benefits; more work gets done, increased transparency, sharing of knowledge and increased motivation due to clear shared goals. In 2015 I had the opportunity to help two marketing- & content-teams at Kaarten Carrousel get started with Scrum. The teams have now broken through the 20th sprint-marker and moved into a larger, more spacious building, so this is a good opportunity to share how this came to be, what worked and what didn't. About Kaarten Carrousel If you live in the Netherlands, and…

Johannes & Christiaan, on the run from Scrum Zombies (by Maarten Brugman) We got out by the skin of our teeth, I tell you! Crawling through vents, hiding behind Scrum Boards and pelleting them with post-its and whiteboard markers. But we got out in time, and we’re here to warn you. Because they are here, and their number is growing rapidly. Mindless, drooling herds of developers, testers, designers and others moaning ‘chaaaange’ and shambling around the building to all sorts of brainless Scrum-activities. We (Johannes Schartau and Christiaan Verwijs) took it upon ourselves to write down what we have…

"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…