If any organization has discovered the secret to producing error free software I’d like to hear about it. For most of us, if your teams were to take the time to make their working code absolutely flawless, by the time they’re done the market window will have closed and the users will have bought a different app. You almost always have to release software that still has some flaws, so you have to include a way to manage prioritizing and fixing them in your lifecycle.
Software development does not happen in a vacuum. Agile practices effectively bring business stakeholders into the development process to better steer teams toward creating software that solves real world problems. But what about the other end of the process? All of the agile process diagrams show the feedback loop where input from users is fed back into the agile backlog. But how does an organization realize that loop?
The tools that manage support cases are not designed to manage development work and vice versa. While plenty of these tools offer integrations to the other kind, it’s not just about being able to create an item over there when your daily working tool is over here. Support staff and other client-facing roles — who may be the best proxies you have to actual hands-on users — need to know what information is critical in an item in the development backlog and also how the development backlog is managed.
When is priority evaluated and assigned? By whom? How can I check up on where my item is in the list? How can I influence the prioritization decision? Have I provided enough information for someone to analyze the problem?
Our product teams conduct change management meetings that include these stakeholders. Everyone sees what’s in line to be done next and can weigh in on which item goes first. But talking about priority is not the same as making the creation and tracking of an effective work item a part of daily workflow rather than a disruptive special task.
At Streamline Health we do not have a full integration between our development management system (Microsoft Team Foundation Server (TFS)) and our support management tool (Salesforce). Client-facing folks have to find the TFS web portal to create a work item when they need help from development to solve a client issue.
The other day we had a lunch and learn session called “TFS for Non Developers.” You can believe that the support and other client facing folks were there, even though this one was a “bring your own lunch” session.
Although we’d presented this material before, regular refreshers, even for those who’ve been here for a while, are a great help in keeping the lifecycle process moving like a well-oiled machine. We showed the audience how to get to the TFS web portal and where to find the backlogs that they care about (structured by product). We reviewed the required fields and why they’re necessary. We showed them how to create and save their own queries, and how to create their own alerts. And probably most importantly, we gave them links to both external resources like the Scaled Agile Framework website, and internal guidance documentation.
An effective agile implementation must include cultural acceptance of principles that the framework depends on, like:
- Information Radiation
- Accountability and Responsibility
Helping our client-facing team members understand that they can look at the backlogs at any time, and that they are responsible for communicating their needs to the development teams in a usable form, is our responsibility. Only then can everyone be held accountable for delivering and maintaining excellent software.