A Development Teams Journey
In a previous post, we talked about the experience of a leadership team coming to realize the value of Outcomes and Impacts over Outputs. For this post, we are going to walk through how one development team came to that same realization.
This is still an on-going effort with this and many other teams at the organization and I will do my best to keep this updated as the journey continues…
Development Team Retrospective
During a recent retrospective. The team was thrilled they were able to deliver a large new feature in such a short time frame. It had cost them many long days and nights work and they are now exhausted and had to move on to the next large batch of work in yet another short window. This team was stuck in the “Service-Provider” or “IT-As-A-Service” model we all know too well. At one point, a strong question was raised.
There was a real conversation about the true length of time and effort to build that feature vs estimate. It was helpful to have the data on hand to compare estimate vs actual. The team realized again that it really was a massive effort in a short window. There will be another post on how the team is trying to address that.
Back on the focus of the feature, another question arose.
Yet another great conversation about the defects and even bugs that were found during and after development, how the team resolved them and how to avoid those types of defects and bugs in the future. Again, it was helpful to have the defects and bugs available to reference as well.
The next question from that retrospective got a couple people to think a little different about the way they are working.
This conversation was great! The team had varying opinions on that question.
- “I don’t know if they are using it or not, we have moved on to twenty other things since then.”
- “Nobody is complaining so it must be working great.”
- “How would I know that?”
- “We don’t have a way of knowing that.”
- “We don’t have time to go out and ask them about things like that.”
- “Why would we care if they use it?”
That last question hurt to hear if I’m being honest. The topic navigated towards Product Thinking and how it helps to determine better solutions that people like, use, and keep using. It brought to light the difference between being scribes taking orders or being partners finding solutions. It was decided that it was better to be more like Doctors and less like Waiters. And the benefits of this approach when it came to not only what, but how to deliver solutions.
Ideas were being tossed around about how and how to measure the Outcomes and Impacts of features. With this particular team they came up with a hypothesis. “If we could provide solid data that some of the things that were deemed critical, aren’t actually used, we could prevent waste in development effort and within the product itself?”
One of the conclusions is they would be able to either improve or remove areas of the system that were lacking the desired functionality.
This is where it got interesting. One of the BA’s, yes we have BA’s, said “What if we could identify the expected Outcomes and Impacts of what we built, before we built it?” Again, more questions and comments from the team.
- “Why would we want to do that?” – Really after all the previous discussion.
- “I’m just here to build what they tell me too.” – Some people are harder to reach then others.
- “How does that help us with “requirements?” – There is that word again..
It was back to the drawing board on understanding why this is important and how it benefits the team as much as the customer and user. Ultimately everyone agreed that if they could understand the problem they were solving, they could determine if it was worth solving, or if there were better ways to solve it then the solution they were being told to implement.
Next was about how they would do it. They found a request for some functionality in the backlog that nobody had tried to tackle fully yet. Took to task creating questions, risks, and assumptions about the functionality. Came up with a plan to answer the biggest question.
Only this time, instead of the Business Analysts going out and gathering requirements, a small core team would meet with the users together. This small core team was comprised of a BA and PO, a Sr. Developer, a QA specialist, and a UX Designer.
The team still questioned what they would be doing in that meeting. The answer was simple. Have the conversation and listen to the users problem. Offer solutions, sketch out the workflow and some design ideas everyone can look at. Part of the plan was to time-box this first meeting to an hour. Create a spike in the next sprint to account for this discovery work and time.
The statement that landed for a few members of the team was the need to gain shared understanding of not only the problem and solution, but how to would measure the Outcome and Impact of the solution. This way they could avoid building software that was rejected, not used or not liked. As well as moving away from the fire and forget approach.
To understand what might come out of this discovery meeting, an exercise on mapping together as a team on the steps you take to getting to work in the morning was attempted. I love this example. Now you could do this with anything, washing a car, making toast, preparing for a party. Really any example that puts people in the mindset of the steps they take to achieve some goal. Here is an image from that exercise. Now this is just a snapshot of a point in time, but people had a great conversation around what would go first, if they didn’t have pets or kids they made alternative maps.
This exercise helped the team to see that when they had something, like a map, that everyone could look at together, they could achieve that shared understanding of what was needed to get from start to finish. Now they just need to have this happen for a piece of software and hopefully it will land for everyone else.
That is where we stop for now. Stay tuned as this plays out.
To Be Continued…
Chris Pipito 