As an Agile coach I have encountered numerous situations which cry for improvement at a most basic level. Improvement needs are visible, dangling just on the lowest branch yet so unreachable that even talking about it brings on questions regarding the very essence of client vendor relationships. In this short blog, I tend to open a discussion and get your views on how to convert seemingly low hanging but otherwise unreachable improvement opportunities to problem statements targeting the whole organizational ecosystem, which makes them SALEABLE and thus produces opportunities to provide permanent solutions.
Let’s begin by exploring some impediments that’s quite common across agile teams:
Platform dependency – difference in code between the development and production and/or staging environment. Convert this impendency or problem into a process of having POCs and feasibility analysis for containerization. Even if the teams fail in the process, the benefits of containerization would provide the team a guided path towards a low coupling design. Eventually teams start building assets (Docker images)
Code smells and quality issues – another low hanging problem but cant be addressed just by introducing code quality tools (read SONAR, CAST) or by code review processes in place. A reusable framework consisting of developer habit along with tools and techniques to reduce code quality issues not only makes it an asset to aid organizational agility but brings business through cross selling.
Too much time and resource in POC/RnD – Too many spikes kills the scrum cadence, no debate on this. Replacing these spikes with carefully planned hackathons distributed across quarters and targeting dedicated problem statements brings on the learning, energy and takes loads off the scrum teams. Energizing those with RnRs is bound to increase participation and enthusiasm. Dependency on Organizational processes – Digitizing organizational process, opening it to feedback and improvement directives from all nooks and corners in the organization will create a dedicated and highly specialized process repositories and best practices. Selling organization process as an enabler to internal or external stakeholder would increase footprint as well as improve the overall organization mix.
The examples could go on – but I guess you got my idea!!
The process is simple: I follow the simple yet elegant TGROW model (feel free to replace it with any other that fits and sales!!)
- Choose the topic as the problem statement and frame it in such a way that makes it as generic as possible and related to a realizable service/ product definition
- Form the goals – prioritize them a LOT so that the team doesn’t get carried away of creating the topic and sprint goals suffer. Best is to make the topic a chosen organizational or client problem and get buy in from client – mostly it works if directly related to quality or dynamicity of change management
- Evaluate the Options – not only through standard option evaluation mechanisms like SWOT etc but through team participation
- Decide on Way forward – let the solution first solve the teams’ problems and then add it as a reusable asset. Share with BD teams and clients.
Author of this Blog