We know that deadlines drive behavior. That’s why in scrum, and other agile methodologies, we timebox the development with those deadlines. They tell us: Focus on the important stuff, and make sure it’s done properly. Since they are good in essence, let’s see how we muck them up. Here’s the process. We prepare for the
When I ask teams “Do you do continuous integration”, eight out of ten times I get “We have Jenkins”, or a similar tool. The other two don’t know what I’m talking about. Jenkins to CI is like JUnit to unit testing (which is, of course, the answer I get when I ask about unit testing). It’s
Another iteration has passed, and so they gather, developers, testers, product owners and scrum masters to behold the showing of the increment. But lo, can they screw this up as well? You betcha. But before we do that, let’s recall why we have a demo in the first place. Remember the deal between the development team
If you’re already doing agile wrong, retrospectives are one of the first things you let go of. A shame really, but if you’re doing something wrong, you better screw up the thing that will bring you the most value. Why does dropping retrospective seem the least harmful? If you think planning is important (because it shows
“Everybody, please, stand up”, I remember encouraging everyone to rise to the occasion of another daily stand-up “meeting”. Even with a room full of people who knew the drill, I still felt I had to ask them. With every practice we do, we anchor around one or two basic assumptions, we believe will help us achieve the
Last time, we talked about the Definition of Done. We use is as vision of where we want to be at the end of the iteration. The question is: What happens if we’re not completely done? The truth is if we’re using the Definition of Done as a measurement, rather than a guiding light, we’ll
So, let me ask you a question: Are you done, done-done, or done-done-done? What does “done”mean anyway? To answer this question, let’s look at why defining “done” is important, especially in the iteration scope. As with many agile practices, it boils down to trust between the business people (and their representatives on earth, product managers) and
Now, I know that based on the title, you’re expecting some #NoEstimates stuff, but not today. You can find the #NoEstimates posts here. Last time, we started talking about iteration planning, and specifically, why we plan for the length of an iteration. Let’s continue with how we plan the content of the iteration and talk about story
Why do we do the things we do? When we can explain why we d: practice, decide to keep or change the way we do things, we should have better excuses than “that’s the way we’ve always done it” or “it is considered a best practice”. If these are the only answers we have, we’re in a