The 5 Biggest Team Delusions
Over the years, there are a number of statements that I hear that make me step back for a moment. Some are relatively new, some have been around as long as I can remember, but every one of these, in my experience, usually means something very different (and less effective) than what the words might indicate. I’m sure there are more, but this is a start.
“We have a solid plan” usually means that someone has captured a bunch of events and put them in the form of a well-structured Gantt Chart, or a burndown list and velocity chart. It rarely shows a feasible approach for the team to work together to effectively deliver the product, and as it is usually built and owned by one person (often called the project manager), it is highly unlikely that the rest of the team believes in is plan, and even less likely that it will serve as a useful tool to help the team understand where they really are. Listen more for “We have all worked out what we believe to be the best approach for collaborating to complete the project, and have captured our understanding here.”
“We’re Agile” usually means that the team has adopted some or all of the practices that have worked for someone else on some other project, and have adopted them without consideration of whether they are relevant for the current project. Despite the intent, these teams often settle on a single methodology, sometimes brand their business as being grounded on this methodology. There is a belief that this hammer is omnipotent, and therefore every project is a nail to be dealt with accordingly. Look for a different flavour of agility that sounds like “We have considered all our stakeholders’ cultures, the nature of the product, the competencies of the team and the constraints on the project, and consciously determined that this approach will best serve everyone’s needs.”
“We’ll deliver on time” often means that we hope that everything will go our way (including a miracle or two), or we will ship on that date (but we can’t guarantee what we will ship), or sure, if that is what you want to hear to get off my case. Even with a strong collaborative story of how things will play out, many projects fail to go the next step and credibly understand how long it will take to do the work, and the depth of uncertainty in those durations. Historical databases are almost non-existant, and the best recollection is based on the last guess that was made and is horribly optimistic. For projects that don’t have any real data from the past, timelines are often built by compressing all the work into the time constraints that were provided, then coding like hell. Seek out “based on our past performance of similar work, and given the uncertainty and known risks in this project, we can say with this confidence level that we can get the project done in this timeframe.”
“The code is the documentation” usually means that our entire life is spent looking at the IDE and debugger, and there are no remnants of anything that would resemble analysis or design that we thought would be worth keeping. Often, this is because technical teams are built based on expertise in coding or scripting. As was noted recently in a blog online, “The code is the imperfect translation into a programming language of the programmer’s imperfect understanding about what the program should do.” Look carefully for “this code traces back and manifests the design principles and client needs that we have carefully analyzed and captured”.
“We’re focused on Quality Assurance” usually means that at some point in the project, emphasis is on testing the defects out of the product, hopefully before it ships. There is a distinction to be made between Assurance and Control, and end-product testing (and the planning of this testing) is a control activity. Real quality assurance has to do with making sure that the system is in place that will help us make sure that these defects don’t get into the system to begin with, or that they are discovered far earlier in the lifecycle. QA is about deciding how to build the product, not how to test the results. Look for…well, look for the responses I suggested for the previous four delusions, as well as a strategy to confirm that you built what you intended to.
How many delusions is your team running with? Are there others you can think of? – JB
Comments
Feel free to leave a comment...
Clarrus Proudly Sponsors VanQ
