Recently there has been some trouble amongst my developers where it has finally come to pass that they are ready to tell the world that they aren't satisfied with the requirements that they're being given by our Project Management and Business Development Teams. Long indetified as an issue, but mostly cast aside as being the braying of an overly cautious engineering manager, some purchase was gained after a particularly disasterous iteration where it was made clear that the quality of the development wasn't up to par, and that key features were being missed. During a meeting called to discuss the discrepancies with the developers and how we should attend to them, the absence of the project manager in this meeting (presumably) made them more comfortable in sharing that the requirements haven't been clear enough for them to cover necessary test cases for backstopping the development. This has given me more ground with which to stand on, but let's dive in a little in to the plannin process.
As a digital services company, "planning" time is one of the most commonly missed parts necessary for ensuring a great delivery. One tends to do fairly minimal requirements discovery as part of the business development process, but doesn't really invest time upfront during the billing period to have the developers sit down with the project manager or business team to discover what the client really wants. Some developer time is made available during the process, but seems to be seldom used, partly because of the language barrier (where I work) and the overhead that it contributes. I think though that it's "just the way it has always been", and it really hasn't changed despite significant protests.
Now, I do think it's important and fair to keep in mind that we also don't want to spend endless time working on requirements with a company that has a low chance of signing with us. We want to ensure that our developer's time is focused on paid work or internal projects and tooling that will enhance the company's performance or its value if we were ever looked at for an aqui-hire. So, while developers are available for these activities, they aren't just around to be picked up and brought in to client meetings during pre-signing stages. Whether or not this is the correct approach isn't something I can say for certain. I'm willing to change my mind, but I'll definitely have to consult with peers in the industry.
From there, the Project Managers write out a bunch of Epics, although I think it's more appropriate to call them features that might be Epics. When PM's aren't really software development PMs, and they haven't really taken to the lessons offered and/or learned from previous work, things will be forever challenging. At that point, they take Epics that contain no work tickets and no estimates, put them in as a 2 week long piece of work, slap it on a timeline and say "yea, that's good". Obviously it's not a particularly good, or sustainable, system, but without having developers involved in a more intense planning process, they do that or get estimates from people like myself, and depending how involved your own manager might be, them. Half of the time the length of the project is just eyeballed by the CEO before I even manage to get eyes on it, and that becomes the deadline.
If the project has a UI and will be presented to customers, it's time to start really understanding the customers. Hopeully there was a period during the initial project proposal and discovery process that surfaced what real problems the client was having, and some access to people who were experiencing the challeges were interviewed. If not, you've got a more uphill battle to fight, but it's one that can be won. Before going in with hands on keys, you want to get the interactions, the visual design, and the usability testing before you start development. Depending on the size and scope of the project, this can be a day or two or three to four weeks. There are no hard and fast rules, but when you get out there, you want to make sure your customers aren't just going to tolerate the results of the project, but be delighted to use it.
That would be true in a perfect world though, and we very much live in an imperfect one. I understand that designing from the backlog is not great, so it's time to bring in the team. In my opinion what should happen is when the project starts, the devs who will be involved across the disciplines should sit down together in a room, virtual or otherwise, with the PM, BDM, QA, whoever else is on the project, and start breaking down the epics critically. Talk about interactions, talk about workflows, talk about user interviews, try to get everyone involved on the interviews as well. You can walk through these things without ever having to touch a keyboard as well. Post-it notes are fantastic ways to break down your interactions and workflows. You can start on the visual design and usability testing as well. Everyone knows how to use the interfaces that customers require you to use. Mobile, desktop, web, and if there is specialized hardware involved, get a dummy or sample of it. 3D print it if you need to.
Then using the combined experience of everyone in the room, you can crack epics down in to a giant pile of mostly organized work that needs to be done, questions that need to be answered, and possible things that need to no longer be requirements. Dependencies should be charted out, estimates should be created wherever possible, and then the real, estimated timeline should be presented. Inevitably, things will be missed by the team, and new concerns will surface. Developers need to be thinking with their heads and not blindly implementing things from the backlog. When requirements are incomplete or don't make sense, they need to bring those concerns up during standups and planning sessions. One of the biggest challenges for companies has nothing to do with coding, it is entirely down to communication. The ability to communicate starts with the willingness to do so. Developers must fight the desire to just "figure it out" and deliver something that is off-spec two days after they started.
From there, the cycle continues. Requirements are something of a moving target at times. It's imperative that the team, even those that are off project for a little while, are kept up to date when they change. You never know when you're going to have to pull in the frontend developer, or bring in one of the QA personnel that wasn't necessary for the first couple of months. A little bit of update beats out having to pay a week or three in ramp up.
Authored by: Mal
Written: 2023-12-12