devopsy.kinsta.cloud

Tag: requirements

How to Solve 3 Significant Development Challenges
As products, systems, and software grow in complexity, so does the development process. This can lead to an increased risk of flaws and can result in expensive and potentially reputation-harming mistakes or recalls.

These new complexities have shifted the product development process entirely, requiring optimization from end to end. Engineering and design teams need solutions that answer the most common challenges they face in this process. This means being provided purposeful, structured collaboration tools; connecting distributed team members; and accurately capturing and facilitating feedback, decision-making and context for requirements under review.

Navigating Development Challenges

To do this, teams developing complex products, systems and software must first overcome some significant obstacles. To help navigate this journey, let’s examine some of the most prominent product development challenges engineers are facing today.

Outdated Legacy or Document-based Solutions

The traditional approach to managing risks and requirements is highly manual, operating in an old mindset in which numerous spreadsheets and versioned documents are shared via email. This method has serious drawbacks, including no guarantee that data is up to date. This results in valuable time lost deciphering different versions or painstakingly making changes manually to achieve cross-team alignment.

Additionally, without a clear path of traceability—which can be difficult to achieve for those who rely on static documents—teams often end up referencing older and often outdated versions of requirements. This inevitably leads to misalignment, increased risk and costly rework.

The solution? Uplevel your traceability practices. Moving on from outdated legacy solutions to a modern requirements management tool is the first step to bolstering creativity, productivity and collaboration.

Compliance, regulations and standards processes

Product, systems and software development has become much more complicated over time. As a result, so has product risk and the accompanying regulatory compliance required.

To ensure the long-term success of organizations developing these complex systems, software and products, strong collaboration between teams, knowledge of applicable regulations and effective requirements management platforms are necessities. These tools provide a simple path and single source of truth for defining, verifying and validating key regulations. However, despite numerous industry studies indicating that requirements issues are a prominent factor of project distress, not everyone is convinced their team needs to focus on requirements development and management. Further, they’re unsure of how it will all pay off.

To address these challenges, companies need to streamline their quality and risk management strategies. This can be done by incorporating detailed traceability across the development life cycle—from the high-level user needs and systems requirements through to validation and verification.

Effective Review Cycles

Review cycles are often time-consuming and fragmented. For example, when approaching requirements management manually and with disparate documents, a cycle can be repeatedly delayed due to versioning issues and lack of a single source of truth updated in real-time. It also reduces team visibility throughout the review process; individuals end up spending hours per week in review meetings just to ensure everyone is on the same page.

To up-level this process, it’s necessary to have:
- One source of truth for requirements and tests.
- A straightforward way to send items such as requirements, user stories or test cases for review.
- Best practices for each major role involved clearly outlined (i.e., reviewer, approver, moderator).
- Real-time collaboration within a shared, dynamic requirements management platform.
- An outline of a formal approval process to capture and record sign-off.
Collaboration is Key to Development Success

At the end of the day, collaboration is at the core of all product development work. The ability to effectively work together is critical to ensure innovation doesn’t stop. In this era of rapidly accelerating change, structured and strategic team collaboration is the means for improving the product development process for all involved. By updating your legacy traceability solutions, establishing effective review cycles, and streamlining your regulations, compliance and standards processes, your team will be well on its way to a much more effective and unified product development process.
November 6, 2020
Want a Successful Software Build? Just Say No

It is a truth which should be universally acknowledged that the most important skill for a customer-facing job in what we laughingly call “information technology” is a cast-iron ability to say no—and make it stick.

The misguided desire to please other humans by attempting to deliver on their every request has sunk more projects than any units mismatch or catastrophic misconfiguration—even more than the justly feared Friday afternoon deployment.

The key to success is an agreed definition of what success is, and how we will all know and measure whether we have achieved it. Let’s take the car as an example.

French Cars Have Always Been Weird

These days, we would consider a car to be woefully unfinished if it were lacking upholstered seating for at least four adults, a roof and windows to keep the elements out and some form of in-car entertainment—an FM radio as a bare minimum, probably a CD slot or USB socket as well. This is on top of seat belts, airbags, anti-lock brakes that are probably power-assisted and more lights and safety features than you can shake a stick at.

Nicolas Cugnot did not bother with any of these features. His design didn’t even have four wheels. It not only didn’t have an airbag in the steering wheel, it didn’t even have a steering wheel. It was controlled with a ridiculous tiller arrangement that unsurprisingly completely failed to catch on. And yet, his vehicle was a success by the stated criteria of the project: It made it much easier for the French army to haul ammunition around.

Nicolas Cugnot’s steam dray from 1769

Admittedly, he was also lucky enough to be constrained by the technology available to him. Even Louis XIV might have balked at adding a four-piece chamber ensemble to provide an appropriate musical soundtrack for the driver. But the key point is this: Monsieur Cugnot stuck to his brief, and concentrated all his efforts on the features necessary to achieve it.

Bringing Apple Into It

In somewhat more recent times, we have Steve Jobs (emphasis mine):

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.

One reason why Steve Jobs is so famous is that he actually said those thousand nos—often loudly, rudely and profanely. Steve stands out in IT because most technologists have an irrepressible instinct when faced with a question to start to speculate about it, bikeshed possible solutions, build a quick minimum viable prototype and, before you know it, you are armpit-deep in feeping creatures, all of which you are now somehow responsible to nurture and feed. Not being a technologist himself but more of an ideas person, Steve was perhaps better able to take a step back and focus on the end goal.

Let’s Get Concrete

Now, this should not be taken as a license to adopt all of Steve Jobs’ methods (Lesson One: Be a complete arsehole to absolutely everyone in your life), if for no other reason that even Steve got fired for it, and from the company he founded at that. When someone comes to you with a request for just one leeeeetle feature, you and I probably can’t get away with screaming “NO!” and slamming the door in the requester’s face. The polite and career-prolonging way to deal with the problem is to ask, “Why?”

Ideally, in the process of explaining the rationale for whatever the request is, some other solution to the problem will be identified. A good way to improve the odds of this happening is to involve other people in the discussion. Extending the audience in this way creates opportunities for someone to interject helpfully with something along the lines of, “but Carol, we have a perfectly good hammer over there; why are you trying to use a screwdriver to batter a nail in?”

Sometimes, you may need to adopt an iterative approach, which sounds impressive, but simply means waiting until the end of the first explanation, nodding thoughtfully, and then asking, “Yes, but why?” Among people who watch more television than me, this is known as the Columbo approach: “Help me understand, what is it you are trying to do here?” and just keep doggedly repeating the question. Eventually enlightenment will arrive—or the requester will get tired and go away, which is also a perfectly valid win condition.

This method will also help with the tricky situation where the most important question is the one which is not being asked. There is often an implicit question behind that one, where the solution is not to give a glib answer, but to think critically about the proposed or effective solution and ask the questions yourself: “Why are we trying to solve for this?” Or, “What is this thing you are proposing actually meant to do?” And finally, “What was the original problem, anyway?”

People have a tendency to focus on the issue that is right in front of them, even when the real problem is in an upstream step of the process. They observe or experience something about X as the identified problem, and so default to solving for X directly without considering the broader landscape. This leads to convoluted, inefficient and often high-friction solutions—Rube Goldberg/Heath Robinson machines (delete as appropriate to whichever side of the Atlantic you are on), where a simple connecting pipe is all that is required. An artillery piece will make holes in the ground, but there are a couple of collateral impacts you may want to consider—and maybe offer a spade instead.

All I needed was somewhere to plant some flowers!

Unfortunately even the Columbo Method is not entirely guaranteed to work, because on some rare occasions the underlying request is actually valid and cannot be summarily dismissed. This is when you bring out the big guns and start ranking the urgency of what was already agreed as the scope of the project (a nail hammered into the wall sturdily enough to support that lovely picture) as opposed to what is being requested (a fully motorized picture rail, capable of supporting up to 10 paintings on the scale of Guernica and turning them to optimize lighting conditions throughout the day while also keeping them out of direct sunlight). Nobody is saying that the second option would not be nice, but it certainly won’t be done in time for supper.

And that, children, is how you say No. Go forth, and do ye likewise, and may all your projects be huge successes. And, most importantly, not require me to come in and clean up after you.

— Dominic Wellington

January 16, 2019
Using Trade Studies in Vetting Tool Stacks
Adding to your tool stack should entail more thought than, “Start your free trial today!” It’s great when there is an application need and cloud-based tools are easily grabbed with a few clicks. However, surveying alternatives before making a tool stack change can prevent costly mistakes. Trade studies can help vet best-fit tools for evaluation.

Short for trade-off, trade studies originated in the aerospace industry as a decision-making aid. Teams of engineers (or developers) usually generate multiple proposed technical solutions for any non-trivial problem. A little searching will find the term multiple criteria decision analysis, with three popular techniques: the analytic hierarchy process, the Kepner-Tregoe method and the Pugh method.

For DevOps teams, I lean toward variants of the Pugh method because it avoids creating an overly complex weighting and scoring scheme. Pugh analysis has gained popularity among Six Sigma aficionados for the same reason. Multi-disciplinary teams find the process easy to understand and the results just as useful as more algebraic methods taking longer and needing more input.

Let’s look at three steps in a practical approach: setting criteria, ranking best-fits and starting evaluation.

Setting Trade Study Criteria

Most tool stack disasters result from discovering a tool doesn’t meet all the requirements as the project unfolds. In my previous life, our IT team went all-in on a big-name ERP application partly because it featured web-based portals for suppliers. My e-business team discovered those portals required specific port numbers be opened at the firewall, which corporate security immediately rejected. We coded a way out, using Adobe ColdFusion querying the database directly and securing it with LDAP sign-on, but it took months.

You could search for the “information I could have used YESTERDAY” gif or you can spend time setting the right criteria. Pugh analysis starts with a matrix of criteria rows versus candidate tool columns. What most sources won’t tell you about Pugh analysis is a trick in generating that criteria list:
- Start with must-have features, with current requirements and anticipated future requirements.
- Research tools (data sheets!) for near-fits against those must-have criteria and create the matrix.
- Add all the features prominently listed for each of those near-fit tools to the criteria.
- Search again for more near-fit tools matching features on the extended list, adding to the matrix.
A common mistake is stopping after the first two bullets. Almost every trade study I’ve done discovers more tools fit the must-have list but didn’t emphasize all those features on their website. It’s a bit time-consuming, because every time you find a feature of interest you must go back and recheck all the other tools on your near-fit list for it.

Adding non-requirements? You’ll miss innovation opportunities outside the Venn diagram intersection. My recent client study on marketing reporting tools found one touting support for a dream-list feature. Digging into that tool found it may not support two must-have requirements but does support the others.

Ranking Best-Fits

That’s why the trade study criteria list should visually differentiate must-haves from extended features. I usually shade the extended feature rows, then plot how near-fit tools stack up against all criteria. You can certainly add weighting to features for a more sophisticated analysis, but I find a simple must-have versus nice-to-have usually suffices.

Now start scoring. A strict Pugh analysis uses a plus-same-minus scoring system. Plus means the tool has a clear advantage on that feature, same is same, and minus means that tool is at a disadvantage compared to the others. I sometimes simplify that to just X for a tool having the feature, blank for it doesn’t. This is mostly a data sheet comparison, and you may want to inject other information such as found reading reviews.

What you’ll find is a best-fit list, and it probably won’t be perfect. You’d like to see a couple tools capturing most or all the must-haves, and a few more capturing some of them and extended features for contrast. As an example, here’s the trade study matrix for that marketing reporting tool assessment I mentioned with the vendor names omitted.

Starting Evaluation

Notice this doesn’t have cost information yet. Cost biases technical decisions if applied too early, and feature coverage doesn’t necessarily correlate with cost. Vendors also don’t price their stuff the same way. Some price by developer seats, some by data source integrations, some by monthly tracked users (MTUs) on the web.

With a best-fit list in hand, it’s time to discuss the findings with your team and add information for evaluation. Confirm the scoring, check the vendor pricing models, ask the vendors about unclear feature support and download those free trials to see how they work. Consider how to cover those uncovered must-have features, or if those even are must-haves if few tools support them. Maybe swapping out another tool in the tool stack gets better coverage. Think about innovation those extended features may enable.

Want simpler, faster, actionable analysis without a massive RFP? Trade studies do that. I think it’s valuable to have one person on your team be the keeper of trade studies, someone skilled at interviewing for requirements and refereeing debates during evaluation. You may want to bring in a consultant skilled at competitive research and analysis to help develop your process. In any case, adapt your approach until trade studies help you make better selections—there is no one right answer.

— Don Dingee
December 19, 2018