Transparency, for Better Application Delivery

As seen in Dzone.com »

 

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: A Key Requirement to Successful Delivery

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.

 

Continuous Delivey

How Transparency Can Transform your Work Environment 

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 on 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 creates confidence for making informed decisions about changes in scope or prioritizing throughout the release.

Transparency done well produces a trustful environment and simpler 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 and Visibility: Not More of the Same

When we say “transparency,” don’t think only “visibility.” Visibility isn’t enough. Research done about 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 info 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 were 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.

Transparency: Integrating it into the Continuous Delivery Process

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 on the board, teams can decide where to focus their effort 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 on 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 preserving 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 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 to the wrong people. If managers or parallel teams can’t learn the information from the view, they either approach team members to acquire this information—which defeats the purpose of the view—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 deliver functionality if they have no visibility of its infrastructure status. Communication and collaboration 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: Sharing Across All Stakeholders   

As said, it is important to understand the players who require the shared information, what they require it for, and how they 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 of 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 need allows R&D teams to create a view that’s beneficial to the release manager and make them feel part of the team. Release managers in many organizations have a dashboard designed specifically for them combining views on 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 searches for 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 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 engaging. Teams that want to build a reputation of success and create perception of prosperity, 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 in either low or high intensity of reflection, depending on the situation. Usually, teams are happier to share and expose their process and performance only when the management is transparent as well. From strategic decisions through goals, promotions, hiring or firing, 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.

Conclusion

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 reflecting 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.

 

With the right methodologies and a designated platform, even enterprise organizations can be agile.  Download our White Paper, Introducing Agility to Enterprise Applications to learn how you can start releasing frequent, high-quality change today. 

 

Continuous Delivey

 

Start the comments

0

I Want Risk-Free Change

×