Come Together
Experiences of Software Development Squad Makeup
No man is an island. It takes a village. Quotes are littered through our culture in support of working together. Be it in our personal or professional lives, we achieve more when we collaborate with others.
Much has been said on the importance of diverse teams. This includes diversification of personality and thought. Regarding role diversification, the traditional waterfall software development model encourages segregation of different functions that contribute to the development and maintenance of systems. It has always seemed like a strange model to me, that breeds division.
Our Agile journey has taken a further step forward in the combining of some key functions within the Agile squads. As with many experiments, this has produced mixed results. This week I reflect on our progress of integrating various roles into one particular squads, and set my sights on future inclusive goals.
Let’s Build a Home
Developers are the cornerstone of any Agile software development team. Without their coding skills, the products we built to support our clients would be but a distant dream. It is for that reason that Software Engineers and Scrum Masters have always been part of our squads.
Having them work as an isolated team has reaped rewards. In our early Agile adoption days, all teams were delivering working software at a constant pace. Coding and testing standards are on the rise. Morale was on the up as teams achieved a steady release rate.
This isolated model does introduce strategic challenges. The team were building strong client relationships and working across the divide to product features of value. Yet, these features became disjointed due to a lack of product ownership. Without direction from a single senior stakeholder, programmer only troops will struggle to understand the product strategy. This manifested itself for us in the delivery of features that didn’t quite hit the mark. These became the justification to push for our first addition to the squad.
Go Your Own Way
These experiences highlighted the need for an integrated Product Owner. Someone able to own the product direction. Many Agile frameworks, including Scrum, mandate that the Product Owner is always part of the squad. Yet in many organisations it proves to be difficult to sell the role. Despite practicing Scrum and Kanban for almost three years, it has only been this year that we have achieved the impossible dream of a truly dedicated Product Owner that gives true product direction.
Until this role is recognised as a legitimate and rewarding role, many other teams will fight the same battles. While awaiting someone exhibiting the desired attributes of a Product Owner, we made use of proxies. Said proxies are not nearly as effective, especially if using a Business Analyst or Product Owner in their place. I have encountered exceptions. However, the majority fail to meet expectations as they don;’t have a vested interest in the product. Instead or driving to a strategic direction, they conform to the age old man in the middle that can obfuscate the vision through indirection.
Level of engagement does indeed vary. Our greater commitment successes have had the Product Owner being present in the majority of ceremonies. Extending invites to standups and backlog reviews have proven to give better direction to developers. Yet if the reluctance is to be obliterated, it is more important to identify Product Owners available for questions if attendance to all ceremonies is not achievable.
Misery Business
Business Analysts have been a recent addition to a couple of our squads. This might sound odd as there is great differing opinions as to the value of BAs in Agile practice. Historically they have worked in isolation as either an information wall. Or as a compromising Product Owner Proxy in some of our later trials. This delegate approach proved fruitless for one crucial reason. They don’t necessarily care about the features being built. This is not intended to criticise their work. It is simply acknowledging how challenging it is to give accurate indications of priority, or answer process related questions when you have no vested interest in using the product itself.
The days of BAs writing large requirements documents are, thankfully, for the most part gone. Instead they support the Product Owner by assisting in the logging of stories and generation of behavioural acceptance criteria. That frees up our busy Product Owner to juggle prioritisation, product strategy and their day job.
This engagement is proving more effective than our prior proxy model. Teams still engaging in segregation are finding that requirements clarifications are less forthcoming. Furthermore, signoff of deliverables is far more elusive as the team quite often build features that don’t quite meet the intended requirement. This breeds the common misconception that Product Owners, or indeed other stakeholders, cannot reject features they consider to be unhelpful or unsatisfactory.
No Control
One group that proves to be elusive to integration is our Quality Assurance arm. While some squads have better success integrating dedicated testers, our model of automated testers and user testing means this is not required. QA for us is more around supporting of the products we build, and integration of tooling for diagnostics.
This lack of integration poses several challenges. The main is that developers have a distinct lack of empathy for those supporting applications. Documented details of the platform infrastructure are not provided. Design of the system support mechanisms such as alerting and logging are an afterthought. The optimistic nature of developers means we need expertise in those used to failure in building our systems.
The message that everyone is responsible for production support must be reinforced. Integrating a dedicated support agent looks to be a valid approach. Pressures on their time is the main blocker around integration. Especially when we balance support of our legacy systems that require more intervention. Global support by a co-located squad would also be difficult for one agent. The first step would be for assigning of an individual to to be available to guide developers in building supportable applications.
A Change is Gonna Come
Reflecting on our journey this far, the integrations achieved are reaping great benefits. Developers now receive feedback and clarifications on features more rapidly than before. Clients better understand the value they receive, and are empowered to prioritise the features they need, as well as understanding the reason for any hygiene the team performs.
That’s not to say that the adventure is over. Our QA engagement is another item of focus. The successes clearly can be scaled and replicated across our other sprint teams. That way we can ensure all groups come together.
