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
Tag Archives: agile
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>
Specification by Example versus Behaviour Driven Development
Personally I favour the phrase “Specification by Example” over the more commonly used term “Behaviour Driven Development” (BDD). That is because I demand the specifications are by example but only encourage my developers to do outside-in test first development (from BDD).
Continue reading
No walls: What to do when you’ve no Walls for your Informative Workspace
You move into a lovely new office. Lots of light and open spaces. Beautiful. Modern. But no walls.
Agile kind of assumes you’ve got walls. Whiteboards. Sprint Plan. Product Backlog. Burn down Charts. Kanban boards. Cumulative Flow Diagrams. All prominently displayed to transform your office into an Informative Workspace.
So what do you do when there are no walls?
Continue reading
Epics: My Love Hate Relationship with Large User Stories
Epics aren’t very good for driving the development team because Epics lack sufficient detail and will take too long to complete anyway. But Epics are, like their smaller relatives the user story, great as a place holder for a conversation.
Continue reading