During my first experience managing a MuleSoft project, I was shadowing a very experienced PM. She was relatable, organized, experienced and accomplished at managing more than one project at a time. I couldn’t wait to learn the secrets to her success and I diligently took notes as we began our project together. Can you imagine my surprise when the project didn’t go as planned? Maybe you can.If you’ve been through several projects, I doubt it will surprise you that even with the best project kick-off it’s highly likely you’ll encounter some bumps along the way. Typically time, cost or scope are the trouble spots. Thankfully, I learned a lot on that project not because it went smoothly but because it didn’t. Yet she still managed to keep it going. That IS possible. If I were to boil the recipe down to 2 words, they would be communication and awareness. What does that look like on a MuleSoft implementation? Keep reading and I’ll share my advice.
Before we get to that, let’s remember what you’ve already accomplished. You’ve made it through project kick-off. The scope and timeline are set, the team has access, your initial meeting cadence is in place as well as 1-2 sprints of work. I’ll be hopeful with you and say it might be smooth sailing from here. However, let’s take a minute and acknowledge some common project scenarios. These aren’t desired, but they shouldn’t be a surprise either.
- Scope is growing unexpectedly
- Complexity increases impacting timelines
- SMEs (subject matter experts) are unavailable for whatever reason, maybe vacation, competing priorities or just ghosting you
- Risks and issues keep popping up and need to be addressed. How will you keep track and create accountability?
- Execs want to know when it will be in prod. How do you estimate that accurately?
- A problem surfaces that the team doesn’t know how to address. How can you get help?
- Team dynamics begin to suffer and it’s impacting morale
- Responding to defects is slowing down development
Thankfully, there are ways to mitigate these “hiccups” and make sure your team has the opportunity to get back on track. With every implementation, I refine my approach a little more. I hope you will too. That being said, here are my recommendations. If you were shadowing me, this is where I would start.
Promote Communication
- Centralize it where possible so everyone can benefit from technical or process centered discussions
- Keep team discussion going in a Slack channel or something similar
- Gather project documents in a wiki or shared drive. Confluence works well. Google Drive does too.
- Start a RAID log (Risks, Issues, Actions, Decisions). A simple spreadsheet works well. I suggest assigning an owner and setting a due date where applicable otherwise it’s easy to ignore.
- Schedule it – I recommend five basic meetings. Together, they increase accountability, regulate expectations and reduce surprises. It also gives you a chance to listen for issues, risks, changes … anything timeline or deliverable related. A word of caution – Large group meetings are costly. They interrupt your development team’s day and prevent them from working toward sprint goals. Used wisely, they add to your team’s efficiency and contribute to overall pace. So schedule wisely. If you’re in doubt, ask your team for input.
- Basic agile meeting cadence – see this list
- Daily standups – Keep these short. What did you do yesterday? What do you have planned today? Is there anything keeping you from reaching your goals? It’s not unusual for these to drift toward status updates or troubleshooting sessions. You’ll want to save that talk for the end and limit it to those directly involved.
- Demos – At the end of each sprint, take some time to share sprint accomplishments with each other and stakeholders. Depending on your project, 30 minutes is about right.
- Retros – Chances are your team has some thoughts about what went well and what needs improvement. Take a few minutes at the end of each sprint to share feedback. There are some online tools that make this fast and easy like Reetro. What I love about that one is the ability to gather input in advance and turn comments into action items.
- Sprint planning – This is one of those meetings it’s tempting to skip, but don’t do it! You’ll want to move seamlessly from one sprint to the next but if you fail to plan ahead, you’ll lose time at the end of your sprint. Most agile authorities recommend doing this mid-sprint. As part of your planning process, you’ll also want to estimate story sizes. PlanITPoker is one of my favorite free tools for getting this done.
- Weekly Status Update – It’s also tempting to skip this or just email a report. However, if your client is willing, set aside 30 minutes to talk about what happened during the week and how the project looks in general. Some suggested content includes …
- Key accomplishments
- Planned activities
- Key dates like vacation, release timelines, sprint dates, holidays, company meetings, etc.
- Snapshot of RAID log
- Sprint stats or project stats, anything stakeholders might want to understand
- Burndown info
- Optional meetings – Depending on the needs of your project, you may want to schedule extra meetings like these, but again use the development team’s time carefully.
- Backlog Refinement
- Bug triage
- RAID log reviews
- Architectural reviews
- Design sessions
- Lead syncs
- 1:1s
- Lean into conflict
- If you’re like me, you don’t enjoy conflict, but it’s important. Don’t let your client get caught off guard by failing to address problems. Here are two tips that I use when facing conflict: take a deep breath and be direct.
- You’re on a team so if it’s appropriate, get the team involved in troubleshooting problems. Talking through scope and timeline tension is a good example.
- Beware of negative communication patterns. There are many, but these seem to be the most divisive to a team in my experience.
- Withdrawal / Avoidance – “What problem? There’s no problem.”
- Escalation – Ad hominems, raised voices, belittling teammates
- Negative Interpretation – Assuming communication has hidden motives
- Invalidation – “That doesn’t make sense” or “It’s not that bad” or “You shouldn’t feel…”
If you’re noticing an increase in negative communication, it’s healthier to address it sooner than later.
Maintain Awareness
- About your project – Here are a few examples of what you might observe on a project.
- Is your architect or the team saying there are holes in the design? As tempting as it is to press on, take some time to review your design decisions.
- Are work items moving from “Done” to “In Progress”? Then it may be time to revisit the Definition of Done.
- Is the team complaining about meetings? Change – add/remove meetings if needed. Make the process work for you and your project.
- About conversations
- Do you hear tension, disagreement, consensus, concern? What’s the vibe between team members? Are they functioning as a team? Since you’re less focused on technical concepts, you have a chance to listen differently. Think about what you’re hearing and how it affects the project. What’s the appropriate response? A follow-up discussion, a new item in the RAID log or a conversation with stakeholders? Think it over and take action.
- Issues and risks are more easily uncovered when the group is comfortable with one another. To the extent you can set the tone for the team, avoid critical patterns. Venting can be healthy from time to time. However, a culture of criticism can destroy morale. The best case is an environment where the team can collaborate, ask questions and voice concerns. How is your team doing? Are they comfortable bringing topics up with one another?
- About opportunities for improvement
- Give the client the benefit of your team’s unique perspective. If you’ve been involved with multiple clients on multiple MuleSoft implementations, prepare to make recommendations about your client’s MuleSoft maturity or technical competency. What should they be considering? What are the next 2-3 areas they should focus on? Logging, Alerting, Security? The next blog about wrapping up the implementation will focus on this a bit more.
Conclusion
Admittedly, I’ve taken more of a project management than technical focus in this blog. Why? Well, I’m a Client Advisor so it’s just how I think. But it’s also because I’m used to working with skilled, dependable professionals who know MuleSoft. I rely on my architects because they’re reliable. I listen to my teams because they want the project to succeed just as much as I do and the client does. Alongside all the work taking place in your MuleSoft implementation, there’s this amazing opportunity to build relationships and achieve a common goal. It’s pretty cool and it’s also why I love my job leading people through a MuleSoft implementation.
Missed parts 1 and 3 of the series? Check them out here!
{{cta(‘a0617cea-3143-4448-97e3-361d38f7fa28′,’justifycenter’)}}{{cta(’70b51d47-0150-4383-b98d-e19a22dd32aa’,’justifycenter’)}}