Project Management: Right tool for the right Job

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?

  1. 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?
  2. 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)
  3. Structure & clarity: Are goals, roles, and execution plans on our team clear for each team member for iteration or sprint?
  4. 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?
  5. 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.

Documentation and Code samples of Open Source Projects should include Automated Tests

Let’s first take a quick detour:

The Software Engineering field thrives on Open Source Projects that is built for and by the people who are part of the community. This is a feature that is unique to the Software Engineering field and not quite common in other Creative or Science streams like Aeronautics or Biology etc. You do not see Open Source prototypes of Airplanes do you? May be because Software innately is Virtual and it makes it easy to duplicate and share. This ecosystem of constantly hitting a wall in some sphere of technology, coming up with revolutionary ideas to solve that problem and sharing that knowledge with the community is just beautiful. I’ve personally gained a lot of inspiration from projects like the Spring Framework, Angular etc. and myriad of cutting edge technologies that are constantly churned out by the Apache Software Foundation (ASF).

Back to the topic on hand:

Take a look at this Tutorial from, the official home page of the popular Angular Framework. I’ve been closely following the evolution of the Angular Framework as well as how their documentation has also evolved in the past few years to its current state.

As you can see the above tutorial does a bang up job walking a reader through a small project to introduce core fundamentals of Angular. The tutorial is augmented by a Live Example. The live Example running on Plunkr shows the source code and its fantastic expect for the fact that there are no test cases bundled with it.

It’s the same deal with the Spring Framework and myriad of other Open Source projects.

Here’s why live examples and code documentation must be bundled with test cases

  • To emphasize to the reader the value of writing automated tests
  • To “teach” the habit of writing test cases: Demonstrate the various ways the Code Sample can be tested. After all the goal of such source code is to help the reader borrow the ideas and implement them in their own projects. Showing well written test cases teaches the reader to write tests in their own implementations.
  • To verify your own work! The code sample itself needs to be tested. Do you really have to manually verify that your code works instead of using automated test cases to do the verification and validation?

I hope that Open Source projects seriously consider revising their approach towards their documentation and incorporate well written Automated tests in their Code Samples and wherever it makes sense. (Unit, Integration and others as appropriate)

The online HTML editor now supports the use of an external CSS file to be applied to format the content of the visual preview of your document.