Being a Customer
I have a group of students who build software for me. It’s pretty cool.
The students are taking a paper about agile software development. The class is divided into teams, and each team works with an industry representative who acts as their customer.
(Where a customer is someone who gives the team a prioritised list of feature requests, and receives working software in return.)
It’s a new experience for me. I’m used to being on the developer side, where we talk about feature creep, tasks going over their estimates, priority changes and difficult bugs. All of these phenomenon look different from the customer’s perspective.
As a customer, the most striking part of the project is the massive reduction of scope.
At the end of our first sprint, the team had finished exactly zero of my user stories. It was shocking.
Once they started explaining, my developer brain understood what was going on – they were working on legacy code, and just setting up the environment was tricky. There were unfamiliar tools and undocumented steps.
Even once the project was running, they found the code to be a maze of complexity. There was no clear place to make the changes I was asking for. The code didn’t speak the same language I did – I was asking them to work on objects that just didn’t exist.
I’m a developer, I knew exactly what they were talking about, and it was still disappointing. I can only imagine what it feels like for a customer who doesn’t understand the technical problems the team faces.
The good part is that this all happened in the first week of the project.
I re-prioritised, abandoning most of the features they were working on. (I hate when the customer does that!) We re-estimated and came up with a new plan.
Now we’re a few weeks in. Their estimates, my expectations and what actually happens are all starting to converge. When I ask them to “add one button to one screen”, they’re good at making me understand what I’m really asking them to do.
They have found a dev process which works – they work in pairs, for a fixed amount of time, with the whole team colocated.
I’m happy with how things are going.
Well, almost… sometimes they spend one third of a sprint on preparing a report for their lecturer. The report doesn’t relate to any of my user stories, but they refuse to drop it out of scope. Those crazy developers…