Even if for any reason you cannot apply nor introduce Agile methodologies in your organization, there are of course still important points to focus on and daily share, little by little, as a personal (and professional) mission to improve project productivity and team sustainability. The Agile manifesto already stands for a brief but complete list of lessons to learn and follow which however may be strongly restricted by corporate management and existing delivery patterns (customer relationships, documentation, release cycle, etc.). The Scrum framework though better empathizes three keys pillars which go beyond Agile practices and can indeed be applied to almost any type of complex project life-cycle and team leadership. Let’s analyze them.
Cone of uncertainty. Once again: the hardness of estimation. The cone of uncertainty just shows us how hard and incorrect are estimates at the beginning of a project and how they improve by the time, thanks to the increasing understanding of context and requirements.
The Mysterious Cone of Uncertainty.
In Scrum environment we would narrow the cone to an iteration scope, hence decreasing the risk of wrong estimates to at most a month, which is already a big improvement and it’s a core aspect of the framework. In non Agile projects, we can’t narrow it concerning time but it can definitely help us concerning understanding. In fact, we can still deal with it thanks to decomposition: the more fine grained a requirement will be, the better its estimate would be (or, to be more accurate, the less wrong the estimate would be).
The cone of uncertainty leads us to the core principle of Agile/Scrum: empiricism, learning by experience and change. If our project doesn’t allow empiricism (it actually does, like any project, it probably can’t be formalized in most of the cases), we can still narrow the cone of uncertainty to a decomposed requirement and yet applying one more principle of Agile Estimation: compare against a defined baseline, a task commonly understood and easy to estimate. It will help to have more accurate estimates and reduce the cone of our uncertainties.
Retrospective: a core event of the Scrum framework in which we can apply its core pillars: Inspect and Adapt. Inspect means try to understand what went well and what went wrong during the last sprint and try to improve it (applying yet another Scrum pillar: Transparency). Adapt means of course Change, for better. What can we learn? It doesn’t really matter whether we are Agile or not in our project and team, we can still inspect, we actually need to, as much as we can. And we can then adapt, based on agreed conclusions and as well limited by management and strategy (changes may be unfeasible or harder than expected).
At different levels (project, team, personal), we should actually try to have a periodic retrospective session which should have as output an effective improvement agenda, a commitment to reduce impediments and bottlenecks adapting to the changing requirements, context, scenarios. We could also use journey lines to draw positive and negatives feedback, collected feelings and results among the team, identify tipping points and understand what could be actually improved.
Servant leadership: in Scrum leadership isn’t mention as often as in reality it would be required, the Scrum Master is indeed a management position but its main scope – among many – is to facilitate collaboration and remove impediments within the Scrum framework, it is hence to serve others. The Product Owner is the only accountable for the Product Backlog and related matters and its main scope is to provide a clear set of stories to the team, it is once again to serve others. The Team is self-organized and no one else can change the content and the priority of the sprint it committed to. Leadership is hence serving and not leading others, changing upside down the normal organizational structure:
What can we learn? Rethink our management attitude and seek a better pattern to improve productivity and motivation, empowering teams and serving them, applying the golden management approach recently discussed.
Of course, applying any of these improvements cannot grant an Agile approach nor would we entitled to claim to use the Scrum framework, we would easily fall in the classic “Scrum but” pattern (you think you’re doing Scrum, but you actually aren’t). However, we would certainly benefit from their appliance and achieve a much better team sustainability. And this is yet another reason why you should read the Scrum guide anyway (it’s short and well presented), even if your project is trapped in a Waterfall management, even if no one would ever pronounce the word Agile in your team, it would still be worth a read.
