Transparency, for Better Applications
Transparency, for Better Applications
Customer engagement is a doctrine of its own, but RnD teams that build a communication channel with customers create trust with the customer.
Join the DZone community and get the full member experience.Join For Free
Every month-and-a-half, Mozilla releases a new version of their Firefox web browser. Internally, the company establishes an R&D commitment to delivery, and externally it publishes the dates and content of future releases. Subsequently, the pressure to meet goals is high and demands a lot of attention and accuracy in the planning stage. During the release timeline, however, things change and the organization needs to respond. Whether it is a competitor releasing a new feature or a technology that can improve performance, these changes affect the release and, if not administered correctly, can create disorder and confusion.
Teams that want to achieve agility, and as a result benefit from being able to introduce new features in the middle of a release cycle, need to continually know and understand their status—delivery and quality-wise. Only a crystal clear view allows teams and management to manage risks while deciding whether or not to push a new capability. Being able to reflect the state of the release at any point in time is a game changer for R&D and delivery teams, as well as leaders who want to take their dynamism to the next level.
Transparency as Integral Part of Delivery Pipelines
R&D teams planning their release take into account many parameters—capacity, requirements research, availability of third parties (parallel teams), and more. When the planning phase is over, team members should each have a clear understanding of the features they are working on and delivery deadlines. From then on, until the feature is completed, the information about the progress of development and testing usually remains clear only to developers, feature owners, and QA engineers who are part of the team and unclear to any other interested parties.
Why Is Transparency Necessary for a Succesful Delivery?
Without transparency, release managers who want to understand the convergence of the release must approach the team leader/feature owner and ask for visibility. Project managers who want to check on the status of new features need to inquire about this with QA engineers. In order to report on release quality, QA managers need to collect data from all involved teams all along the lifecycle, analyze and compile it so they can produce a clear view of the status.
Consider the case of HP Application Lifecycle Management (HP ALM), built over the last 20 years. There were several issues with its 11th version, identified as high risk only a few days prior to the release. The QA manager worked with four feature teams on the release. However, due to lack of transparency, he was not fully aware of the delivery details along the way. The issues were actually in the system for a while but were never reported. Nonetheless, they were serious enough for HP to release a critical patch with fixes less than two weeks after the original release of the version. This shows the importance of teams consistently reflecting the status of an application in a shared location—physically or technologically— so stakeholders can access, track, and extract the information they need at the time they need it.
Transparency done well produces an environment of trust and easier collaboration amongst the team and with others responsible for the development and release process. More importantly, transparency creates confidence for making informed decisions about changes in scope or prioritizing throughout the release. This confidence is transmitted over to organizational leaders and upper management who then give freedom of action to R&D, leading to a healthier work environment, better products, and higher quality.
Transparency Doesn’t End With Visibility
When we say “transparency,” don’t think only “visibility.” Visibility isn’t enough. Research done on transparency in software development ranks understandability—the ability to comprehend the information displayed—as the second most common problem for project reflection. Teams that share information should understand why consumers require the information and build the dashboard or report accordingly.
Sharing partial information is another concern when it comes to transparency. In 2015, a month before a well-known company in the Bay Area finalized their acquisition by an enterprise-sized company, their R&D team announced the release of a new mobile application with improved features and user experience. Management began bragging about the app in board meetings with their new owners but was disappointed to discover after that only an iOS application would be released. The new Android app release was planned for a few months later. The board of the enterprise decided to revoke the acquisition claiming the management team had been irresponsible in not knowing the specifics of the application release.
Sharing partial information defeats the purpose of eliminating the element of surprise, which is one of the main goals of transparency. Furthermore, such behavior creates distrust, at the very least, and at worst, severely impacts business operations.
Incorporating Better Transparency Into Your Pipeline
A tool as simple as a Public Scrum Board creates openness and insight into the team’s work and process. As a result, the team and external individuals may see, at a glance, whether they are on track to meet their Sprint goals, have too much work in progress, or are blocked on one or more stories. Based on the status displayed on the board, teams can decide where to focus their efforts and change plans on the fly. Using the same board, the change manager gains control of the features developed and is able to keep track of their state and progress.
Another useful tool for sharing information is a periodic delivery and quality status report.
Organizations now understand that while awesome new features might bring new customers, quality is the most important facet for retaining them. The focus on the product’s quality is higher than ever and has a lot of attention. Teams that are confident in their deliverables’ quality and share their confidence among the whole R&D group have a better ability to accept or reject change requests coming from the product manager or from customers.
Dashboards and graphs of quantitative information facilitate an accurate discussion about the release state. Release and change managers require precision in order to plan and change content during the release and these views enable this capability. But dashboards have a tricky element—relevancy.
Dashboards must display respective and practical information which stakeholders can utilize and benefit from so it is important to maintain different views for different stakeholders, so the information is relevant and clear.
In the same research on transparency mentioned above, another significant deficiency is sharing the right information with the wrong people. If managers or parallel teams can’t learn the information from the dashboard, they either approach team members to acquire this information—which defeats the purpose of the dashboard—or worse, ignore the information displayed.
When developing a feature that is dependent on services from another team, transparency and clarity become critical. Teams cannot commit to delivering functionality if they have no visibility into the status of its infrastructure. Communication and a collaborative culture can only be improved when the status of both teams is completely transparent and the teams understand and trust the others’ objectives and processes.
Transparency: A Cross-Organizational Effort
As said, it is important to understand the players who require the information, why they require it, and how they want to make use of it, in order to build the right view for the right individual. These include release managers, project managers, upper management, and even end-users, all of whom will benefit from transparency.
The top consideration for release managers is whether to approve a release or delay it. Convergence, quality, risks, and service level are the release metrics they plan and measure to monitor its status. Understanding this allows R&D teams to create a dashboard that’s beneficial to the release manager and make them feel like a part of the team. Release managers in many organizations have a dashboard designed specifically for them that combines all the parameters affecting the release and more aspects that can affect the release approval.
Project managers have a high-level view of all the components in the product—risk assessment and opportunities, product features and their priority, quality, testing and defects, and the deployment of the app in production. This is so they can build a project scope, evaluate the work involved, and create a schedule. Responding to their requirements and reflecting the appropriate information can change the course of a project and lead to its success.
Teams should continue working through the list of information and clients, recognize their part and responsibilities in the product delivery procedure, and create transparency to support the manner in which they make use of the information.
There are two more types of transparency—upper management visibility and customer engagement. Teams that want to build a reputation of success, need to be able to share their development process, show how it improves over time, and how they learn from and fix mistakes. This can be achieved via reflection. Usually, teams are happy to share and expose their process and performance only when the management is transparent as well. From strategic decisions through goals and promotions, being open and communicating decisions that impact a team make the working environment more stable and invites identical behavior from the R&D teams.
Customer engagement is a doctrine of its own, but R&D teams that build a communication channel with customers create trust with the customer.
Transparency is a key asset for creating a successful, collaborative organization, but only a few organizations put into practice the activities required for achieving it. Teams find it hard to invest time in creating understandable visibility of their processes or progress. Some teams are anxious about sharing their status as it might indicate setbacks. Such teams usually don’t understand how sharing their status -- no matter what’s going on -- benefits the organization and affects the way the team is perceived. As there are quite a few tools in the industry that help teams get to high levels of visibility and clarity, it’s simple enough to get started today.
Published at DZone with permission of Tal Doron . See the original article here.
Opinions expressed by DZone contributors are their own.