At the end of the first Program Increment, people felt a bit disillusioned with the volume of outcome generated by the ART. An ART is a rather large amount of people, so the hope was that there would be a rather large amount of "Done Product". This wasn't the case.
Some developers were complaining that they couldn't get anything done because they were "spending too much time in meetings".
Hence, I investigated.
ART delivery surveyWe asked ART members in a quick survey to categorize their working day into four categories:
- Time unavailable for the ART (i.e. doing "legacy structured work" or "working on other ARTs")
- Time spent in SAFe/Scrum meetings, such as Planning, Daily Scrum, Reviews, Retrospectives
- Time spent on daily chores, such as Maintenance & Support etc.
- Time spent actually working to deliver Features
Here is what I got:
This anonymized data represents the situation of an ART launched by an organization which simply didn't have the choice to 100% commit all ART members before getting going.
ART delivery capabilityThere were some interesting findings:
- Capacity: The "real capacity" of the ART was significantly smaller than the "presumed capacity" due to part-time ART membership. Statistically, one in five participants of the PI Planning was an uninvolved spectator.
- Meetings: The amount of time spent in SAFe meetings was very proportionate at 15%. This, however, became an issue was a 10% committed member of the ART spent all of their available time in meetings.
- Chores: In a Devops production environment with legacy processes, there's a significant capacity drain caused by daily business. Nobody had this on the radar until we surveyed it.
- Features: The total delivery capability was not much higher than a few dedicated development teams - everyone else was busy, but not with getting new features out of the door! The results delivered by the teams were the logical conclusion of the setup.
ART member overburdenWhen we took a closer look at the feature delivery time of individuals, here is what we found:
Yes, this was a shock! A few unfortunate individuals had to consistently do overtime just to keep up with the ART - and that wasn't even about getting feature related work done.
So to say, some people got steamrolled below the (Agile Release) Train. I guess you could sympathize with these people when they say they'd rather not work in the ART - yet they enjoyed the working mode. They just felt the workload was crushing!
Also, the average ART member was barely spending a quarter of their time on feature delivery, so even a room full of developers wasn't getting much more done than than a single powerful delivery team.
On a positive note, dedicated fulltime ART members were able to spend nearly 80% of productive quality time to get features delivered, so we had the proof that the root cause of the problem was neither SAFe nor the ART, but peoples' part time availability.
Size mattersAs a coutnermeasure, individuals had to choose either to be 100% on the ART or to go 100% into another ART. Even though some people had their technical expertise home in multiple ARTs, the mix construct just didn't work out in their favour.
It's better both for the organization and the individuals to move towards 100% ART membership and be in one stable, dedicated team.
This has implications on the size of the ART.
An ART with 100 members of whom a great portion is less than 100% committed will be bigger than a dedicated ART would need to be. This additional size requires additional communication, adding additional coordination. All of this increases effort, risk and cost while reducing productivity.
Not to mention finding a sufficiently big PI Planning room and overnight accommodation becomes increasingly challenging with increasing ART size.
ConclusionFrom an economic point of view, I hence coined the phrase: "Better 1 dedicated than 3 uncommitted ART members".
And I feel that the human aspect conveys the same message: Better focus on one thing you're good at than constantly jump between construction sites.
It's important for leadership to commit on a Priority 1 for their people, because the cost of indecision may be the entire productivity those people have to offer!