Re-visiting agile feedback

One of the topics that I wanted to write for the last months is agile feedback. It’s not a hot topic and clearly it’s not a new one. The reason that made me write a few things about it is the fact that for more than one year I work remotely as a software development manager. My primary role is to manage 7-10 global development teams, enforce the highest level of quality and drive them towards our business goals and delivery dates. Piece of cake, no?!

We are not following a specific agile methodology such as Scrum, Kanban, XP etc. I’d say that we have our hybrid agile process that make sense for us and we try to improve it week by week. We decided which agile practices fit to our organization, our values and culture and we apply them to our development process. One of the key concepts and ideas is : feedback. Everyone (development teams, product owners, upper management, customer support) is telecommuting. At the same time we have customers literally all around the world expecting every month new features and improvements alongside the typical defect fixing. With global teams is very easy to lose focus. The absence of a co-located place where you can just jump to someone’s office and discuss or work together might be an issue. What we realized is that feedback across all functional is essential to keep the business smoothly running and hit our goals and targets. In this blog post I will discuss the different flavors of agile feedback we enforce.

Build stability feedback

Simple, yet very important. I’m simply talking about Continuous Integration and the value of letting developers know as soon as possible (less than 10′ after pushing the code) if their changes broke the build or if they introduced any failing tests. Imagine that you are a member of a distributed development team. It’s Friday afternoon in Australia and one developer is committing to the development branch but since there’s no automated build no one realizes that the build is broken because a couple of files where missed. She shuts down her machine and she enjoys the rest of the weekend. However it’s still morning in Europe and U.S. developers will start their day later so when they checkout the code they find out that they cannot build the project or even run it and they spend a lot of time to undo the latest changes and bring it back to stability. Build stability feedback was our first step towards agile feedback and we have a common rule. When we start a new project, we never add new features unless we have a stable and automated build process and more important all developers are notified through their preferred channel (email, slack, PM notification etc.) in less than 10′

Quality Feedback

Putting crappy code to the code-base that just doesn’t break the build is not enough. We adopted the continuous inspection process and we made it as an integral part of our software development life-cycle. Having that said, every check-in, if it’s successful according to our build stability process. is analyzed against a common and objective set of quality rules and if a new issue is discovered then developers and me ( the development manager ) are notified in less than 20′. Then we decide how we will treat the new quality flaws. Do we want to fix them right away, or plan them for the current sprint, next sprint, current release etc. ? Quality feedback is there to make us aware of the code quality level and help us make decisions about our next actions.

Upper Management Feedback

This might sound strange but yes, we do have a process of getting feedback from the upper management of software development. This is an essential part of our weekly process because we make sure that every team is still working on the right goals and they are all aligned to our core values and strategic imperatives. This process aims not only to provide feedback to the development teams but also to the development managers about their way of management. In some cases based on this feedback we make decision about things we should change or try differently, especially if teams are not performing well or are working on items that don’t add business value to the product.

Process Feedback

No-one is perfect and every process needs tuning. Every two weeks we hold a retrospective video-call (remember we are distributed global teams) to discuss about the things we did right and those that are not fitting to the team. This is a strictly developers meeting and we focus on the practices that cause us delays and stop us from delivering business value.  We discuss about what can be further automated, communication issues we might have with other business units like customer support, or marketing or product owners and we decide how many different items we will try for the next 2 weeks. We don’t try many things at the same time because it turned out that it’s not very effective and in a long-term it actually causes the opposite result. We also decided to do this retrospective call twice a month and not every week because – in our case – one week is not always enough to evaluate if the changes we are applying have the expected positive effect or not.

Product Owner feedback

Simple, yet very important. Product owners attend all of the development meetings and they are available every day to provide feedback about new features, clarify requirements and work together with the developers to solve any problems. Every week also we hold a demo meeting call. During this call the development team presents the features implemented last week and the product owner gives us feedback about our progress. If needed we also discuss about possible requirements or priorities change. This is actually one of the most critical meetings. I still remember how bad things went when for some reason we skipped the weekly demos to the product team for a whole month. When we finally did a presentation, there were so many things that we missed during implementation and we had to redo almost 7% of last month’s work.

Customer feedback

Last but not least is the customer feedback. Most of our products target enterprise customers so it’s not realistic and it doesn’t provide any value to have a demo to the customer every one or two weeks. However the product team is doing periodic demos, presentations or even roadshows to customers about upcoming features and releases and the feedback we gather from those events is reflected back to our road-map and our backlog priorities.

Summary

In this post I presented the different ways that a development team is getting feedback from various sources (management, product owner, customer and automated tools). Our biggest problem was and still is that our developers are telecommuting and it’s “extremely easy” to keep them in their silos without any proper communication and constructive feedback. I assume that all of the above feedback flavors make absolutely sense not only to distributed teams but also to typical teams working in the same environment. I’d love to hear your feedback ��� about this post and maybe share your own experiences.

Feel free to share it to your networks.