A Developer, a UX Specialist and a Project Manager Walk into a Bar
It’s a random Thursday night, and a small group of professionals is casually gathered for happy hour after work. As is often seen with any group of professionals in the same field who’ve come together socially, they begin their evening by blowing off some steam:
“ Man, this QA Engineer on my project is giving UX design tips instead of just testing the user stories!”
“ Well, our Project Manager is letting the client add more and more requirements to the project. There’s no way we’re ever going to finish on time.”
Let’s be clear: By “ blowing off steam” , I’m in no way referring to the kind of incessant complaining that creates a toxic force-field of hopelessness that kills off creativity and threatens to sour even the best work environment. (That level of negativity is a completely different situation and should be aggressively nipped in the bud.) However, engaging in the occasional gripe session with one’s peers is normal and healthy. It allows us to connect with others, especially in times of stress and, if we’re open to it, sometimes those gripes are opportunities in disguise, a concept that’s recognized in the Scrum methodology.
In the Scrum, we practice the end-of-sprint “ Retrospective” which is meant to be an open, “ no holds barred” assessment of the good, the bad and the ugly of the previous project sprint, in the spirit of team collaboration and problem solving. As a Delivery Manager, I can say that although I like retrospectives and believe they have their place in the process, I’m also a realist, when the discussion includes everyone on the team, as a Sprint Retrospective does, the honest kvetching — the difficult feedback that leads to genuine course correction and improvement — is not likely to be tossed into the ring. That type of real talk comes out when the team has its guard is down, when the people are outside of the retrospective meeting in a more casual social setting like happy hour or a spontaneous lunch. True assessments of what’s working on a project and what’s not are also more likely to happen when team members are among those they feel can handle hearing the gripe without getting anyone’s earbud cables in a bunch.
The truth of that human tendency to be polite is unfortunate because being honest about what’s not working is the only way to improve. But this truth is a component of our society, ingrained in our culture. We are quite simply raised, for the most part, to be courteous to our colleagues and deferential to our customers and managers. So, to those who remain reluctant to be honest about what’s not working, I encourage you to flip your complaint on its head! Think about not only how you can frame a difficult situation so that it’s viewed as the opportunity for improvement that it truly is, but also think about the person to whom the difficulty is being expressed. Yes, not all complaints are for the larger group, and that’s where your project’s Delivery (or Project) Manager can be of immense value.
Following are four of the most common project complaints I hear (they are not as bad as they may seem), along with considerations about to whom these difficulties can be expressed in order to promote change:
1. Scope creep. When a client adds to an ever-growing list of design or development requests, which happens in 99.5% of all software design and development projects, the first thing that comes to mind for many team members is the phrase “ scope creep.” Scope creep is not some strange dude lurking in a dark alley with a telescope, it’s the concept of a project’s defined scope (or end business goals) growing and morphing into something larger than what was initially anticipated when the requirements, budget and timeline were established.
Scope creep as a concept is a relic left from the days of waterfall projects where a Business Requirements Document (or Product Requirements Document) was created, approved and revered as an unyielding and authoritative tome locking the business stakeholders and project resources into an uncomfortable, “ forever-hold-your-peace” dynamic that could not easily accommodate the reality of fast-paced markets and changing customer demands.
In Scrum, we assume at the outset that requirements are going to evolve, especially when the stakeholders are given real-time visibility into the project’s progress at the end of each sprint. A skilled Delivery Manager will not only help the client to capture these new and evolving requirements but will guide the evaluation and prioritization of new requests so that without changing the timeline or the budget, the client is still able to walk away with a valuable product that meets the critical business needs.
If you’re working with a Delivery (or Project) Manager, these conversations are most likely taking place “ offline” , one-on-one with the client. But if you, as a project resource, are not sure about this, then I encourage you to bring it up with your Delivery Manager in the context of, “ I’m concerned that the client is giving more requirements than we can possibly deliver and I don’t want to fall short. Is this something you’re communicating with the client about?” Because if it’s not, it certainly needs to be!
2. The single most important thing is… everything. The client has a life-changing, customer-changing, or workday changing technical solution that’s been cooking for months or even years. They’ve got an approved budget in hand, an eager group of stakeholders and a whole host of needs and requirements. In other words, they’re more than ready to go, so a project team’s request for the client to prioritize is often met with “ Huh? EVERYTHING is important! This product cannot be released until EVERY SINGLE IDEA is executed!” Few phrases strike fear into a resource team quite like “ It’s ALL high priority!”
Unless a client has truly endless funding and no launch date in mind, prioritization is a necessary evil. I am a firm believer in being honest with the client, and with the team, so conversations around priority need to happen early and often, for everyone’s benefit, and they don’t need to happen in private. If prioritization conversations are not happening in your project, bring it up right away to your Delivery Manager who should be grateful for the nudge. Something along the lines of “ It feels like everything is urgent, but at some point, something is going to have to be left behind. How can I help you to be sure that we deliver the most value in the time and budget we have?” Every Delivery Manager is a sucker for a “ how can I help you.” Give it a shot.
3. Who is this for? Ah, yes, opinions are like… brains. Everybody has one! But a common problem in software projects is when individual opinions take the place of end-user needs. This is especially true when the primary users are not part of the core project team. It’s much easier to say “ I know what I’d want” than it is to conduct end user research, including usability testing. This is not an issue specific to client stakeholders: everyone on a project team, even the resources, has a natural tendency to view a technology solution through the lens of their personal experiences and preferences. Once we accept that, we can be aware of when it’s happening and keep each other honest. This isn’t something that only the Delivery Manager can identify and stop: it’s equally important for the UX Specialist and/or the UX Designer to keep the end user in the forefront by continually reminding the project team of who that end user is and refocusing the entire team’s attention on the Personas and Context Scenarios created for the solution. If you’re on the client stakeholder side, you should also keep an ear open for personal bias or unsubstantiated needs from your other stakeholders and the rest of the team members.
4. Meandering meetings. This is a common complaint within the American workplace in general: “ We have too many meetings and they don’t have a clearly articulated goal, so we end up talking in circles until a key stakeholder has a hard stop. I don’t have time for this!” Hey, who does? This falls in the lap of your project’s Delivery Manager. Not only should your Delivery Manager set only necessary meetings, but he or she should time-box them (hint - shorter is better), create and circulate an agenda and also identify and share the expected outcomes of each meeting. If your Delivery Manager cannot answer those questions, there shouldn’t be a meeting on the calendar. I would hold your Delivery Manager’s feet to the fire on this one. Identify this issue early and approach the Delivery Manager directly, although for this one, I think a one-to-one would be a prudent and appreciated approach. One way to discuss this would be to say, “ There is a lot that I need to do on this project to deliver and, honestly, there are only so many hours in a workday. It would be incredibly helpful to me and probably appreciated by others as well if we had shorter meetings and knew ahead of time what our agenda and end-goals were. That way if we finish early, we’ll know it!”
The above are merely four examples of the kind of honest project feedback every project team might hear if every team member were sure they could give honest feedback in a form and format where no one would hold a grudge. No, I am not recommending that you hold all of your project’s sprint retrospectives in a bar. I do recommend, though, that Delivery Managers find a way to connect individually with each team member so that open dialogue is more likely. And I also recommend that all of us find diplomatic ways to frame our complaints, whether one-on-one or in a group setting, so that we improve the odds of a positive project outcome, a happier client, and a victorious project team. In other words, an optimist walks into a bar…