Horse blinders
With the usage of Agile methodologies the big picture and vision of a product or service gets sliced in small parts to be developed incrementally.
As the slice is executed in a separated scope, sometimes by different teams/organizations than the other slices, this creates the product contraption. A collection of implementations based on different designs that sometimes don’t fit.
You can think about it as the eye pads for horses, with it the animal can only see in front of him, with a narrow vision.
Only focus on the current sprint or iteration affect both the understanding of a component design, by not considering all the space from left or right, neither learning for experience or preparing the design for the future; as you look to a timeline and you only see the current iteration or
Sprint and not seeing the left or right side of it.
Technical debt
This term in familiar for teams that work with a product and need to develop it and maintaining it. The technical debt occurs when a team decides only (or mostly) base on time/money factors and the quality is put behind. This happens quite often due the lack of empowerment of the architecture and design roles.
From other side, without knowing the “big picture” the development engineers fail to match the use cases, causing sometimes issues that are found too late in the development or operation pipeline.
So, there is a cause effect that is not taken in consideration, and sometimes is assumed that bugs are inevitable and the only cause of it are the software developers. Think about it!
Like all debt, it will have to be repaid, sooner or later.
Agile is here to stay
According to the 2019 state of agile report, 97% of the survey organizations practiced some kind of Agile development.
Yet more than half (53%) said that theirs process is still maturing.
To make the contraption a workable and maintainable system here are some tips for process improvement.
Keep it stupid simple
Avoid the contraption machine to kill a mouse
Use Sprint Zero
Pre-Sprint or requirement/business cases grooming is used to understand better the product, feature and its constrains before start to work on it.
Do a best first pass software design
Do not underestimate the power of a good design. Depending on the team setup this can be done during the sprint or iteration, have specific sprints to work only on design or have a dedicated team work on it involving always the development team for a good design handover.
Have good guidelines
To reduce the technical debts is important that the teams agree on frameworks, design patterns, common guidelines and defined best practices. Those items proper documented and evangelized to the teams are foundations for move away from the contraption machine.
Get Devs involved early
An under-rated but important tip (but your devs will appreciate it).
With agile dependent on speed, there’s every likelihood for architecture and design decisions to be made without dev input.
As the devs tackle your design approach, things can quickly grind to a halt,
impacting the project as a whole. Including your devs earlier in the design process lets them input into critical design decisions. It reduces risk and surprises, and lessens technical and design debt down the line.
Always zoom out
Zooming out sounds easy. Yet when someone is deep in the details it’s easy to forget, is important that within the team there is someone always aware of the big picture, trying to get and explain the context of the overall system or feature on the right time, that is fundamental for a better decision on the design.
Keep 10% + 10% time out of estimates
During effort estimation keep a percentage of the time
for fix your software design issues, those issues can occurs due to missing information on certain interfaces, miss communication or even improvements suggested during development.
Another amount of time is necessary for innovation. Reserve some time to investigation, research and try out of new technologies, methods and even your ideas that are in the backlog because you are only focus on the working items committed during the sprint planning.
A 10% for issues and 10% for innovation is ideal if a good build pipeline for issue root cause analysis is in place with the help of test automation to keep the issue fixing with low effort. This would mean that in ten days of work you would have one for bug fixing and one for innovation, while the remains eight would be for feature development.
A Post-Agile world
Analysts are seeing signs of organizations using part of Agile that work for them and discarding the rest, not considering the cases where the methodologies are adapted.
Taking a part of an Agile methodology, like work in sprints or having scum meetings is not wrong, the Agile Manifesto state “people over process”.
Agile is about mindset change and not process, the software engineering teams need to champion the software development best practices and involve/influence other teams and stakeholders on the Agile practice.
The teams need to focus less on “shipping”; instead create unified experiences that benefit the customers more than the internal processes.
At the end of the day, your customers, your users, the humans who interact with your product or service…
They don’t care how your product was made. They only want a great experience that lets them fulfil a task.
Don’t make your product fit into Agile.
Make Agile fit your product.
References
Avoiding Frankenstein By Jon Aizlewood
https://www.device42.com/blog/2019/05/infrastructure-technical-debt/
