Have you been part of a large solution or portfolio team where you had no idea what another related team was working on? Have you been part of a single large team where team members were only focused and aware of what they’d been asked to do, oblivious to the bigger picture and context in which they operate?
These scenarios, called “siloes”, are becoming all too common in software development, especially in distributed teams that try to adopt agile delivery methodology. They can be really destructive for an enterprise if left unchecked. Siloed teams are very likely to develop non-optimized solutions which can cascade all the way up to an enterprise. This can result in projects that don’t serve to fulfill a program’s objective and therefore the strategy and vision that a company set out to achieve.
This is where we find that an incorrect understanding and application of the agile manifesto – valuing working software over comprehensive documentation – acts as a barrier to achieving these goals. Documentation, when done right, is a very powerful information dissemination and collaboration aid that not only overcomes siloes but also has many other benefits including:
Sounds too good to be true? Let’s dive In...
Let’s imagine a scenario where you have a reasonably structured onboarding process, supported by an easy-to-reference guide that enables new team members to adopt a self-help approach to onboarding. This enables quicker onboarding and only requires light guidance from another senior team member, improving productivity for everyone.
Contrasting this with an approach that’s very low on documentation or created using mostly word documents or power points. In the latter case, people stop maintaining such documents over time, leading eventually to the former, being very low on relevant and usable documentation. The responsibility, therefore, falls on long-lived individuals in the team, who while battling pressures of delivery, have to spend considerable time helping to onboard new team members. This process needs to be repeated every time a change occurs in the team. The end result is lost productivity and increased stress and pressure on the team which, over time, can and will lead to loss of motivation and what every organization wants to avoid: attrition.
This is really a no-brainer. Effective documentation about product development methodology, software engineering practices, architectural approaches and design decisions, to name but a few, enables team members and teams to adopt a unified approach to product development, which results in a higher quality of the software.
The alternative is for teams to follow widely varying practices and tools that create costly technical debts and potentially result in having to rewrite the software within a couple of years.
In a siloed setup, knowledge also tends to be siloed in the minds of certain individuals such as a Technical Lead or a Solution Architect. For a business that wants to scale, it’s imperative to ensure continuous development of team members to be future leaders, and one of the keys to achieving this is to use documentation as an effective mentoring and knowledge democratization tool.
In a world where documentation is effective, all team members have easy access to important information and knowledge such as approach and rationale for every stage of the product development life cycle, rather than just bits and pieces of information. Team members should also have the ability to question and recommend ideas as well as offer suggestions to improve things. This should not be just the prerogative of a selective few.
Lean documentation enables lean-agile practices that in turn enable business agility for customers. Let’s review this with a couple of examples.
Think of the lean startup approach that is the iterative build-measure-learn cycle for product development and innovation. In the absence of a well-defined and documented lean business case, defined MVP and benefit hypothesis, it is impossible to know if teams are developing the right product and if they should pivot or persevere, before it’s too late. Too much focus on just “working” software can lead to the development of products that don’t meet all the MVP criteria and end up being discarded due to lack of adoption or business impact.
Moreover, to adopt the practice of Set-Based design that enhances design flexibility, it is essential to document multiple requirements and design options so that teams can converge to the right decision as they gain more information. Otherwise, teams end up moving from one single point design to another, without empirical reasoning much later in the product life cycle, which is costly and wasteful.
Smart and effective documentation is as key to agile product delivery, as the measurement is to devops. Without it, important agile principles, such as design thinking, customer centricity, innovation, and continuous improvement, are often left to chance. What remains of agility is limited to the adoption of scrum ceremonies.
Here are a few simple guidelines to do it right. Documentation needs to be:
Documentation also needs to be served to address a gap or provide a benefit such as:
By doing this, we create a culture of empowered teams and team members who adopt a growth mindset, resulting in innovation and continuous improvement being the norm rather than a casualty of the daily grind.
It's also vital to invest in a documentation tool that meets most of the aforementioned criteria. Without it, even the best efforts of your teams are likely to fall short.
Netcentric’s culture isn’t something intangible or something hard to put a finger on. It’s a set of values and principles that can be continuously lived, demonstrated, and rewarded. When we engage with clients strategically, we not only bring exceptional competency and digital skills but also our unique culture to drive a holistic transformation that delivers success.
We have worked with large enterprise clients that have a hierarchical culture and helped them to establish and nurture digital delivery units based on our model.