Evolving culture and ways of working through DevOps, Lean, and Agile.
This is a question that got asked on a live stream panel I was part of recently. My initial reaction was blunt. Of course we do, and here’s all the evidence you have. But then I started thinking about it a little more deeply. I’ve come to the conclusion that no, you don’t need a daily stand-up. But it’s a rare situation where this is actually true.
Continue reading “Why bother with a daily stand-up?”
A definition of done is one of the cheapest and most effective ways in which you can start tackling IT issues. It can improve quality, transparency, accountability, alignment, and even predictability. All at the cost of a conversation and some documentation.
There’s plenty of material on what a definition of done looks like and why you might want one, but not much on how to go about constructing your own. This is my attempt to fill that gap.
Continue reading “Writing a Definition of Done”Contrary to traditional management methods, an Agile approach considers the team to be a single cooperative unit. Individuals are not scored on the amount of work completed, but the team is monitored as a whole. This serves to improve team cohesiveness and ensure that anyone working on a project is dedicated to the success of a project through collaboration. You are all in this together.
The product owner is the individual responsible for establishing a common vision. This person is often the sponsor or customer of the project. The owner must be the lead in identifying features (Stories) and prioritising the workload such that the highest value is being delivered.
The following is an adaptation of content I wrote to help a new agile team. It was meant to be a brief skim over the surface of estimation, rather than an exhaustive document. It generally sticks to the classical agile approach, but has some additional techniques that I have found useful. The information on which this is based is largely attributable to Mike Cohn, of Mountain Goat Software, perhaps my favourite technical author of all time and, for me, certainly one of the most readable. I would love to hear peoples opinions on estimation, feel free to drop me a line with any tools and techniques that you use.
It is very difficult to provide an off the cuff estimate for something unknown. We may hazard a guess or try and compare it to something else of similar or relative size. If asked to estimate the size of a mountain, it would be much easier to estimate it as double the size of another mountain than to specify a weight in kilograms. There is also significant scientific evidence to support the hypothesis than humans are much better at estimating relatively than absolutely.
Story points are way of estimating effort to complete a feature that decouples that tie to specific units of measurement, such as time. By estimating effort in relation to other estimates, we can derive a value for time. Because we have estimated relatively, our final value for time is likely to be more accurate.
A story point is a unit independent measurement of effort required to complete something. Features are measured in a number of story points.
A useful video by Mike Cohn discussing User Stories can be found here: http://www.youtube.com/watch?v=6q5-cVeNjCE.