(…and 1 that Doesn’t!)
In my last blog post, I discussed why agile feedback is such an integral practice for high-performing teams. Feedback allows teams to effectively collaborate, communicate, and iterate to create a high-quality, polished product. While these qualities are always important, practice is even more invaluable during a time of physical distancing.
When we think about practicing Agile, we tend to think about checking boxes. We adhere to the prescribed meetings and practices of a particular flavor of agile, often Scrum or Kanban. But the Agile Manifesto doesn’t mention meetings at all, it only lists values. Often, we subscribe to a flavor of agile without imbuing it with the tenets of collaboration, communication, and iteration. This is adhering to the letter of the law but dismissing its spirit.
I’d like to delve into specific areas of the Agile Scrum ceremonies and processes where formal group feedback occurs naturally, yet may be underrated. Formalizing these agile feedback processes can help them find their place. However, all of these activities help to deliver quality regardless of what one calls them. If you practice a form of Agile but don’t use an official framework, I think you’ll find that many of these ideas still apply.
So, how can we welcome that essence into our work? Where do Agile processes benefit from feedback?
1. Planning the task goals – what is it that you are being asked to produce?
Defining the requirements and success criteria for a particular task helps ensure that everyone understands what needs to be delivered. Typically, a Product Owner comes up with high-level ideas and works with members of the technical team to establish criteria and a definition of done. When end requirements are well-defined, teams are much more confident that they are developing functionality that the customer actually wants. It’s ideal to accomplish this with a face-to-face conversation that involves multiple team members. If it’s impractical to have this conversation in person, due to differing geographical locations, health issues, or a pandemic, then a video call with the team will also work well.
It’s important for the Product Owner and the technical team to give and receive feedback during this process. The conversations may center around ideological feedback or technical feedback. They will certainly include probing questions to test assumptions and understanding. Testers are of invaluable help here, as this is the exact mindset that they bring to their work. Including testers from the beginning allows for smoother coordination later on when the work is actually being produced and validated. This validation is another type of feedback that will be addressed shortly.
2. Breaking up tasks – who will own the individual items of work?
Many teams work in Sprint iterations, where a number of tasks are chosen for completion in one- or two-week periods. At the beginning of the sprint, the team meets to decide which tasks to include and who will work on what. Choosing which tasks to include in the sprint might require re-visiting priorities. Although the Product Owner has set priorities for the tasks, it is up to the technical team to understand task dependencies and which tasks fit together into features or even into longer-term priorities. Task dependencies must be taken into consideration to help reduce bottlenecks for future development.
As teams discuss which tasks each member will be responsible for, it is important to leave judgement and egos behind to help increase team cohesion. Granting teams the ability to choose what they work on allows individual team members to deepen their specialized skill sets while expanding their generalized skillsets. This is how individual agile members become generalized specialists with the revered T-shaped skill set – through analysis that provides opportunities for growth without throwing members out of their depth.
3. Merging code – what can we learn through pull requests?
Your team uses pull requests to review new code, right? A lot of teams treat the pull request process as a chore. But with the right mindset, it is easy to see that this is a rich opportunity for learning and for feedback. It is important to define who will have the final say in approval and who will actually close the pull request. But the opportunity to familiarize oneself with another’s work is important for the whole team. This is not to say that every team member needs to review every pull request – that is not necessarily practical. However, it is important to recognize the process itself as an opportunity for transferring knowledge through feedback.
Pull request reviews are a good time for more junior members to study how more senior members provided clean solutions to problems. Asking questions may reveal even cleaner solutions. Pull requests are also a way for senior members to guide junior members in improving their work. Review encompasses more than just finding typos or bugs. It can also be asking for more comments in the code, for more modularized commits, or for a different solution pattern. Guiding team members through areas of improvement allows for less stressful and more efficient growth. That translates to a stronger team and ultimately a better product.
4. Testing – how can we receive constant feedback through formal testing?
The best feedback is detailed, analytical, and non-judgmental. Whether they are automated or manual, the best tests also portray those qualities in their feedback. Testing is often pushed to the end of a task as validation, or even to the end of a sprint or release cycle. While this is better than nothing, the best practice is to shorten the feedback loop by pushing testing as far left as possible. A test itself, whether it passes or fails, is a form of feedback about the assumption undergoing the test. As previously mentioned, the testing mindset is important to bring to the planning process as a way of helping to define requirements. Of course, it’s also important to test the work that is being done to make sure that it meets those requirements and doesn’t contain bugs.
5. Feedback from users – how does your product match up with your users’ expectations?
If the requirements and definition of done for a feature were thoughtfully fleshed out in their own feedback cycle, then your product features should be exactly what your Product Owner expected! Are they what your end-users are expecting? The User Acceptance Testing (UAT) process aims to answer this question through testing scenarios. Clearly the exact form of UAT can differ based on your product (for example, a self-driving car would require different UAT than an internally-facing web app). The goal is the same, which is to provide insight into how the application works from the end-user perspective. Ideally, these users do not know how your application works at a technical level.
UAT can uncover usability issues, or spark discussion around feature requests. Which flows work? Which are difficult? Does the product meets the business requirements as well as user needs? UAT allows for a feedback step in between task completion and customer feedback surveys (or worse, customer complaints). Even if you don’t have the ability to put your software in front of real users before shipping it, it is helpful to get the perspective of someone who hasn’t been involved in its development.
6. Retrospectives – what can we learn from our last cycle?
The Retrospective is the ceremony that usually comes to mind when thinking about feedback in Agile ceremonies. This ceremony is for the technical team, and the focus is on generating constructive feedback and action items to improve team cohesion and productivity in the next cycle. There are many different ways to hold Retrospectives. Switching up the process can help keep the team engaged. One of the biggest reasons that agile Retrospectives can fail to deliver value is if the team isn’t engaged enough to generate and provide thoughtful feedback about what was working well and what could be improved. The other pitfall, naturally, is to not follow up on action items identified during the retrospective. The Retrospective is the ceremony that allows the team to pick its own brain for feedback to propel it forward.
7. Backlog refinement – what have we learned since we wrote these tasks?
The Backlog Refinement is the place for re-prioritization of items. It isn’t the time for extensive feedback about upcoming tasks. The point of the process is to quickly revisit these items. Useful re-prioritization can’t happen in a vacuum – it has to come as the result of feedback. This can be re-prioritizing stories that are blocked due to factors outside the team’s control. It could also be the case that after a sprint’s worth of feedback, the Product Owner realizes that some of these stories are actually more important than previously thought, or are vague and need to be broken down into multiple stories. This is the process that recycles feedback into the next iteration of business requirements!
Now, there’s one Agile ceremony that does not benefit from formal feedback…the Daily Stand Up!
Why does the Daily Standup not benefit from formal feedback? The Standup is a short check-in meeting where the work for the day is planned and blockers are brought to light. It’s not a place for opinions or lengthy discussions about the merits of certain actions – those conversations should be taken outside the Standup. At most, it should be a place to plan for those fruitful conversations to take place.
