Agile is about delivery, first and foremost. Scrum is an approach that is adopted as a delivery mechanism. Sometimes its easy to lose sight of that and get too involved in the ceremonies, sophistication and the maturity level teams are at.
I was asked to drop in and consult on a project that had just been kicked off.
- The work had been won very quickly and a new team had to be spun up.
- Individuals in the team didn’t know each other
- The team weren’t familiar with Scrum, it was their first time
- The project was fixed price
- The project terms stipulated it would deliver to aggressively tight deliverables
- The client were still attempting to elaborate out requirements
I sat in the initial Sprint Planning session:
- The technical lead had split the work up into logical chunks and estimated how long each would take
- The chunks of work were allocated to members of the team and they were asked to commit to the estimates which were pre-determined by the lead
- Some of the Stories were estimated at over 16 days
- Development of stories were assigned to Spint N, testing of them in Sprint N+1
- The PM stated that ‘Story Points were rubbish, everyone knew that’
- Poor Definition of Done e.g. Done was defined as developed but not QA’ed
- SM role assigned to a Dev Lead
This was what I termed a ‘Sprint Giving’ session
My head hurt – they had gone mini waterfall. I attempted to broach aspects of the above, but was rebuffed by the PM and Technical Lead who had been heavily invested in the initial bid.
I sensed that some of the more junior members of the team knew something was wrong. However they couldn’t articulate and push back as they didn’t have the knowledge or experience.
After some thought, I decided that it was better not to interfere. These are the reasons why:
- They had ridiculously tight deadlines which had been committed to
- There were no members of the team experienced with Scrum, so there were no advocates and internal sponsorship to push Scrum maturity forward
- The Tech Lead had taken strong project ownership and attempting to delegate out (this was good)
- They had very bright and capable team members
- To take the team out and teach them mature Scrum would have disrupted their flow and taken them away from ‘doing actual work’
I determined that this was the teams most effective way of working given their environment constraints. They were also doing productive work, putting in place the unpinning infrastructure from which the customer’s workflow model could be built upon.
It was also important to preserve relationships and harmony. Being a conflicting voice would have been disruptive, distracting and divisive to the team.
They were in the first stages of what I would term the Scrum Maturity model, very unstructured, ad-hoc and going through the ceremonies in name only. They would get it, but they needed more time – which they were in short supply of.
But generally – this was OK. I realised they were operating at the optimal effectiveness given their constraints, experience and knowledge. Sometimes there are environment constraints that make it FINE to be immature Scrum. This was a valuable revelation to me. As a coach I had learnt that this was OK and not to be too prissy about SCRUM.
I know quite a few agile purists that would have hit the roof. Agile is a means to an end, and that end point is client delivery.
As time and team knowledge progressed, the team did start to mature to a better Scrum way of working …. and then time ran out and the project ended.
Some projects – Fixed Cost, Fixed Period, Pre-determined aggressive deliverables, in-experienced teams will never be able to make it to a high Scrum maturity level. This is because of the environment constraints they operate in.
I was philosophical, I viewed this as the start of a much longer journey, where team members will disperse and take their learning onto new projects to the benefit of the wider industry.