The Agile Activist cannot see beyond their chosen framework whether that be SCRUM or something else. They will talk about delivering business value but they only really care about the rate of delivery. For them it’s about JDFI rather than quality.
These people are easy to spot, just suggest improving the non-functionality characteristics of the system
Me: We need to invest time building in this logging framework so the solution can be monitored better in production
Agile Activist (AA): That is not business value
Me: We need to understand security protocol X for when we integrate with system
AA: We can do without security
Me: We should implement patterns that create a loosely coupled components and minimise dependencies on external systems
AA: That sounds like up front design. Just get the two project teams in a room and we will sort it out.
On paper these exchanges look crazy but they happen. The justification is that the project is ticking off high level business features and hitting all the key milestones. The downside is that technical debt is mounting up which is causing team velocity to flatline or even slow down.
Craftsman use their experience to deal with the task at hand. A carpenter will use power tools when manipulating large panels of wood but they will use small and light hand tools for detailed work.
Software engineers must be allowed to build secure software that is easy to manage and is independently releasable. This provides value as much as any new business feature does.
— oOo —
When organisations are transitioning to Agile, Product Owners come in many shapes and sizes. Some will be open minded to Agile ways, others, Project Manager POs, will have one foot in the old ways, the command and control ways, the time and budget micromanagement ways.
In SCRUM, Product Owners are authoritative. They have the position and stature to make decisions and arbitrate disputes. However, they don’t know everything and should rely on their team in many situations, particularly when a technical decision needs to be made or a complex arguments needs resolving. It is question of shared ownership and trust throughout the team.
Project Manager POs often reach for the old ways of costs and scope control without understanding the implications. The complexity resulting from a technical discussion flies over their heads and they select the option that looks the cheapest, or does not expand the projects scope or looks like it will be delivered on schedule. Sometimes they simply make the decision that makes the problem go away.
Hopefully you’ll be on a strong team and can support your PO in these decisions. If you’re not then let’s hope those decisions don’t come back to bite you, the project or the organisations you are working for.
— oOo —
It is possible for someone with little technical experience to find themselves in senior technical roles. This may be due to the Peter Principle or they simply may have been around at the same company on the same project for a long time. Once these Institutionalised Technical Leads are taken out of their comfort zone either by working on a new project or the project they have always worked on being ported to a new technology stack, they are exposed.
The currency of Institutionalised Technical Leads is experience and knowledge of their domain. In the past they always knew more than newer members of the project team and often use that to their advantage. Often Institutionalised Technical Leads are good in a crisis; they are excellent fire fighters. When dropped into a new project, or a new business domain or asking them to use new technology resets the levels across the team.
When presented with a new way of doing something, that may be well understood in the industry, their confirmation bias tells them that the work or method they are hearing is overkill and unnecessary. It sounds complex to them but it is simple to the person doing the explaining.
- I don’t need REST and JSON. SOAP and XML does everything we need.
- Why do we need messaging when I can simply have all of my code share a common database schema?
- Implementing SRP by creating many classes is much more complex than sticking all the logic in one class? One thing is simpler that 100s of things, right?
I have worked with Institutionalised Technical Leads like this many times in the past. They can cause disruption in a couple of key ways.
One way they have impacted projects has been through their general resistance to anything “different”. This results in moaning and complaining that can have negative impact on team moral. An alternative manifestation of Institutionalised Technical Leads are long sessions where relatively well known patterns have to be described and justified in detail whilst they are deconstructed and challenged.
The latter manifestation can be very damaging. Not only does it suck up a lot of time, it also creates a perception that the team are not aligned which often reduces the confidence of key stakeholders.
Don’t get me wrong, buy in is important but it works both ways. It is important to point Institutionalised Technical Leads to examples of how modern software is built but it is also their responsibility as software professionals to keep up to speed with what is happening in their chosen trade by understanding the pros and cons of the various way software is designed.