Frequently Asked Questions

I respond to most enquiries received through my website, with the most useful responses anonymised and shared here with consent.

---

Table of contents

What are software requirements
Are software requirements important
Isn’t gathering requirements anti-agile
Functional requirements vs non-functional requirements (NFRs)
Software design specification
What do you think of Scrum
What are your favourite offshoring locations
I’m so tired from sprinting all the time
I’m not cut out to be a Scrum master
My girlfriend wants us to try Scrum
Technical debt is killing our delivery
My delivery manager changes his mind on a daily basis
My developers are very quiet and don’t speak up
How do I track what my developers are doing
Every production release is a disaster
My Vietnamese offshore development centre is on fire

---

What are software requirements

Software requirements are a description of what a software product should do. They represent the needs and wants of product users and broader stakeholder groups and, as such, should be clearly written down and prioritised.

Many formats exist to capture requirements, including use cases, agile user stories and requirements catalogues. All are valid and have their place, depending on context and environment.

Software requirements are easy to do badly and notoriously tricky to get right. Business analysts and requirements engineers are responsible for gathering and validating requirements – it’s an interesting but specialised job role.

Are software requirements important

Yes! Yes, yes, yes. Because without them, chaos happens. Your developers won’t know what to do, so they get stuck and frustrated, or spend their time day trading instead of working. Others may work it out for themselves, building what they think is needed, making important decisions as they go. Even the most ‘agile’ of developers still need a way to clarify what’s required.

Sadly, the business pays the hidden cost, the very individuals least well-placed to know what’s going wrong. Not having good requirements will become visible as poor quality software, delivered slowly, often not working as expected, by angry or demotivated developers. Only to be sent back for re-working, once again. Nobody wins, and it doesn’t feel good.

Isn’t gathering requirements anti-agile

Seriously, who said that? The same person who told you that touching the banana makes you blind? Anyhow, requirements gathering and solution designs are even more critical for agile software development, not less. The confusion lies in the idea of fully ‘signed-off’ requirements or ‘big design up-front’ (BDUF), neither of which an agile team should aspire to. Instead, just enough detail at the last possible moment is the right approach, with some kind of overarching high-level design or roadmap in place as the North Star to all pull towards.

Requirements in the form of agile user stories are helpful, and having these refined ahead of implementation means developers can build rather than be unexpectedly blocked. The only time I’ve seen not bothering with user stories work well is a single developer sat next to the product owner, both happy to have frequent conversations throughout the day. Which is fine if that’s you and your situation.

Functional requirements vs non-functional requirements (NFRs)

I’m so glad you asked. Functional requirements are what the software needs to do, whereas non-functional requirements are more about the standards it should adhere to when doing it. NFRs are also known as ‘quality attributes’ because they are more like the service standards the user should expect.

Here’s an example. ‘I want to make a payment by credit card’ is a functional requirement; it is something a user wants to perform to meet a goal. ‘The payment should be secure’ is a quality attribute that explains how it should be performed ie. securely. This could be further elaborated by specifying implementation-specific details, ie. ‘256-bit encryption for card details’ and ‘compliance to PCI-DSS’, an industry standard for card payments.

NFRs often apply to entire software products or whole sub-systems, unlike functional requirements which describe individual pieces of functionality. ‘I want to make a payment by PayPal’ is a second payment requirement, but the expectation of doing so securely still applies. For this reason, NFRs are often specified at the product level and then referenced within individual requirements, or inferred as generally applicable. ‘Cross-cutting concern’ is a commonly used term for this.

Software design specification

Software requirements define what the software should do, whilst a software design specification shows exactly how it will be done. Software requirements avoid specifying solutions and implementation details where possible, allowing the requirements gathering to proceed without undue concern for solutions too early in the process. However, once the requirements have been well defined and agreed upon, then producing a software design specification commences.

Several implementations may be suitable, but the design specification clarifies which one to use. Developers won’t need a software design specification for trivial requirements, simply extending the existing codebase in a familiar pattern and working out the minor details themselves. However, more substantial changes, new products, and large or remote development teams will do.

A dedicated technical architect or entire architecture function will be responsible for producing the software design specification, sometimes consisting of several different architectural blueprints, solution designs and low-level details and implementation guidance. Good judgement should decide when a specification is required and what level of detail is appropriate.

What do you think of Scrum

I think Scrum is an excellent way to build software, and I’ve had many good experiences with it. It’s fairly prescriptive, fosters good planning, promotes sustainable development and requires whole team inspection points for improvement. That’s the kind of Scrum I know and I’m familiar with.

Unfortunately, it doesn’t take much to turn Scrum into a developers’ worst nightmare, ie. daily micro-management, endless sprinting, oppressive burndown charts, futile retrospectives. Many developers I know have experienced this at least once in their career, and when they do, it leaves a lasting sour taste.

My advice is to get a truly excellent Scrum Master who can protect the team from this kind of thing whilst educating the wider stakeholder group and fostering the right conditions for agile working.

What are your favourite offshoring locations

Hmm, tricky question, but if I had to choose, it would be Eastern Europe, particularly Poland or Romania, because the tech calibre is very high, there is a good grasp of the English language, and working hours are similar to the UK, but most importantly, a culture of great craftsmanship. However, that’s also meant the cost of Eastern European developers is no longer much cheaper than the local UK market. Although I would still prefer to hire remote.

If you are looking for more significant cost savings (nb. doesn’t necessarily end well), then I would look to Southeast Asia, places like Vietnam and the Philippines that have decent emerging offshore software development industries. Favourable currency rates and lower costs should compensate for increased difficulties compared to their Eastern European counterparts. I’ve worked with many Indian offshore firms and would avoid them like the plague.

I’m so tired from sprinting all the time

Like, duh. Of course you are. Does Usain Bolt run back-to-back 100-meter sprints? Certainly not. Nor should any self-respecting development team, particularly those following Scrum. We work in an industry that thrives on creativity and yet force ourselves to operate like machines.

I’ve seen many teams run back-to-back sprints and burn out needlessly, but it’s mistaken to believe Agile requires this. Different work requires different conditions and tempo. Cut yourselves some slack and regularly down tools for a week or two, do some exploratory tech spikes, bust some bugs or write documentation. See this as necessary rest and repair.

I’m not cut out to be a Scrum Master

Don’t throw the towel in just yet, although your situation does sound difficult. You’ve told me that the dev team and company managers see you as the delivery manager for the product, and you are often expected to manage project risks and provide release dates and other such matters.

It’s a common situation, unfortunately. Helpfully providing burn-down charts, talking about near-term priorities, and fronting regular demos all position you as the person in charge. Being a facilitator, first and foremost, gets lost as all the boss wants is accountability for delivery. This isn’t you.

The truth is, the Scrum Master really isn’t accountable for anything, except well run Scrum ceremonies. Excellent products and well-performing teams are loosely correlated to good facilitation, but it’s not a 100% relationship. The dev team can still do a crap job or be resistant to change, and none of that is a personal reflection on the Scrum Master, or an excuse for thinly veiled accountability.

You need to move away from accountability for the product, clarify your role and remind everyone of that, and encourage the delivery manager or product owner to step more fully into their roles.

My girlfriend wants us to try Scrum

Seriously? Well good for her, and good for you, if you decide to go along with it. I see absolutely no reason not to give it a go, particularly if you’ve been having trouble organising yourselves. You didn’t mention if she had any prior experience with this, but that doesn’t really matter. Remember, Scrum works best for activities that produce tangible output that can be ticked off when complete, like putting up new blinds, cleaning out the shed or bagging up old clothes for the charity shop. I suggest giving each other equal time to speak in the planning meeting, prioritise what’s most valuable for your household, and checking in daily to see how you are both getting on. A good retrospective should bring you closer as a couple and improve your communication too. Good luck with it.

Technical debt is killing our delivery

What you mean by this, I assume, is that the rate of new features being shipped has slowed and your developers are telling you it’s because of ‘technical debt’. Or they have a pained look on their face and scratch their forehead each time they are asked to consider, what seem like, fairly trivial changes.

Codebases become more complex as the product evolves, so it’s only natural that the rate of new features slows down. Making changes becomes harder, and the risk of doing it badly increases. You may also be seeing an increase in quality issues, such as production outages or user-raised bugs, sometimes even in the face of increasing testing efforts.

Your developers could get away with ‘winging it’ before, getting by with insufficient quality and testing measures in place, whilst still shipping ‘perfectly good’ features. Now, the underlying complexity of the codebase is causing problems when working like this. This is what is meant by technical debt.

The solution starts with the right mindset, namely seeing technical debt management as equal to shipping new features. If things aren’t too bad, make time in each sprint to address technical debt, slowly chipping away and keeping things in check. Consider how the design and development of each new feature built can reduce the current technical debt. Sometimes this is all that’s needed.

Unfortunately, the most drastic of cases result in ‘downing tools’ as development effectively becomes stalled because any change is too hard or too risky to make. It’s not the end of the world as various approaches exist to move forward, but an honest acknowledgement of the starting position precedes them all.

My delivery manager changes his mind on a daily basis

Being on the receiving end of an ever-changing work stack is really hard, particularly if a typical daily task takes longer than a day to complete. Then it feels like a continual game of catch-up.

Also, many developers need time to really consider their work and do a good job, so if that’s you, a frantic changing of daily priorities will probably leave you feeling pretty terrible.

You mentioned the manager is quite aggressive and pretty stressed out, so I suspect he is responding to changing demands from his managers from a disempowered position himself. It sounds like a crap situation for everyone.

Unfortunately, it’s very hard for the development team to change this behaviour single-handedly, and whilst management continues to operate like this, I suggest considering whether it’s time to move to a different team or employer, if only for your own wellbeing.

My developers are very quiet and don’t speak up

Without speaking to your developers or seeing them in action, a few possible reasons come to mind. Firstly, have you considered they might just be shy or introverted kind of people? Perhaps your hiring practices simply resulted in a very quiet team.

Alternatively, and it’s ‘look in the mirror time’, perhaps your environment or ways of working keep them quiet for some reason. Do you make individuals personally accountable and blame them for mistakes? Has anyone been sacked for getting it wrong? Are your developers on the receiving end of an aggressive manager or other individual?

Either way, I reflect on the possible reasons for your question and wonder if something more significant is out of place, which you feel might be solved by more vocal developers. Catching technical issues before development might be a good use case, but hoping the developers will solve issues further upstream with product decisions or poor management probably not.

How do I track what my developers are doing

Umm… you know that’s a pretty old-fashioned, pre-covid view of managing your team. It’s like walking the floor to see who is sitting at their desk. Anyhow, I’m pretty sure you want to know how your software development is progressing. Are developers working well, and are features getting built on time? Or is there some hold-up, technical problems or just poor throughput?

The answer is to time-box your software development effort into small increments of a few weeks and pay particular attention to what the team commits to doing in that time. Do they complete what they say they will? If not, and without blame, spend time as a team discussing why. Importantly, develop some ways to improve the planning and what they commit to in the next increment.

Every production release is a disaster

You mean unexpected issues, service outages, lost data, and having to send out apologetic emails to users? I get it, been there done that. Complex software and multiple backend systems, overreliance on manual testing, test environments that don’t correlate to production and pressure to release frequently are the usual culprits.

Unfortunately, not much will change until management realises the rate of change must slow whilst better quality assurance is put in place. Dedicated test environments refreshed from prod, automated testing, better code coverage and one-click deployments are necessary measures. But these require investment and time to do so, even if temporarily.

Ultimately, cultivating a ‘test first’ mindset amongst your development team is the solution, and it’s reasonable to expect in the fullness of time.

My Vietnamese offshore development centre is on fire

Oh dear, I assume you mean a physical fire rather than your developers coding so fast the keyboard starts to spark? Hiring developers in another country is a big deal and should be afforded the same due diligence as entering into a local partnership. You are stepping into a global supply chain, and it’s not good karma to propagate violations of basic human rights or health and safety, willingly or by looking the other way. Be a good global citizen and do your due diligence on the offshore company supplying the developers, considering things like fair wages, employment rights and good working conditions. Fire safety should appear in their list of procedures and training. Western buyers of offshore development services are in a powerful position to influence their suppliers for the good.