If you follow my blog, you know that I talk a lot about collaboration and the impact it has on the success or failure of modern software projects. In a recent post on Agile Project Management, I closed with a brief mention about feedback loops being a major initiative for us in our next release. Here I want to expand on that a bit.
Let’s look at the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I would argue that every one of these mantras has a component of feedback to them and that iteration and the feedback that iteration enables and drives is fundamental to the Agile conviction. If you look more deeply into the 12 principles of Agile software, you’ll see the role of feedback there too. Feedback helps you clarify your understanding. Feedback helps you see things in new ways. Feedback helps you correct your course. Feedback helps you learn. Feedback makes you and your work better. Whether you follow specific Agile practices or not, feedback early and often is a critical component of being more successful.
There are countless ways in which we’ve enabled feedback deeply in our V.Next work. As we were planning the release and we really started to narrow in on what our core mission in this release would be, it became clear that a lot of the ideas we were discussing had feedback as a core principle. We latched onto that, drove that as a common principle and worked to make the whole greater than the sum of the parts. We’ve enabled feedback in many forms. There’s even more we could yet do but what we’ve got lined up so far is pretty exciting.
During this process we’ve evolved a graphical way to talk about the feedback cycles in a good software development process. This is clearly an evolution of the Scrum cycle which expands to include stake holders. We’ve also got a version that includes a feedback cycle for operations for the longer term application lifecycle.
That captures much of the structure of feedback and some of the activities but I think it’s also important to think about what kind of feedback you want. In our next release we’ve focused on optimizing the following kinds of feedback workflows:
Feedback on Priorities – Am I building the most important capabilities that you want? Am I doing it in the right order? If I don’t get to everything you want, have I delivered enough of the critical capabilities that the solution is useful to you and I can continue to iterate? This is all about making sure that the stakeholders and team are aligned on how the work will be organized and what capabilities (user stories, if you will) will be delivered. Our solution for this in V.Next is the Agile Project Management solution I described in my previous post. It provides a web based view of the planned work and progress, easily accessible by everyone with roll up from fine detail to coarse scenarios. It is easy to adjust and experiment with. It really makes a conversation about priorities easy.
Feedback on Design – Does the software deliver the capability you need? Have I properly captured the requirements? Is it going to be easy enough for the customer to use? If I haven’t understood what you wanted and translated that into a design that will meet your needs, then the best developers in the world aren’t going to succeed. I sometimes ask development teams “Have you every built what the customer asked for and not what they wanted?” I usually get a lot of people nodding vigorously. It’s a symptom of a problem where poor communication – both in the inability to conceptualize and communicate the requirements and in the diligence to validate the proposed solution. It is said that a picture is worth 1,000 words. In our next release, we are releasing a storyboarding tool to enable the development team to work together more easily with stakeholders to ensure that before they go build a user story/scenario, they’d had a high fidelity conversation about what the user experience is going to be and how the scenario is going to work.
Feedback on Working Software – Does the software actually do what I think we said it would? Now that I see it in action, is the solution actually going to work? I can’t tell you how many times I’ve built something that I thought was going to be great only to sit down and use it and realize it actually didn’t mesh well with my workflow. Back to the drawing board (or storyboard :)) for another round of design. There’s nothing like actually sitting down and using the software to get a feel for whether or not it is “good”. This is one of the biggest cultural changes in teams adopting Agile practices and yet, one of the most important changes. To make sure you are building the right thing, you MUST build it in reasonably small consumable increments and solicit feedback early and often. It will save you countless weeks of wasted work developing down a path that ultimately turns out to have been a dead end that you could have avoided much earlier simply by asking “What do you think of what I have so far?”. To help with this we’ve build a number of things in V.Next but the most significant of them is what we call the “Feedback tool.” The Feedback tool and associated workflow enables a product owner/business analyst/dev lead to easily solicit feedback on a specific set of user stories/requirements on a recent build of the software. The stakeholder can easily review the user stories and the associated storyboards. They can explore the software, capture screen shots, and comment on what they see. They can optionally capture video, audio, etc. and easily bookmark them to draw attention to areas where they have feedback. All of this is captured in a feedback work item that the product owner can use to make any necessary plan updates.
Feedback on Code – While the first 3 of these are primarily focused in enabling stakeholder collaboration, let’s not forget that collaboration between developers is important too. Code reviews are becoming a more and more popular way to enable feedback among developers. They can provide:
- A fresh set of eyes to make sure you didn’t miss anything.
- A good way to stay up to date on changes happening in a body of code.
- A good way to learn a code base and understand why changes are being made.
In our next release, we are enabling both a good and flexible code review work flow and a great code review experience. It will provide a great way for developers to learn from each other and get better by the day.
Conclusion
Getting feedback early and often is a critical component of your success. If requires organizing your work in a way that you can get feedback, being transparent so people can see what to give feedback on and incorporating that feedback into your work and getting continually better. By increasing the role of iteration and feedback in your development process, you can build better software and make happier customers. I think the features we’re building in our next release can help you with this a great deal. And this is just the beginning. We’ve got a bunch more ideas for how we can increase the richness and the reach of feedback cycles and you can expect to see us continue to invest.
Brian
0 comments
Be the first to start the discussion.