Once I used timeboxes by default. Now I relegate Sprints and such like to exception situations.
Continue reading
Tag Archives: xp
Programmes can use more than one method: Kanban, Scrum, XP, BDD, etc
I have my preferences – Kanban and BDD – but don’t enforce these on my teams. That means I’ve got a couple of Scrum (ish) teams and teams that don’t use BDD. And I also have a bunch of people working in isolation – I just leave them to it.
Continue reading
Software Batch Sizes are Plummeting
When I said Continuous Delivery is Inevitable I cited shorter iterations as the main driver. However, along with shorter iterations we’re also getting smaller batch sizes. And from a Lean perspective it is the smaller batch sizes that are more interesting.
Continue reading
The Lean-Agile Fanatics are all Wrong
When Kanban folk talk to Scrum people the conversation can often get heated with recriminations and finger pointing. Personally I’ve got a pragmatic, or eclectic, style of Lean-Agile. None of the published methods are the silver bullet. But they all have something useful to offer.
Continue reading
Research on Pair Programming by Professionals
Research on Agile technical practices are few and far between. The research that exists often uses students as the test subjects so doesn’t necessarily reflect professional practice, particularly not by senior professionals. In 2006 I got my company of the time involved in some research on pair programming. What was different about this study was that the subjects were professional developers. The results were interesting as, in general, they didn’t bear out claims that pair programming improved quality or speeded up development. But pairing does take a lot more effort. This is why I am selective about encouraging pair programming, restricting my active encouragement to discovery mode.
Continue reading
Daily Plan: Stand up to Plan the Day
“Stand up please”. Old habits die hard and because I started Agile with Extreme Programming I “Stand up”, I don’t “Scrum”. Otherwise the two types of meeting are pretty similar. “What have you done since we last met? What will you do before we meet again? Any impediments?”
Great meeting. Wrong questions.
As Mike Cohn explained back in 2006, and Matt Wynne reminded me last year, the daily meeting is a Planning session. It is part of Mike’s planning onion because the aim of the “Stand up” is to develop the plan for the day.
Continue reading
Pair Programming is Best in Discovery Mode
Pair programming is one of the technical practices from Extreme Programming (XP). I have observed that pair programming works best when either member of the pair are in discovery mode. If there is little discovery going on, by either of the developers, there is little point in pairing.
Continue reading
Pain Driven Development
Agilists love a good catch phrase. You Aren’t Gonna Need it (YAGNI), Do the Simplest Thing that Could Possibly Work, and Pain Driven Development are three of them. In fact these three are different ways to say the same thing.
All three phrases are about addressing a technical problem the team might face in the future. Immature teams will immediately attempt to solve the potential problem and thus add complexity to their product. More mature teams take a slower, more considered view.
In fact Agile teams should go through these stages when considering a potential problem/solution:
- Remember “YAGNI” i.e. point out the team don’t have a problem now, hence don’t need that solution now, so probably won’t need it in the future either.
- Wait until you feel some pain before accepting the problem is real.
- Once you feel the pain then do the simplest thing possible to solve the problem.
- Then wait until you feel more pain before trying anything else in that space.
That considered process is Pain Driven Development.
Continue reading
When To Measure Lean-Agile Productivity, and When Not To
Lean-Agile offers two productivity measures: Velocity and Throughput. It is possible to improve both over time but there is little point in management demanding that a development team improve either because both metrics are very simple to fudge.
There is also little point in using either of these productivity measures in product development. The focus is discovery not churning stuff out.
Where a productivity measure is useful is in a project or programme. Where somebody is wanting to know when the team will be finished. Or, conversely, how much functionality will be delivered before the time and/or money has run out.
Build Less, Start Sooner, Innovate Constantly
Jim Highsmith proposed two simple strategies for successful software development: Build Less, Start Sooner.
Jim’s observation is genius, but I would add “Innovate Constantly”.
Continue reading