The pitfalls of Project Management - part 2

In the second part of the project management pitfall series we continue with some practical examples of how we can manage certain sensitive situations using some of the tried and tested methods. Read the first part of the of the project management pitfall series here.

The approaches or best practices suggested here are a funnel of several great minds in IT and project management, such as Frederick Brooks, James Coplien,  Robert C. Martin, Jeff Sutherland and the likes. This in no way is an exhaustive list of advice or the best possible approaches for any management predicament. As Mr. Brooks says in his later addition to the Mythical Man-month book: 

"There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."

The joint effort

A company is developing a product for which they know the business rules that are governing it. This product is the focus of the company, and they don’t have other ventures that bring back any financial return. They are looking to improve the overall user’s experience and client satisfaction by providing a “fresh” look and feel to their flagship application. The new approach is a joint venture between a development team from a contracting vendor implementing the solution following the Scrum framework and a product team from the client’s side with a Scrum Master, Product Owner, and QA Engineer for analyzing and defining product requirements, designs, and solution direction.

Solution: Putting the roles of Scrum Master, Product Owner, and QA Engineer on the client’s side gives an insight that the client wants a better control over the development effort, but the lack of an engineering team puts the pendulum towards business requirements and less towards technical feasibility. A strong consultation between the client’s team and the vendor’s team should be put in place to reduce this discrepancy. We can also argue that the Scrum Master needs to be from the vendor's side because the Scrum Master is dedicated to the team’s effort, thus a better chance to bond and perform is when they share the same “predicament”, and they can safely and openly communicate about impediments and work progress. We can also praise the approach here for the Scrum Master and Product Owner role to be given to two people. The Scrum Master role is focused on protecting the team and working for the team’s benefit, while the Product Owner role is in a way in a constant attack stance towards the team, demanding more work, faster delivery, and better quality for a lower price. These two roles are always in tension, and placing them both from a single reference point, i.e., the clients, can lead to lower satisfaction and performance by the team.

The inspection

Many code-inspecting platforms run through the application's codebase and return a rating. That rating is usually measured as the quality done on a static code analysis. However, there are even programs that go deeper and inspect the code complexity, fragility, rigidity, and immobility, defined as the package principles by Robert C. Martin in his book "Agile Software Development, Principles, Patterns, and Practices*". This is bad because it shows an antipattern called "code rot." It is bad if it is an in-house project, but it is a price to pay if it belongs to the client. Having a low-rating code means we are approaching a decline in productivity as we continue to increase the codebase because it slowly becomes unmanageable even for its original creators. And what about if it needs to move to another vendor? There is a limit to how tangled a code anybody will accept, and the inspection platforms warn us of the risk of taking ownership of such a spaghetti codebase. And experience shows that asking the Software Architect responsible for this mess to create documentation for the code will result in a continuous livelock situation – when (or even if!) the documentation is done, the code has grown again that it becomes even more entangled, or in a different way than the first time, so the documentation is useless.

Solution: Communicating low-quality code to a development team is always bad news. This means the team structure or members' experience is at a different level. Sometimes this review can break the team's spirit but appropriately done, it might lift it and motivate the team to try harder. The team needs to understand the specifics of the inspection to provide a better-quality product. A Project Manager who has a technical background can better translate this into actions. It is not only to communicate and leave it at that, but a plan must be prepared to tackle the feedback.

Communication is a delicate thing. First, a deeper understanding and analysis of the results needs to be done. This can be made in collaboration with the Team Lead to begin with, sharing this information with a limited audience until we can find the root cause of the problem. After a firm ground for the feedback has been established, meaning the feedback is adequately analyzed and all aspects of the low-quality code tackled, the feedback can be shared with the team. This way, it is not only demoralizing but provides encouragement that we as a team accept the problem and want to address it – collective ownership. We must motivate everyone to work harder and better, but only by example. We can explore several options on how to increase the quality. We can try the XP methodology. We can attend classes and certification paths; we can even start a book club, studying together and unearthing better approaches to higher standards and quality. Everyone can work towards the team's common goal, specializing in their area of expertise.

There is always one approach to hiring consultants, or even better, senior staff members for the team to work with and learn from if the budget allows. We need to communicate this to the client and explain the reasons behind the low-quality code. Perhaps, providing a larger buffer for the project could increase the quality. Communicating the team's needs transparently with the client, the results from the analysis, and a plan of action can result in a joint effort to achieve higher quality and improved trust – after all, we are together in this one. However, the best practice dictates that sticking with the current team and raising their knowledge and standards is better than starting from scratch. 

Starting a green field project does not guarantee results on the first try. It is a pattern called "The Second System Effect," stating that the first product has a lot of issues, and you try to solve every single one in the second product, making it so heavy and sluggish that it fails also. Only reaching the third attempt do you understand how to build the most streamlined product version–as Frederick Brooks argued in his timeless classic "The Mythical Man-Month*". But it remains to be seen such a thing, a client who can approve, finance, and wait for the third version. The sad truth is that if you put the original Tiger Team from the first product in any subsequent attempts, they will keep rebuilding the same thing repeatedly. That does not mean that the team should be disbanded entirely, but a fresh set of eyes with a higher experience can motivate the team and bring them higher satisfaction with the result.

The Handing Over

A project is being handed over by a Project Manager who is swamped with work and has accepted a temporary replacement role of a delivery manager for an ongoing effort. He can provide only limited information, that currently everything is okay with the project, except for some minor bumps, such as someone from the previous management team leaving the company a few weeks back, and currently, the scrum ceremonies and release planning are done by the development lead. Some people complain that the Scrum framework needs to be followed as before, and the meetings are leaking over the timebox due to the incomplete requirements in the backlog.

Solution: The handing over by the PM, who was responsible at the start, needed to be done correctly. A piece of good advice is for the new Project Manager to have a chance to see how the previous, even the temporary manager, works with the team, to "shadow" him or her for a while, to learn the spirit and the delivery cadence of the team and to better analyze their strong and weak points as a bystander. Knowledge transfer sessions should be separately scheduled between the two to transfer any business knowledge and detailed state of the project or product, which can be further explored in detail, on a need to base.

Since the previous manager, or we can deduce since it was the scrum that suffered the most, the Scrum Master left the company and was replaced by a technical person, having in mind that the technical team is from the vendor side, we can assume that at least a step in the right direction was held, i.e., to the common pressure for the client to take over the PM role was not yielded. However, working both as an implementer and a manager, one role will suffer, most often the less valued one from a subjective point of view, often the management role in this specific case, given the tendency for technical people to find satisfaction within the development effort. However, suppose the technical person is solely dedicated to the management role. In that case, this can be one of the best-case scenarios for the team since the manager can also understand the predicament of the development team better, escalate in the right direction to monitor, and manage the risk of any arising impediments having an insight into the implementation work.

Unfortunately, we don't have that luxury here. As expected, the management role needs more knowledge of agile methodologies, frameworks, and best practices. This should be communicated with the new delivery manager taking over, and it should be clear that if the technical person wishes to continue working as a Scrum Master, a better education on the role must happen. A first step would be to better equip the person to handle the Scrum theory by passing the PSM1 or even PSM2 certificate, thus obtaining proper base knowledge for the role. However, more is needed since covering the bases brings you only halfway there. Further interest in Scrum and the Agile world needs to be expressed by the person proactively, followed by engagement in self-studying in such areas as, i.e., release management, delivery management, roadmap elicitation, prioritization, etc.

To provide some ideas on how to attack the quality of the work done by the PO or the BA is to better specify a ticket following an industry standard for defining the stories, tasks, and bugs. A lot has been said on this topic; my personal choice is the BDD* (Behavioral Driven Development) using a short User Story description, followed by Gherkins scenarios or Use Cases, Acceptance Criteria or Tests, and a mockup or design proposal. To keep it complete, we should stick to satisfying the "Definition of Ready" defined by the team for when a ticket is considered finished in the specification phase and can be moved in "To Do" state beginning with implementation and moving on following the agreed "Definition of Done" by the team.

The Complaint

A team can be found in many operational states; the usual ones are forming, storming, norming, and performing. Each state has challenges, but most can be attributed to the storming phase. Here the team shows the "Five Dysfunctions of a Team*": Absence of trust, Fear of conflict, Lack of commitment, Avoidance of accountability, Inattention to results. Usually, the finger-pointing goes through the manager at this state, and they are generally addressed to the chain's weakest link. Most cases involve engineers working in isolation from the rest of the team, such as QA, DevOps, or to best blame a functionality on, the Frontend Engineer. Complaints can come in many forms, but they usually find their way as a written communique; hiding genuine emotions and breaking through the defense is more manageable.

Solution: The team's conclusion from the low quality of the product is focused on the work of the DevOps engineer. From personal experience, I have worked with excellent DevOps practices in place, such as those provided by the "Accelerate*" study. I've also worked with a great team with no DevOps practices. They did everything manually since that was the nature of the application, and placing DevOps would open unnecessary burdens to the team and prolong the deployment cycle even further. The first team, even though they had a perfect CI/CD in place, had a terrible throughput, while the second team yielded much more excellent results faster. DevOps is not a silver bullet, as argued in the book. Good research has to be done on whether DevOps or, more recently found as CloudOps is a way to go in a specific case, ex. Do we plan to develop and maintain this product for a more extended period (is it an engineering effort?), or do we plan to try out an idea as an MVP that we can perhaps include a CI/CD/CD pipeline (a programming effort?). For more information about the difference between software engineering against coding or programming, read the first chapter of "Software Engineering at Google*." 

Sometimes the client can provide feedback about what they see as a possible root cause of a problem. Usually, they give this feedback through an email without any prior investigation, and it shouldn't be acted on immediately. First, we need to further address this on a call as a better approach in this situation, if possible, to get a better insight and more information on why this is their conclusion. Let's say that they usually see the result of an effort and jump the gun that it has yet to be implemented as expected, so the logical conclusion is that the frontend has not been according to specification. This conclusion that the Frontend Developer is the chief problem can be challenged. How did they reach this conclusion? Who reviewed the Frontend Developer's work? Are they unsatisfied with the UX design instead of the frontend work? Who provided this information and why? We need crucial information that can dictate the course of action. We need to find the root cause of the problem, taking every branch to its origin; perhaps this will lead back to a conclusion that it was wrongly specified or there were many ambiguities at the start that were not addressed, so the team did the best they could, given what they knew.

Assuming that the client is correct, and we should always investigate this option no matter how we feel about it, we should schedule a call with the FE developer to see if this is the case and inspect the things where they are pointed at. We should also talk with the Team Lead before the call and perhaps one or two of the FE developers' peers to collect more background information from several sources, so they are not biased. We should also consult the QA Engineer who has been testing out his work in the past and collect their insight.

Finding that the accusation is correct, we need to plan our next course of action – communicate this with the Frontend Developer face to face, carefully, and try to find out the cause. Perhaps there is some lack of knowledge, or perhaps there are some problems of personal nature. Maybe they did not find their proper place in the team, or their work is not appreciated. Anyhow, seeing that we can't solve the problem immediately, i.e., the quality of the frontend can't be improved, we can try to look for another Frontend Developer with a better experience as an addition to the team or as a mentor. This should also be communicated with the current Frontend Developer for openness and fairness, and transparency is the chief pillar of Agile, so they will know their options. Perhaps having a second Frontend Developer in the team can motivate the current one to provide higher quality, thus keeping both developers, if not in the same team, perhaps in the same company.

A similar approach can be taken for the DevOps work. Also, throwing away work should never be our first option. However, if the work of the DevOps Engineer is causing more harm than good, building on the existing work can slow things down even further. If no knowledge of how to improve the work of the DevOps Engineer is present, there are, again, several options on how to proceed. Maybe external consultancy can be used in addition to better educating the engineer on proper techniques and practices or to "patch things up" for the time being. However, a short-term solution to work without DevOps practices will significantly reduce the team's deliverability. Hiring a more experienced engineer in this position or a DevOps team lead can increase the quality of these roles for all teams and put higher standards and solutions into practice for long-term benefit. But we should be mindful of Brooks's law: "Adding manpower to a late software project makes it later."

[1*]https://www.goodreads.com/book/show/84985.Agile_Software_Development_Principles_Patterns_and_Practices

[2*] https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_second-system_effect

[3*] https://en.wikipedia.org/wiki/Behavior-driven_development

[4*] https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Team

[5*] https://en.wikipedia.org/wiki/Accelerate_(book)

[6*] https://abseil.io/resources/swe-book/html/ch01.html

About the author

Borjan Petreski is a Service Delivery Manager working in the technology center in Skopje.

Borjan is a versatile Service Delivery Manager and Scrum Master who has experience working within different agile frameworks, such as Scrum, Kanban, or "Scrumfall." Borjan managed multiple projects and products simultaneously with stakeholders and SMEs from various fields.