Company B: A very traditional organization, this team has with a history of working in waterfall models – a Project Manager (PM), 2 testers, and 4 developers – with PM acting as the de-facto team lead.
The team was confused why it was receiving largely negative reviews on the product from the users. It maintained strict release criteria – prohibited anything to be released until the artifacts match 100% of the test and quality criteria. Not surprisingly, the team had a very long release cycle and gathered a large backlog.
As a last-ditch effort, it decided to move to an agile development process, but most of the team members do not have much experience. The team recruited agile consultants and tried to embark on the agile way because that is the “fad.”
So, the team invented a hybrid model of working combining the features of both Scrum and waterfall. It conducts daily stand-ups, arranges weekly status meetings (“project review” event, as it portrays), and often engages in discussions where productivity could be improved. However, even after a few months of run, the backlog still grows. And worse, the team sees people leaving the organization.
What happened here? The team is trying to emulate the scrum events, but not in a careful way. Too many customizations effectively were ruining the team’s progress. Here’s what it could do:
- define a fixed-length iteration and slice the larger stories into manageable (typically within a sprint) chunks.
- employ a Product Owner, who can create a product roadmap out of the lengthy project contract. For some time, the PM, if she is knowledgeable about the product could serve as a PO.
- divide the roadmap into smaller milestones and fasten releases around them. With more frequent release cycles, the customers could actually test what the product offers and suggest improvements (Big-bang vs frequent release(2)).
- stop resisting the agile transformations.
A Caution Point
This is not to mean that the waterfall model does not work; in the past, it showed varying levels of success in many projects, especially with requirement well-documented, technology well-understood, resources available, and product definition stable(3). The point is, if a team decides to go agile for whatever reasons (there are plenty(4)!), it should not drag past misfit elements in the new beginning.