How can you manage unexpected issues when meeting software engineering deadlines?

One more important point in terms of communication related to deadlines is communicating often and communicating early. Software projects by nature are complex and more often than not, one is bound to discover something they didn't anticipate or plan for while in the course of development. The best strategy here is to communicate clearly and keep the stakeholders in the loop always. No one likes to find on the launch day that a project is far from ready or has that "one tiny issue".

In today's world of geographically distributred teams working in multiple timezones, key to executing successful software development projects is to stay coordinated and synchronized through timely communication. On one hand distributed teams allow the project to get benefited with diverse skill sets, at the same time the added overhead resulting from keeping teams coordinated is significant and must be accounted for.

- Sometimes teams can think out of the box and be innovative to find quicker solution to the problem in order to deliver the project on time. So there might be a solution before thinking of giving up - In some circumstances, when it doesn’t sacrifice product quality, user experience, and business outcome, team can take calculated risk and consider technical debt to speed up delivery, specially whenever there is critical deadlines and constraints for delivery time.

Executives need to make sure they’ve created a space where it’s psychologically safe. Communication is a broad term. You need the right communication for the right audience at the right time. And you need folks to know they can challenge, push back, and raise questions

Prioritizing and transparent communication are linchpins in managing unexpected issues. Assessing impact and urgency allows for strategic responses, preventing project derailment. Regular, clear communication with stakeholders ensures shared understanding, mitigating conflicts and aligning efforts with project goals. It's a proactive approach to navigate challenges and uphold project integrity.

I would try to break the project into "thin vertical slices". This will allow us to: 1. Identify issues earlier than at the end when integrating the different layers. 2. Realise value earlier for some projects. 3. Surface unknowns and manage risks. 4. Getting stakeholder approvals earlier and allowing us to manage scope creep. 5. Able to perform incremental releases.

Usar métodos ágeis por si só n?o garante nada, na minha opini?o, existe aí também um trabalho de conhecimento sobre as técnicas e métodos e a ado??o de forma correta, por exemplo, usar o Scrum mas banalizar suas práticas n?o resolve, fa?o Daily mas n?o olho burndown, depois lá no final da sprint, quando n?o temos mais margem de manobra alguma, tenta-se algo, enfim, deve-se utilizar de verdade dos métodos ágeis, mas eles n?o d?o resultado sem engajamento do time com as suas práticas.

Ironically, we speak of Agile methods to tight engineering (ie, Waterfall) deadlines. Agile is great for prototyping POC, or adding incrementally to an existing product, to provide and receive ongoing feedback ("are we on the right track? Are we still in sync?"), but it may not be appropriate for some projects with hard deadlines and hard budgets that is the hallmark of serious new investment (with marketing launches, channel fulfillment, training...), or risk averse organizations who watch their budget to the last dollar. Unexpected issues are mostly handled by stopping some activities, lowering their priorities, to redirect key resources thus freed up. We can call it Agile, or what it really is: Scope Change Control.

Something I found helpful in context of being agile is, include the customer, engineers, design and PM in the weekly or release calls. It helps the engineering or design team understand the problem directly from customers, feedback will be immediately known to them(good or bad) and it will keep the team motivated as they aren’t just working on tickets instead solving a customer problem.

1. When unexpected issues arise, We can reprioritize tasks, adjust the project scope, and incorporate new requirements based on evolving circumstances. 2. Features can be reprioritized, and the team can focus on delivering the most critical functionalities first, reducing the impact of the issues on the overall project. 3. After each sprint, the team reflects on what went well, what could be improved, and implements those improvements in the next iteration. This will help in learning from unexpected issues and finding ways to prevent or handle them better in the future.

Error handling means making sure that the code can handle "all" expected and unexpected scenarios. I can remember a scenario where we tested a variable for True and False but did not cater for when the variable was Null. Our team uses automated code checking such as lint and implements processes such as peer reviews and pair programming to ensure that coding is not done in silos. We also have logging via New Relic or Sumo Logic. This allows us to set alerts if an error occurs, calls to an API drop, or application run times have increased. Such alerts help us to quickly fix an issue before a customer complains.

I am not sure EH is that useful towards the mitigation of Unexpected issues. Unless we don't mean the last level in an "if else" or "case" logic block, but rather we mean the saving of the state condition at the time things exhibited undesirable symptoms. In which case how does this contribute to the deadlines? Perhaps in more efficient and effective Triage and Debugging; faster identification of Root Cause?

Error handling is useful however better code design implementation is also important. Cross team collaboration on code reviews and deployment can make a significant difference.

Duh! Programming 101! The 20/80 rule applies. In robust code, 20 percent in functional and 80 percent is error handling. One reason projects overrun is that this is not properly considered at the design phase.

Maybe something to consider here too it to make systems more fault tolerant. It is better than breaking after an unexpected error.

Absolutely. However it can be difficult to put into practice, as you need a mature and self confident organization that rises above a quota and "good news" measurement and rewards system. To learn from mistakes you need to admit to them. All too often, the Post Mortems / Lessons Learned mtgs are innocuous or ignore the truly large gaffes because someone important may feel humiliated by association, or there may be monetary or career consequences. It's then up to the project manager and team to keep an eye out for such things informally and unofficially... which is too bad, the wider org (and remote employees) will take longer to improve.

According to the Principles behind the Agile Manifesto, teams are expected to frequently run the exercise to stop and look back to review and reflect on what can be improved. "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." There are many ways teams can achieve this: retrospectives, post-mortems, regular reviews, etc. Doing these activities regularly allows the teams to improve and adapt their working methods incrementally. Finally, documenting the learnings and tracking action items on the improvements helps the team be set up for future success.

Cultivating a culture of accountability and ownership truly helps in ensuring that people strive to learn and share knowledge gained mistakes.

In case of major incidents, there is quite popular notion of blameless post mortem analysis. After any major incident there is a collaborative effort undertaken to analyze root cause and the best way to avoid it and/or deal with it in the future. All of it is then described in a template-based document for future reference.

An RCA should be a required document/process when dealing with software development issues especially during production support (outages, systemic errors, etc.). A well-formed template will allow team members to gather the right information. In addition, it's important the document is reviewed and approved to ensure it includes all the facts and is objective. Lastly, RCAs are a key step in the overall incident management process...a process which allows organizations to respond quickly with the proper follow-up.

Seeking help might seem like you don't know what you're doing, but it's actually not the case. Just do it, two (or more) heads are better than one.

As leaders to aid in this, I found that having internal workshops and showing off successful projects assists in mentoring, creating a platform for viability on lessons learned and cultivates clear communication, as well as opening for Q and A which provides insight into current sprints

You can triage the feature set encompassing the problem, to be dealt with later in a future sprint in your agile deployment plan when you have enough knowledge and resources to tackle it, with acceptance from stakeholders that this does not prevent other feature sets from being released in the current sprint.

Getting previous feedback about any Project, Situation, Team, Area, Process, we can visualize in advance any possible issue and be prepared for. On the other hand, when the problem arises, ask for advice to them who already faced it in the past...

Seeking help is being professional. After you received help your knowledge is expanded. Next time you can do a better job. Win win.

Maintaining balance and composure is the utmost quality for a product/ project manager. Because only then the manager would be able to apply the various measures shared in other parts of this article. Only a reasonably calm person would be able to retrospect and identify the actual cause of the unexpected issue. Majorly unexpected issues are caused by one or the other failure of the team, it can be improper use or implementation of Agile principles, lack of transparency, or failure in anticipation of variables affecting the project. Whatever be the case, there should be progress and for that a composed manager is the key.

Balance is Key! Unexpected issues? They're just part of the game in software engineering. Remember, these challenges don't define your worth or performance. ?? Keep perspective: take care of your physical and mental health. Set realistic goals, take breaks, exercise, meditate, or indulge in your favorite hobbies. This isn't just about managing work; it's about nurturing your well-being. By maintaining balance, you face challenges with confidence and resilience. Stay balanced, stay brilliant!

It's important to understand the difference between a person's perspective on goals vs the company's perspective on those goals. If you learn to distinguish the two it can greatly help you with your own perspective on what goals your team has. Just because someone says something is high priority, doesn't mean it's high priority unless that is corroborated with the appropriate people in the company with the authority to make that claim.

Problems never end, so it is important to have control on our feelings and keep separed our profesional from our personal side...

The greatest success factor to overcoming unexpected issues is the collective reaction to the issue. We need to take the collective emotional responses, collective technical responses, and the emotional responses to those technical responses from the issue into consideration holistically. Because left unmanaged from a holistic perspective, unexpected issues can wreak havoc on project and/ or organizational culture. Identifying and communicating the emotional responses helps validate the human experience in the process and creates a positive organizational culture. Which, fosters a healthy dynamic holistically where innovation can thrive.

Always focus on what you can control. The things you have no control over aren't worth your time or energy. It is more valuable to spend your time and energy on building a great team than it is on building a great product. If you have a great team the product will happen, the goals will be met, and the delivery will be the best it can be. If you focus on a great product or delivery you may get out the door, but you might not have a team at the end of it.

I found what helps when it comes to managing unexpected issues are: - Focus on the solution not the cause until retrospect time when reflection on the cause can be helpful. - Having a regular platform to encourage clear and honest communication, unexpected issues are often avoided completely. - Ensure that the problem statement you are trying to solve is clear, the team should have a clear understanding of what is being solved and what the plan is to get there, if this is clear, something unexpected is often worked around easily.

There will always be unexpected issues that happen on software projects, not all of them are negative either. It's important to understand that no individual should responsible for addressing issues and in fact, companies that adapt well to issues tend to embrace change from the top down. What I have seen work really well is when all the company stakeholders collaborated and educated each other and periodically discussed issues in order to determine if in fact there was an opportunity possible or whether a pivot was required. This was only possible as the engineering team were given the psychological safety to be able to raise issues early.

One skill that is essential to managing unexpected issues when working under a deadline is the ability to prioritize. You cannot succeed when your prioritization tactic is to jump based on which customer or department is yelling the loudest. At the business level you need to set specific criteria for what to consider when determining what order to address issues in, and whether to allow an unexpected issue to jump the queue. Then you need to empower your team to follow that criteria and teach them how to manage customer expectations around it.

Issues are standard, the key thing is remaining calm, if your first instinct is to panic and rewrite or make large changes, then you are already making things a lot worse by adding more errors to your error. At the end of the day, the initial issue might have just been a typo. Identify. Isolate. Understand. Resolve.