by Venkateswaran KN
I like to think of Software Development as the ultimate team sport. The parallels between sports and software development have been well documented. In fact, the “Scrum” in the Agile Methodology originates from rugby. A cursory google search would bring out the history and context of this term.
At the risk of dating myself, I worked on a project executed under the much maligned and now almost extinct “Waterfall approach”. We will look at this in more detail a bit later on, but the Waterfall approach to software development may be likened to a relay race.
The requirements document is released followed by the solution design, the technical design, test and feature / product release. Like in a relay race or a stack of dominos, the process proceeds in one direction. Any changes identified in the middle of the process, can usually only be accommodated as a “Change Request” which is triggered as a separate and new workflow.
However, complex projects usually involve cross functional teams and span multiple quarters. A more flexible approach is required for these projects, as challenges may be encountered during the development process, which in turn would require changes to the solution design and subsequent changes.
Complex projects, spanning multiple quarters, demand flexibility. Challenges during development may necessitate changes to the solution design, reflecting a more iterative approach. Customers might propose modifications, introducing an element of moving “one step backward” to move “two steps forward,” much like the classical scrum analogy. While well-known in software circles, what’s less discussed is the impact of Culture on Software Development teams. Like sports teams, no two software teams, even within the same company, are identical.
Executives transitioning across different domains within the software industry, from roles like Sales to software, face the challenge of understanding different cultures. Successful companies may seek to “import” best practices and incorporate Machine Learning from diverse environments. The key is to navigate and bridge different software cultures effectively.
Even the simplest feature passes through all the stages shown below. The process is a flowchart to handle changes or surprises at every stage.
What are some common factors that cause deviations from the above demonstrated flow?
- Experimentation – It’s crucial to identify requirements needing experimentation or prototyping before reaching the Solutions Stage. An important motto for me is that Agile methodology doesn’t mean poorly defined requirements. Business Owners (Product Manager, Product Owner, Business Analyst) should ensure clarity in requirements. Agile applies at Solutioning and Development stages.
Requirements are like “raw material” – teams can do very little with a bad brief. Well-defined requirements allow creative solutions at the solutioning stage. Sometimes, experimentation extends to the release stage with features in beta.
- Estimation – At the Requirements stage, Development teams provide high-level estimates based on assumptions. What if a “Must Have” requirement has a very high estimate?
- User Workflows – If the feature or application requires new wireframes, it is logical and optimal to design the workflows for the “Happy” paths. However, during development, all user flows should be handled with appropriate errors warnings. These may sometimes bring about new workflows, not envisioned during the design stage.
- Priority Changes – Due to business reasons, teams may at times need to re-prioritize or re-scope features.
- Technical Feasibility – Is it possible to know the technical feasibility of all requirements at the Requirements stage?
While not a direct factor, it’s crucial to consider Team Structure and individual member Skill Sets within this framework. Team members might assume roles beyond their designated ones based on their skills. For instance, a Technical Lead could excel in functional knowledge, almost taking on a Product Owner’s role. Such deviations can prove to be strengths for the team.
In diverse environments, I’ve observed the remarkable adaptability of software teams to ensure continuity. However, in times of change, teams may adapt sub-optimally to external pressures. Clear leadership becomes invaluable in guiding teams through these adaptations.
To assess software teams, consider these questions for newcomers and decision-makers:
- How are the requirements gathered? Who does the requirements gathering? Which artefacts are used to document the requirement?The term “Requirements Gathering” is a slightly dated term, but I believe it is still relevant today. All development stem from a requirement or a need. Sometimes requirements can just be one-liners and at times they need to be more elaborate.
- Who creates the solution? Who is responsible for the documentation?As mentioned before, roles may overlap and that is perfectly fine. But it is important for managers to have a good handle on the same. It is very important to use the words “Requirements” and “Solutions” correctly. Many a times, the solution is not clear, but teams may mistakenly say that the requirement is not clear. Solution not being clear is an easier problem to handle. Requirement not being clear is a deeper problem. I cannot emphasize how important it is to use these terms judiciously.
- Who performs the Estimation? Is it a high level estimate or a granular estimate? Who is the intended user of the estimate?
- How is the planning performed?
- Is development going as per plan? How is the technical design being documented?
- What practices are adopted for testing? How are test cases developed? Is it an automated testing setup? How much of automated testing is possible?
- How equipped are the QA teams to perform detailed functional testing? Do QA teams need support from Product Owners / Product Managers?
- What is the release rollout plan? Is it a push-type release or can the customer choose?
- How is feedback obtained from customers? What is the feedback loop after release?
The intriguing aspect of software development, culturally speaking, lies in how customer culture shapes the software vendor. Many vendors tailor their products to specific industries, and the culture of a vendor serving healthcare differs significantly from one serving the automotive sector. Software vendors tend to mirror the culture of their customers more than each other.
The degree of regulation in the customer’s industry deeply influences the vendor’s culture. Generally, in highly regulated industries, vendors need to be process-driven and rely on extensive documentation. Process and documentation, in this context, act as allies, safeguarding the vendor.
Consider the healthcare industry; as an end user, you wouldn’t want software vendors to “move fast and break things.” In such cases, thorough testing becomes crucial. In my experience, teams in such environments often adopt a “Modified Waterfall” approach, albeit cautiously, as “Agile” is usually the preferred method mandated.
In essence, the journey from requirements gathering to release proves to be an endlessly interesting and fascinating process. There’s never a dull moment in the captivating world of Software Development!
(The author is Principal Product Manager, Sabre Bengaluru GCC, and the views expressed in this article are his own)
