“inspect” And “adapt” – Transparency And Scrum Implementation

By Author: Mrugesh panchal
Total Articles: 48
Comment this article

Each business organization follows its own particular methodology and process flow while conducting its business. The management decides about the protocols to be followed and how the team members should interact with each other. One of the sensitive issues, often stringently controlled by the companies through the implementation of technology and work processes, are the levels of transparency followed and allowed within the organization. In the business world, where critical work related information is zealously guarded, and its flow is stringently controlled by various ways and means, transparency is key issue which is often debated, discussed, and controlled by the chief level officers. In many ways, it is not our nature to be open and share our knowledge with others, primarily because right from the amateur league baseball diamonds to the lecture halls of reputed business schools, we are always taught to be competitive, push ahead of the competition, and maintain a discreet silence about our plan of actions and what we intend to do next.

Now, consider a situation where a typical organization decides to implement scrum. ...
... The management “hears” about the Agile framework, and how it can benefit through the product increments by implementing scrum in its projects. There is a lot of enthusiasm, and the management responds positively to the proposals forwarded by the Agile coach – the person appointed by the company to implement scrum methodology. The project owners are eager to proceed with scrum. In its haste, the management does not pause to understand how scrum is liable to affect the company’s policy regarding the levels of transparency, and as to what and how information pertaining to the project should be ideally shared. The Agile coach is also eager to start with the implementation, and in his or her haste to work out the product release, completely fails to study the company’s policies regarding the transparency levels.

The scrum team is carefully worked out by the management under the guidance of the coach. The product owner, scrum master, and the cross functional development team – all are properly appointed by the management, and their contract dully drafted. The product release too is documented and decided for implementation. Everything seems cool and cozy, and perfectly planned. Scrum is implemented. The first sprint planning meeting is conducted, and wham! The blow is struck cleanly, in the “place” most unexpected. One of the development team member wants to know more about the business values associated with a particular user story, and demands that the product owner elaborate upon the manner in which the stakeholders (the management) plan to incorporate the user story into the product, and how much importance it has while considering the “worth” of the product. The product owner hesitates, fidgets, and slowly takes in a long deep breath. Unknowingly, the member has exposed a sensitive nerve. Should the PO deliver information pertaining to the business value? While the management policy indicates “certain” information should not be shared with the team, does the PO veto the HR policy and share information because scrum principles advocate total transparency and collaboration? Does the PO approach the management with the issue or take an “ex parte” decision and share the information? This could be an example of a typical scenario experienced by the scrum team when it undertakes a project bound by stringent HR policies and restricted access to information.

Scrum and transparency levels
The main principles which form the backbone of scrum are “inspect” and “adapt”. Scrum supports transparency in the truest sense, and everything is “shared” to facilitate the collaboration process which is so very essential for a successful scrum implementation. Increased transparency and sharing of information not only streamlines the scrum process, but, in addition, nurtures it for delivering consistent product increments.

Validation of ideas and thoughts
Sharing information and publicizing your ideas provides a chance to weigh in the pros and cons, and render an insight into the relevancy, feasibility, validity, and practicality of suggestions offered by the team. The team gets a chance to think about the development aspects well in advance and offer a personal opinion concerning the technical difficulties likely to impede the team during the sprint process. Rather than facing technical issues while the daily sprint is currently underway, the team members can work out possible solutions in advance and prepare for the subsequent development during the sprint iterations.

Collaboration and sharing of ideas
The act of sharing begins by a dialogue initiated by a team member in which other members subsequently join in to offer possible solutions concerning a particular issue. As the discussion grows, more factual information pours in which can offer valuable insights and alternative ways in which the problem can be tackled by the entire scrum team. Feedback and sharing of information provide the base upon which new methods can be explored and discovered to fulfill specific objectives.

Getting the work done
Transparency is a great tool to get work done by openly discussing how much work has been completed by individual team members, when, and how. When people openly discuss their contributions, it creates a certain level of healthy competition amongst the team. Each team member evaluates how much work has been delivered by his or her colleagues, and compares the productivity with others. The developer tries to maintain the team velocity during the daily sprints to ensure he or she contributes by developing the sprint backlog items as per schedule. Healthy competition fosters successful product increments.

A source of inspiration
Sharing of ideas lead to increased transparency, improved transparency levels lead to meaningful and productive discussions, and focused discussions lead to solutions. When ideas are shared and visible to everybody, it serves as a starting point for generating valuable feedback. The feedback helps to make the retrospective sessions more effective. Self-learning and self-correction processes which form the base for sprint retrospective are possible when ideas are shared and transparency is enhanced.