In this article, part of my series explaining better ROI from software development, I conclude the story of Fiona and team removing dependencies.
Following the team workshops (see Part 1), and the 1st town hall meeting (see Part 2) - Fiona’s held a second town hall meeting. Fiona briefly recapped the plan again, and opened the floor for new questions.
A developer asked if the squads would include the representatives from the business. He had used Scrum in a previous organisation which had a full time business representative as the Product Owner.
Fiona said that unfortunately for the trial, this was being seen as a step to far. She certainly believed it was the right thing – but would likely be something they added later. First of all she wanted to prove the improvements within the IT structure.
The developer commented that he hoped that it would go that way. He shared that in his previous organisations that having that business representative within the squad had really helped. It had not just helped to get quick responses to questions, it had also helped the squad understand the business goals better – thus enabling them to contribute better to the overall direction. He said that he had felt much more motivated and a level of personal ownership over their system(s).
Fiona thanked him for his comments and made a note to invite him to further planning sessions.
A Business Analyst asked about documentation. She was aware that one of the recommendations from the lean consultant was reducing effort going into short lived documents.
Fiona jokingly apologised to the developers that documentation was still required.
Then addressing the BA; she went on. Documentation was still essential to the long term maintainability of the products. She firmly believed that.
The art came in getting the right balance.
She expected that within a squad, the documentation required to deliver a change would drop significantly. The squad would be communicating directly and collaborating over the solution – thus logically removing the need for a lot of the traditional team boundary documentation.
She did however still feel the need for relevant documentation to support the system as a whole.
She expected that each product have relevant and current documentation at all times to support the taking on of new staff. In extremes, this should allow an unfamiliar squad to pick the system up and understand it.
She expected the documentation to be living, breathing part of any change. To be updated in line with the actual software as part of normal procedure.
The documentation didn’t need to be exhaustive – but enough that a competent individual would be able to start investigating a problem or understand how to run the product.
One of the architects mentioned that they had previously used a template called Arc42 to do this. Arc42 provided a template for expressing the purpose and architecture of a software product – all the way from its purpose, to physical installation details.
Fiona thanked them for the input and made a note to ask the trial squad to take a look at it.
A Project Manager then asked what if there are still dependencies.
Fiona acknowledged that there wasn’t a 100% dependency free panacea – it simply wasn’t going to be practical.
While the aim of the changes was to reduce those dependencies – they would still crop up.
The task for all of them was to challenge those dependencies when they arose and identify if changes could/ should be made to handle in the future – to adapt the process.
Sometimes it wouldn’t be practical or worthwhile to make any change and the squads would have to handled them – as in the short term skills gaps.
The hope was that from reducing the dependencies that it became much easier to manage and handle the exceptions – being able to see the wood for the trees.
Where one squad finds they have dependencies on another squad (the core systems squad for example), then they should work to have a shared understanding of those dependencies. They should almost treat the relationship as a customer/ supplier. The “supplier” squad should be working with their “customer” squads to understand upcoming demands and plan as appropriately as possible. The “customer” squad should be thinking about the dependencies as early as possible to allow the supplier time to provide.
The Project Manager went on to then ask what would happen if there was more work on a product than a single squad could handle.
Fiona suggested it depended on if it was temporary spike in work or more permanent
If permanent, then they would either try to split the product down further based on the dependencies & rate of change rules or simply share the workload between the multiple squads. If the latter then there would need to be additional touch points between the squads to coordinate those changes. Fiona suggested something like Scrum of Scrums
If temporary, then the primary squad maybe split between additional teams to mentor them through that temporary period. With the primary team reforming again once the temporary spike was completed. With local knowledge baked into the new teams and quality documentation, she believed it would produce the best of a less than perfect situation.
As Fiona felt like that the meeting was coming to a natural conclusion. She wanted to close with some final words.
She admitted that she didn’t expect the road ahead to be smooth. This change would take work.
There would be problems that needed to be solved along the way. But she committed to provide the support required to resolve them.
She knew that every person in the organisation would take to the change different. Change could be very emotionally charged. Some people would thrive on it, some people would be revolted by it and some would simply not understand it.
She committed to provide support for everyone – be they enthusiasts that wanted more training, or be they people nervous for their future. There would be support provided at organisation, squad and individual level.
She concluded that that she fundamentally believed in the direction they were taking. A direction that would benefit everyone. She expressed that she was genuinely excited by the initiative.
She thanked everyone for attending.
And this is where we will leave the Acme Corporation. Maybe we’ll revisit their transition.
It certainly isn’t the end of the story for them. Rather the start of a journey …
“A journey of a thousand miles begins with a single step” Common saying that originated from a famous Chinese proverb.
Agile
Scrum
Spotify