The product owner calls everyone together and explains the "crazy" direction we are headed and why.
Team morale does an immediate 180-degree turnaround and sky-rockets.
Product Owner has a Sprint Goal
This little tidbit of Sprint Planning often goes unnoticed, is frequently forgotten or never mentioned. But when you see the difference it makes for a bunch of devs that thought we were building the wrong thing and then realize how crafty your product owner is... well you will not forget to insist on the reasons - the goal of sprints you and the team are running.
Years ago, in a rainy distant land far from sunny Texas, I worked for a SpeakEasy. The company was a hot-shot in ISD land (Internet Service Delivery in the days of modems). They had this crazy idea to build a Voice-Over-IP telephone product and hired out the tree-hugging hippies from a little consultancy company across the lake. These hippies said they had a new collaborative way to build products that worked so much better and made applications that clients would fall in love with. For some reason, we will never know, the SpeakEasy leadership thought they could use some of that magic collaborative "Kum ba yah" development process to gain an advantage in the market space. So they hired the hippies to mentor, teach and staff their project.
After several months of hard work, and the realization that this product was going to take much more time than the 3 - 4 months leadership had envisioned, the devs started to get restless and chatter in the break room was quite negative. The group had some mild success - they had scaled up from just a handful of developers to something like 40 developers on 5 teams, some members in South America. But the lot of them were unhappy with the project direction. There was very expensive Broadsoft server hardware in the lab - they needed to get telephone calls working via that hardware. Yet all the team time was being spent sorting out the buttons and dropdowns of the User Interface. Yes, it was quite complex, and we had some expert designers that worked very well with little friction in this new quick to change process. But the core of the developers knew the project was going to fail - because we had lots and lots of work to make a cell phone connect with a land-line and tunnel sound over the internet. That work had not started. The Christmas deadline was approaching.
Word got around, and back to the product design group - our product owner call an all-hands meeting. I'm sure it was after lunch because there was more than one liquor bottle in paper sacks being passed among the devs. Were we all getting the ax? The Product Owner started telling her story; where we were going, why it was so unique in the market place, why SpeakEasy was the provider that could pull off this end-run around the lazy leaders, etc. But then the question came out of the crowd - WHY, Why oh why, are we putzing about with this UI, when we have not placed ONE stinking call yet?
She paused, caught her breath, took up a marker and drew a timeline to Christmas on the board. She pulled out the Product Backlog and asked if our estimates were good? Yes, to the best of our ability, and we had be proving it sprint after sprint for months - we had good predictive evidence. She drew a diamond on the timeline a month in the future. This is the week of user experience testing - you are all invited to watch behind the one-way mirror glass. We have scheduled experts in UI/UX to test out our user interface with real users. The UI has to be done by then - a month out. Then we have all the remaining time before product launch at Christmas to make it functional - to place and receive calls, to go to voicemail, and all the other features we can get into version ONE of the product. But we have to have a user interface that the public can use - that means your sisters, brothers, aunts, uncles, mothers, and grandparents. It will not sell if the general public cannot easily use the phone and the web site accounts. She stood still, said nothing, it was sinking in - the room was dead silent.
Then, there were murmurs and laughter, and then a roar of relief as the light bulb over the crowd of devs came on full-force. She was quite the fox. It seemed sneaky. But there was no one to be fooled. It was just great to see her use of the tools we had provided. A large product backlog with good-enough estimates of all the features we may consider for the release. She had several plans, but they all had this one diamond about in the middle where the UX testing was to be done. Then the plans all pivoted to the functionality with some padding for fixes to the UX and she had feature option sets. But each had a release by the Christmas deadline.
Over the coming months we worked to those plans. Nothing went perfect, in fact, quite a few times we would bring up discovered work that would have to be done. Our PO was calm when presented with these technical hurdles, she would ask for the estimate of the newly discovered work - then find a feature or two that was similar in size and slide those into release TWO.
We all were astonished watching the public users of our application, behind the glass at the UX Testing lab. They were all idiots! They could not find the right buttons, or read the screen, or understand anything presented to them. It was frustrating to watch. The user interface got a complete re-work. But it was all very easy to implement since we had working code, may times it was trivial changes that made huge differences, for example coloring a button green.
We also had good guesses at how long it would take to build the technical calls to Broadsoft and make the functionality work. It was a glorious day when we called the executive sponsor on his cell phone in a sprint demo. The team was very successful. The project was a success. One executive quibbled when he jested, "I can not believe you went over your release estimate by 80 points." There were two or three thousand points in that first release. By any measure, we hit the target.
Team morale does an immediate 180-degree turnaround and sky-rockets.
Product Owner has a Sprint Goal
This little tidbit of Sprint Planning often goes unnoticed, is frequently forgotten or never mentioned. But when you see the difference it makes for a bunch of devs that thought we were building the wrong thing and then realize how crafty your product owner is... well you will not forget to insist on the reasons - the goal of sprints you and the team are running.
Years ago, in a rainy distant land far from sunny Texas, I worked for a SpeakEasy. The company was a hot-shot in ISD land (Internet Service Delivery in the days of modems). They had this crazy idea to build a Voice-Over-IP telephone product and hired out the tree-hugging hippies from a little consultancy company across the lake. These hippies said they had a new collaborative way to build products that worked so much better and made applications that clients would fall in love with. For some reason, we will never know, the SpeakEasy leadership thought they could use some of that magic collaborative "Kum ba yah" development process to gain an advantage in the market space. So they hired the hippies to mentor, teach and staff their project.
After several months of hard work, and the realization that this product was going to take much more time than the 3 - 4 months leadership had envisioned, the devs started to get restless and chatter in the break room was quite negative. The group had some mild success - they had scaled up from just a handful of developers to something like 40 developers on 5 teams, some members in South America. But the lot of them were unhappy with the project direction. There was very expensive Broadsoft server hardware in the lab - they needed to get telephone calls working via that hardware. Yet all the team time was being spent sorting out the buttons and dropdowns of the User Interface. Yes, it was quite complex, and we had some expert designers that worked very well with little friction in this new quick to change process. But the core of the developers knew the project was going to fail - because we had lots and lots of work to make a cell phone connect with a land-line and tunnel sound over the internet. That work had not started. The Christmas deadline was approaching.
Word got around, and back to the product design group - our product owner call an all-hands meeting. I'm sure it was after lunch because there was more than one liquor bottle in paper sacks being passed among the devs. Were we all getting the ax? The Product Owner started telling her story; where we were going, why it was so unique in the market place, why SpeakEasy was the provider that could pull off this end-run around the lazy leaders, etc. But then the question came out of the crowd - WHY, Why oh why, are we putzing about with this UI, when we have not placed ONE stinking call yet?
She paused, caught her breath, took up a marker and drew a timeline to Christmas on the board. She pulled out the Product Backlog and asked if our estimates were good? Yes, to the best of our ability, and we had be proving it sprint after sprint for months - we had good predictive evidence. She drew a diamond on the timeline a month in the future. This is the week of user experience testing - you are all invited to watch behind the one-way mirror glass. We have scheduled experts in UI/UX to test out our user interface with real users. The UI has to be done by then - a month out. Then we have all the remaining time before product launch at Christmas to make it functional - to place and receive calls, to go to voicemail, and all the other features we can get into version ONE of the product. But we have to have a user interface that the public can use - that means your sisters, brothers, aunts, uncles, mothers, and grandparents. It will not sell if the general public cannot easily use the phone and the web site accounts. She stood still, said nothing, it was sinking in - the room was dead silent.
Then, there were murmurs and laughter, and then a roar of relief as the light bulb over the crowd of devs came on full-force. She was quite the fox. It seemed sneaky. But there was no one to be fooled. It was just great to see her use of the tools we had provided. A large product backlog with good-enough estimates of all the features we may consider for the release. She had several plans, but they all had this one diamond about in the middle where the UX testing was to be done. Then the plans all pivoted to the functionality with some padding for fixes to the UX and she had feature option sets. But each had a release by the Christmas deadline.
Over the coming months we worked to those plans. Nothing went perfect, in fact, quite a few times we would bring up discovered work that would have to be done. Our PO was calm when presented with these technical hurdles, she would ask for the estimate of the newly discovered work - then find a feature or two that was similar in size and slide those into release TWO.
We all were astonished watching the public users of our application, behind the glass at the UX Testing lab. They were all idiots! They could not find the right buttons, or read the screen, or understand anything presented to them. It was frustrating to watch. The user interface got a complete re-work. But it was all very easy to implement since we had working code, may times it was trivial changes that made huge differences, for example coloring a button green.
We also had good guesses at how long it would take to build the technical calls to Broadsoft and make the functionality work. It was a glorious day when we called the executive sponsor on his cell phone in a sprint demo. The team was very successful. The project was a success. One executive quibbled when he jested, "I can not believe you went over your release estimate by 80 points." There were two or three thousand points in that first release. By any measure, we hit the target.
Comments