Delivery Culture
It doesn’t matter how great the idea. It is only as good as its execution.
Dual Track Agile
One of the pitfalls of conventional agile is that teams spend arduous time and energy on spring planning and story grooming meeting. Often, a poorly defined backlog compounds the problems and puts additional pressure on product and delivery leaders - taking focus away from activities that matter in focusing on customers and making them increasingly inward-focused. Not to mention that the probability of waste and rework increases because the backlog items have not been validated with either the customers or SMEs.
Even in agile teams, we may notice a ‘water-fall’ behaviour. The ‘requirements’ may still be collected by the product manager, passed onto the UX/Designer, and eventually shared with the engineering/delivery team to bring it into the sprint. This handing-off sequence creates bottlenecks in the team and robs the engineering team from being part of the discovery and the whys.
At any stage of the product development journey, the teams shall not lose the culture of validating an idea in the fastest possible manner, much before it comes to the whole team's attention to plan a sprint. At the same time, planning shall not be delayed, and non-valuable work shall get slotted in the sprints if one person raises the validity of the feature/requirement.
At Caizin, we have broken out of the ‘one team, one sprint’ mindset. We execute parallel sprints within a team with their dedicated subject matter. During the Discovery Sprint, our product manager, UX designer, and engineer lead collaborate to validate product ideas and features as part of the Discovery Sprint. They uphold shared accountability for building the right feature for the right customer persona and measure their success on - lesser bugs, lesser rework, better user adoption, and lesser office jokes.
Incrementally Earned Value Delivery
There are many concepts that Agile brings forward, which are challenging for stakeholders to grasp and a journey for product teams to truly master. To name a few - Agile Delivery, Iterative Delivery, Incremental Delivery, Continuous Delivery, Progressive Delivery - combined with concepts of Lean, XP, Kanban, Scrum, Kanban, and SAFe. These terms are intertwined in the spirit behind them and represent Lean Principles.
Of all these concepts, Incremental Delivery is most identifiable towards business value and value to the end user. An Incremental Delivery is one or more small features/functionalities released to end customers to use as an outcome of a sprint. The business stakeholder and end customers can realize the value offered by the feature/functionality after the release.
Incremental Delivery is a hard problem since it requires upfront investments in the following areas:
- Product vision and its communication to everyone on the team
- Investment in readiness for continuous integration and delivery
- Ability to switch on / off features to a subset of users
At Caizin, we constantly invest in our posture toward Incremental Delivery through a.) our initial discovery and idea validation cycles with relevant actors and painting a product vision with those insights, b.) investing in ready-to-use continuous integration, continuous delivery, test automation, feature flags, open source software adoptions and building capabilities in off-the-shelf software was rapid application development and deployment through better build vs. buy decisions, and c.) leveraging Agile, collaboration, and documentation tools extensively to make knowledge available to every person involved, as open and real-time as possible.
These help us be far more transparent to stakeholders as delivered value is showcased through not only progress visible in the collaboration tools, but also through sprint demos. Bringing visibility together enables the ability to switch gears since there is hardly any “un-done” work at the end of each sprint. It enables the team to continuously deliver business value and reduce business risk since financial commitment to a body of work for the stakeholders is always a month or less effort.
Themes, Initiatives, Features, and Stories
Practicing Agile for just its methods, ceremonies and structure sometimes may drive the team to miss the forest for the trees. Great autonomous teams feel automatically empowered when their day-to-day work can be traced to make a business impact through contribution to the overall product vision. It automatically brings the sense of what done looks like and what metric has to be measured towards success.
This act of correlation helps the stakeholders to make an informed decision about where the effort and money are being spent and the ability to influence any change of focus and high-level priority without micro-managing teams.
Lastly, this becomes an excellent tool to convey the why behind what is happening and any changes in priority.
At Caizin, we leverage collaboration tools and work breakdown methods to start breaking down the product vision into goals as themes alongside the initial product discovery with stakeholders, SMEs, and users.
Our teams further break them into Initiative (roadmap item), Epic/Milestone/Risk, or a feature and derive stories. tasks and sub-tasks from them as part of Sprint Planning and grooming.
Our showcases focus on the features, their use to the customers and users, and their alignment with the business stakeholders' vision and goal. We work with the stakeholders once a month to collaborate on the high-level direction, current achievements, and any need to change the roadmap corresponding to internal priorities, customer needs, and external factors.
Our product managers and scrum masters continuously give the team the visibility of overall direction, initiatives under focus, overall progress, and business and market feedback at the beginning of the Sprints. The rest of the time, teams are empowered to do what they do best in achieving the sprint goals.
Shift left practice
The traditional software delivery lifecycle model, which started taking shape into what we know as a ‘Waterfall,’ strongly believed in the sequential phases of software development. In this model, the requirements gathering, analysis, and design phases were focused on gathering as much clarity as possible on the software release process. It was followed by development against those features and requirements, with software quality, security, usability, and deployment-related activities as the last phase of the lifecycle.
In the real world, an ability to bring crystal clarity on what a product shall have as features and how they shall be presented to users is a myth. More often than less, this model of ‘shift right’ for quality/testing, security, usability, and deployment lead to adverse outcomes and, most of the time, causing a.) exponentially high cost of fixing problems, b.) unexpected costs (more hardware, resetting team’s focus, customer/client dissatisfaction), and c.) unpredictable time to market.
In various studies and publications on the cost of defects, it is found that the later in the cycle, the higher the cost is. In a product lifecycle, these costs can be devastating and, for lack of better words - life-threatening.
At Caizin, our delivery model and team capabilities are focused on Shifting Left, combining concepts of continuous discovery, integration, testing, and deployment within the same Sprint. Our teams, beyond producing feature code, also bring the following in the discovery, design, and development cycles in parallel:
Unit test and test automation
Writing tests for the code being developed. We follow test-driven development, and side-by-side feature development and drive test coverage to a high 90% since the beginning.
CI/CD
While the features are being developed, the engineering team automates the integration and release process to ensure that as soon as features get done, they are launched to various environments, without human involvement. The parity of the pre-production environment with the production environment ensures that software quality, performance, and scalability checks are not environment-dependent.
Security
Secure code testing for vulnerabilities in code using industry standards tools, combined with security testing of all the environments (not on production, but in pre-production environments as well). The security testing scope is not only looking for code vulnerabilities but creating a security posture that spans the public cloud, network, data in transit, and data at rest.
Design and usability
Our dual-track agile discovery cycles focus on gathering inputs on whether users want the feature, their intended use, their inputs on designs and prototypes, their ability to discover the feature by themselves, and lastly, wherever possible, a usability analysis through a click-through prototype.
Not everything can be shifted left
Quality, security, usability, and resilience have to be further monitored after the software deployment on production. At Caizin, we enable key checks and balances post-production for:
Key metrics
How various metrics important to business and product teams perform before and after feature releases. These include financial, customer experience, conversion, feature utilization, feature adoption, performance, errors, and audits.
Further test automation
Every bug or incident observed post-production is further test automated as part of the fix. It helps us ensure that the fix is not only done but also perpetually validated to avoid recurrence.
Usability
Beyond the discovery phase, we measure how customers are large are interacting with features and what are their potential challenges. This ensures that validating with a limited set of users and personas does not result in a failure with end customers at large.
Hypothesis validation
In the end, product features hypothesize the impact they will have on the users and business. The hypothesis eventually gets validated post-production through specific metrics and is “tested” for real.
Team Values
Simplified team values ensure that the principles derived from those values are upheld when in doubt. They also create promises and expectations with the other stakeholders.
At Caizin, our team values are crafted simple and articulative and are meant to be devoid of keywords.