I both embrace change and also fight like crazy to reduce scope creep. On my current programme I use three main techniques to control scope: Programme Vision, Release Goal, and Requirements Trade-off. In different ways all of these put the business in control of what is in/out of scope. But they all help me stay within budget and time constraints.
Continue reading
Kanban in Video, Post and Book
I’ve been using the Kanban method for several years now and I recently introduced my latest team to its joys. I do a lot of arm waving to explain the method but I also direct them to some essential viewing/reading. So I thought I’d share my Kanban recommendations – one video, two posts and a book.
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
Six Reasons to Adopt Specification by Example
I love the whole concept of Specification by Example. This approach ticks several boxes for me:
- Business requirements
- Concrete requirements
- Earlier conversations
- Shared understanding
- Automated tests
- Living documentation
90% Complete not = Done
What do you do when a developer claims “I’m 90% complete”? Well, don’t rely on it and patiently wait for 100%.
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
Specify Business Rules by Example
If you are going to use Specification by Example then start by specifying the business rules.
Continue reading
What do I do When the Project Manager is late for their own daily meeting
I got asked what I do when the Agile Project Manager is late for their own daily meeting?
Continue reading
The Sign Off – An Example of Delegation and Decision Making
I had just joined a team as programme manager and was talking to the lead user experience (UX) designer about the latest version of the UX design. We’d not worked together before and this was the first time I’d seen the designs. They looked pretty good to me and I told her so. That is when it got a bit weird.
PgM: They look great.
UX: Okay, I’ll get everybody together to get sign off on the designs.
PgM: Um, who is everybody?
UX: <Lists names of the business representative, product manager, technical architect, business sponsor, technical sponsor, UX discipline lead for the department, development manager, portfolio manager, team assistant to take notes, and quality manager>. I hope they don’t want too many changes.
PgM: <Jaw drops>