A recent survey on the state of Agile development cites "Lack of experience with Agile methods, Company philosophy or culture at odds with core Agile values" and "Lack of Management support" as the top three leading causes of a failed Agile project. This led me to think, "What is the definition of a failed project?" A dissatisfied customer or a team? A failed product? A project that goes over budget? A schedule overrun project? Or a combination of any of these factors?
Not delivering valuable, high-quality working software at regular intervals certainly leads to a dissatisfied customer, and for me this is one of the most apt definitions of a failed project. Does a project fail overnight? Certainly not. There are certain symptoms that one can pinpoint when a team is struggling to deliver on its commitment. It is possible to control further damage if these symptoms are identified early and acted on in a timely manner. Following are the most visible symptoms that I come across.
Monotonous Daily Scrums and sprint retrospectives
I stress these two Scrum events especially, because I see teams losing steam when they participate in them. The main reason is that, over time, these events become monotonous; teams are simply following a ritual by attending. This feeling could be attributed to the events' structure, in which case the team and ScrumMaster need to review and understand the real purpose and expected outcome of these meetings. The Daily Scrum is not a status meeting but a tactical
meeting for planning the day. Scrum retrospectives are not meant only for identifying good and bad but for proposing an action plan for continuous improvement. Teams should be innovative in the manner in which they conduct retrospectives so that they are fun and not monotonous.
Many teams suffer from electronic tools syndrome. For them, adoption of some electronic tool is as good as adoption of Scrum. Such teams try to fit the Scrum process within the boundaries of the tool. The discussion revolves more around how to use the tool than on improving the process. Processes and tools take precedence over individuals and interactions.
Precious time is lost in this process. Better to first start with a paper-and-pen approach before getting overwhelmed by a discussion of tools.
Micromanagement by chicken roles
However much you want to deny it, micromanagement exists -- just maybe under a different guise. In spite of best efforts to educate leadership and senior-middle management about trust and transparency, micromanagement can still exist when teams have additional roles -- like project manager or PMO or a directive ScrumMaster. Many teams end up with a project manager donning the ScrumMaster hat. The name of the role has changed, but what has not changed is the mindset, from command and control to servant leadership. Micromanagement continues when:
- The ScrumMaster allocates work during sprint planning meetings.
- The ScrumMaster decides who will talk when during Daily Scrums.
- The ScrumMaster handles the software demos in sprint reviews.
- The ScrumMaster discourages team members from expressing their opinions freely by arguing their points during sprint retrospection.
To overcome such behavior, a set of organization-wide change initiatives need to be taken up across hierarchies and verticals, which will promote Scrum values.
Initiatives for change
Find a visible product owner
Catching hold of (a busy) product owner is a task in itself for Scrum teams. The PO spends a lot of time working with different stakeholders/customers/end users, but it should not be forgotten that she is also one of the important roles on a Scrum team. If the PO seldom attends sprint meetings, then it's a sure sign of a project leaning toward failure. The product owner should be reminded of her responsibilities if the team has to groom the product backlog, write user stories, resolve queries among themselves, cancel/postpone the demo due to nonavailability, etc. An unavailable PO is a big problem for many Scrum teams. Consider identifying a proxy product owner if that can resolve the problem in your organization, at least to a certain extent.
Contain rising technical debt
It is not uncommon to see Scrum teams struggling to achieve their sprint goals. The focus is on delivering working software, and sometimes that means compromising on quality or achieving the goal at the cost of quality. In due course of time, the source code takes monstrous shape and becomes unmanageable. The tests become fragile and unreliable, and defect fixing becomes a pain. If rising tech debt is not contained in good time, teams will come across a dissatisfied customer sooner than expected due to poor quality. Whether to wait for a perfect situation to address this issue or plan for it every sprint is up to the team.
You will have seen many similar and other symptoms of a struggling project. I would be happy to hear from you and to learn how you overcame those symptoms.