“No battle plan ever survives contact with the enemy” – Helmuth von Moltke, a 19th-century head of the Prussian army, as quoted in Donnybrook : The Battle of Bull Run, 1861.
The same goes for Project Management. Most projects fail as soon as they come in contact with something called ‘humans’. We humans are emotional creatures. The reason for failure isn’t necessarily a lack of ability or lack of will but mainly because of not planning the human element in to the plans. Let me rephrase: Does your Project plan include review or assurance of Psychological Safety, Dependability, Structure & clarity, Meaning of Work and Impact of work? These five aspects come out of a research project’s findings from Google about why some teams succeed while most fail. I’m sure that if you send me your Project Plan arguing that it includes “Structure & Clarity”, I’d reply back saying Yes and No. Just because it is included doesn’t necessarily mean that it is described effectively. And if the Business and Development teams use JIRA or any other bug tracking tool to carve out and manage hand off of work then you might need to re-think your workflows. Bug tracking tools can be the worst tool of choice because
- Requirements change continuously as work progresses
- Requirements may end up being found unreasonable if there’s no implementation path or if there is no appetite cost of such implementation
- Division or organization of work in to individual JIRA issues or stories is completely subjective and may not be straightforward when they are handed off to a different team (Say the Business teams divide the work in to JIRA issues and hand it off to Development and then they transfer it further to QA after DEV complete)
- Granularity of Division may also be very subjective. One developer might want to create a JIRA issue for every URL mapping (endpoint) of a REST Service plus separate while another developer might want to track everything related to the controller in just one.
- When filling a JIRA issue there’s a section for filling in Estimates. Treating these Estimates as SLAs or concrete expectations are a recipe for disaster. These estimates should be treated as guesses. If the work is not complete within the duration of the estimate it should not be counted against the assignee. These estimates should not be considered for evaluating performance.
- Bug tracking tools are good for tracking bugs and reporting but are not ideal for Project Management because you cannot account for the five aspects (outcomes of Project Aristotle discussed above).
- Semantic Diffusion: The team members are out of sync when it comes to their understanding or their philosophy towards Agile, Project Management and pretty much every aspect of Project management including but not limited to Estimation, Purpose of using JIRA for Software Development, Workflow of SDLC through JIRA.
How do the five aspects as laid out by Project Aristotle apply to usage of JIRA and Project Management in your team?
- Psychological safety: Can the individual team members debate or be allowed to openly question any aspect of the way JIRA is used in your team that does not make sense to them or is inefficient? Are team members encouraged to speak up during the planning or the Sprint review meetings?
- Dependability: Are the correct expectations of “What constitutes a quality deliverable” conveyed to the team members? Do the team members know that the team can count on him/her for the delivery with the quality expectations set by the team? Does the team have quality expectations? (Such as unit test coverage, Complexity requirements, Architecture guidance, collaboration help when dealing with complex problems or for brainstorming)
- Structure & clarity: Are goals, roles, and execution plans on our team clear for each team member for iteration or sprint?
- Meaning of work: Are we working on something that is personally important for each of us or are chunks of work randomly assigned to team members without rhyme or reason? What’s the formula that is used for carving up work and how do they help achieve this criterion?
- Impact of work: Do we fundamentally believe that the work we’re doing matters? Is anybody doing any analysis of how the work being performed in this integration is aligned with the Business? After all the entire goal of I.T is business alignment.
It’s time for your team to get together and have an open conversation about how well the tool you use for Project management is serving your needs.