Project management seems pretty straightforward on paper. However, real-life throws you curveballs that to dodge or adapt. The following are some of the most common problems I get asked to solve.
My Teams Estimations Are Always Off!
This problem is very common, and it is being faced by most teams when they are adopting a new methodology. It usually takes a few sprints before your team gets a better grasp and estimating. There are many technics you may utilize to reduce your margin of error and estimate quicker; one of these techniques is called Estimation Poker.
Estimation Poker is a simple exercise that doesn't need any fancy software. Though, there are many online. The process is as follows:
Describe the epic or the story, and what you are costing out
Ask all your team members to estimate how long it would take to develop this feature
All estimates are written down silently on a piece of paper.
Then on the count of 3, the all reveal their estimations. It's important that this happens all at the same time so that one estimation doesn't influence another.
Take the highest and lowest estimations and have them justified. Remember, there are ego's involved that will work to your advantage.
If one number is justified then you take it. If not, then you split the difference and move on. Remember these are only estimates.
Estimation Poker is the perfect methodology to be used when dealing with your developers, and this will allow you to get the most honest estimations with the least margin of error.
The Golden Ratio: The Fibonacci sequence
Another technique you can use is the Fibonacci sequence for estimating hours; I believe using hours is better for projects because it minimizes your margin of error. The Fibonacci scale is also known as the Golden Ratio 1,2,3,5,8,13...etc; this is adding the first two numbers 1 + 2 is 3, 2 + 3 is 5, 5+8 is 13 and so on. What you need to do is to have them estimated using the Fibonacci Sequence since it implies exponential complexity and variability with the size of the task. I never let my team estimate over 13 hours for a single task since the margin of error becomes unmanageable. If they need more time then have them break up the task to multiple smaller tasks. For new teams, I limit them to 8 hours.
I have a Team Member that is Chronically Late
If you have a developer who is constantly late, constantly procrastinating and has difficulty catching up. The first thing I would investigate would be your daily standup meetings. If the project manager is holding daily standups and holding everyone accountable daily, the accrued debt should be minimal. If the project manager if sending out a performance report every Friday with a hard correction by Monday (ie all debts need to be paid off by Monday). Then your risk should be manageable. See how to get the most out of your daily standups here https://www.cogentstep.com/post/how-to-run-your-daily-standups-effectivly
If your developer is lying and putting up fake progress numbers. That will end quickly and here is how. If there is a task that is estimated at 8 hours. If they want to show progress, they will then burn 50% of it on day one. Then by day two they need to show additional progress so they need to show a 90-100% completion. This is where you call their bluff and ask them to demo. YOu may get an objection that they need to clean up the feature a bit or some lame excuse. Insist on them demoing, even have them demo in front of the team. Even if you can't tell the difference the team can. This will put an immediate stop to fake progress. While, I am all for building the team to be the best they can be, malicious intent I have very little tolerance for.
I Feel my Developers are Lazy
Generally speaking, developers aren't necessarily lazy. They don't like to be burnt out, and there's a lot of environments where expectations are just not reasonable. For example, there is always some urgent work on Friday that needs to be completed by Monday. This is just a toxic environment, and you don't want to burn out your team. Just think of it this way, would you like to work for you? Ask yourself how you are influencing your team's environment. Are you creating robots or as problem solvers? Most people tend to deal with developers as robots, "Just do what you be are told" mentality. That is bad in two ways. The first, is if they aren't robots yet, you are now making them that way. Never challenging any thought presented to them. Secondly, they become disconnected from the project. It becomes a job where you are just doing enough not to get fired. An indicator of this is if you hear comments like "I just did what you told me to do", which alleviates any sense of responsibility or ownership. What you need to do is have them join in on finding solutions and owning the product together.
Tell them What, not How
Software engineers are problem solvers by nature. They spend time-solving puzzles for fun. So when you present them with a solution they're first instinct is poking holes in it. Which is useful, but can be frustrating over time. Another approach if ask them to solve the problem. In this scenario, the burned and responsibility has been put on the engineer to solve and is not a challenge. All this takes is a slight change in how you word your statements. For example, "I think we can increase the conversion rate on our product by...", versus "How do you think we can improve conversion rates?", then tack on your suggestions.
When you have your daily stand-ups, make sure everyone is paying attention. When a team member reports progress amongst their peers, the team knows if that progress is good, bad or bogus. Each team member has an ego and no one likes to be the bottom performer. So make sure your standups are done in a round table fashion where all are participating and not just waiting their turn. For example, if developer A is explaining how difficult and complex his/her problem is and you have no idea if it's true or not. Ask developer B for his/her opinion and if they have a simpler way to go about it. As you watch the back and forth as a spectator you can see who prevails. Remember, I don't need to know how to box to watch a fight and see who one.
Priorities Keep Changing
This is common in younger companies. If you are managing the team, you could be part of the problem. The infamous "idea's guy" who calls the shots, has fantastic ideas constantly popping into their head and wants to start acting on them while the idea is fresh. IF the next idea comes along before the first finishes, then you're never going to get anything done. You need to make sure that you're not part of that problem.
If you're managing a team for a larger company where you need to make sure have full buy-in by the management team on the new process. Explain the process of Agile development, and how it can help you reach optimal output. They need to follow the process. You need to remind them of that. See more about Agile development here https://www.youtube.com/watch?v=H4GsJkboqvs
Another consideration is, maybe your Sprint is too long. if you have a four-week Sprint, and they just can't bite your tongue for four weeks. Make it three weeks, two weeks or even one week if you are ready for it. Bring it down to a manageable length to have the stakeholders commit willingly to commit. if I'm at a two-week sprint. That means the stakeholders; on average; only need to wait one week until the next sprint begins. You need to be okay telling people "no" or at least "not now".
Always Explain the Cost in a way They Understand
Make sure when you present the cost to someone, anyone really personal or professional. Make sure the cost is weighted by their pain, and not yours. For example, your boss wants you to work extra days on a project which will make it extend a week. One way of repeating the request back to them is "So, you're going to make me work these extra days to make sure it gets done?". Another way of saying the same thing is "So, you're ok spending another weeks' worth of salary for me and my team to get your feature done, right?". The first method made it about your pain, while the second made it about your boss's pain. Which do you think will sink in more?
Always Give and Take
Let's say a feature needs to be squeezed into your current sprint. Make sure one of two things happens. EIther, you extend the sprint or some task, story or epic needs to fall off the sprint and get pushed to the next. Send out an email to all the stakeholders informing everyone that manager X requested a new feature to be added in and will cause the sprint to be delayed by a few days. If an argument ensues then its between the managers and not you.
Production Support is Too Big and is Getting Bigger
In essence, this happens because you accrue technical debt. Small loose ends, bugs and sloppy code that never got fixed. A quick recap, production support is a portion of your sprint that your team allocates for anticipated, unanticipated items coming from the production system. It is unknown what issue may arise, but anticipating that something somewhere will. Failing to anticipate these loose ends will cause your sprint to not meet their deadlines. Allocation of 15 to 20% (no more) of the sprints resources reserve buckets of hours for production support. If and when a bug is reported in production, your team has reserves to fix it.
Sometimes you get too many issues that are reported. Fires left, and right. Servers are going down. Whatever it is. You have your development team always in a scramble, and they're reactive and not proactive. If you see that you're exceeding 15-20% regularly, what you need to do is just stop the sprint and dedicate a new sprint to only paying down technical debt your debt. No new features. You just make sure whatever backlog of debt that you have is being aggressively tended to. You make sure you pay down enough of it until you have a healthy state again. Once you have a healthy state still, you can go back to your backlog and start dealing with all the new features that are coming in. If you don't do that, you're just building on a weak foundation. This should reduce churn and increase customer satisfaction. Especially when they are customer-reported bugs.
I try to allocate my resources correctly. However, it always seems to be unbalanced. When assigning a particular sprint like a 3-week spread, out to your developers, QA, and designers. You may find that your developers are always fully engaged and your QA or designers are under-booked. At a certain point, if your team is so small, the ratios between developers and QA will be off-balanced; This is just a rule of thumb, 20 to 25% should be QA 22 to 25% should be for design. Thus, for every 4-5 developers, you should have 1 QA, and that should be a healthy ratio. If you have fewer developers, you may want to consider a part-time QA and design resources. If your ratios are not as mentioned above, your developers may not be producing good enough code quality. Forcing QA to repeat their testing cycles over and over again.
Now, let's assume that you have a QA team-member at the beginning of a sprint not burning enough hours as projected. Saying something like "I'm waiting for the developers to give you something to test". There's a lot of preparation that happens before functionally testing these new features, and what you want to consider is having your QA act more like a BA (Business Analyst) at the beginning of the sprint, writing specs and how-to test documents for the following sprint.
Make sure your developers have something to deliver weekly to QA, so that some developers who have ten different items, just incrementally work on each item and complete them all the last few days of the sprint. That doesn't work. We need to make sure that you portion out and modulate the code, make sure that you develop one segment give that to QA while the developer works on the next task. The QA will provide some feedback from the developer to fix prior to the end of the sprint. The QA resource will still need to run one last sweep of the entire project to make sure nothing regressed. Same thing for the designers, designers once they are given features to design. Generally, the designers are a sprint ahead. However, designers should be part of the QA process of the current sprint. Ensuring their designs given to the developer are actually implemented correctly.