Letters

I respond to most inquiries, either direct emails or received through the Scrum helpline, with the most useful responses anonymised and shared here with consent.

---

Developing a successful software product is hard
Why are you so interested in software requirements
Do you enjoy telling the developers what to do
Business analysts shouldn’t design the solution
Our business analyst is not very good
What do you think of Scrum
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

---

Developing a successful software product is hard

Creating a new business is a good analogy, I think. A global marketplace with plenty of customers and existing businesses presents unlimited opportunity, but it also means you need to really think about what exactly to offer, how to compete, and why customers should buy from you. Will you develop something new and completely unique, aiming to capture a risky but first-mover advantage, or will you try to take a bite out of an existing industry and compete on efficiency and economies of scale? Do you understand the customer needs sufficiently, are you well placed to compete against all the other businesses, have you got your pricing right and still be able to make enough profit to remain viable? Can you easily protect any competitive advantage you create? Developing a new software product or SAAS offering is no different; lots and lots of shrewd decisions are required before writing a single line of code. Poor ideas, bad market fit, and lack of planning are probably the biggest early failure points for new software products.

Why are you so interested in software requirements

In truth, I’m not really. Which may surprise you given the volume of posts and articles. As a former developer who still codes recreationally, I am super interested in good software craftsmanship. Getting lost in the IDE whilst engineering elegant solutions is what it’s all about for me. Plus it feels good. However, as someone who no longer codes for a living, how do I create those conditions for other engineers? Perhaps most importantly, how do I describe that to the FTSE 100 companies that could do with my help? Agile coach, technical team lead, and software architect are roles that offer the possibility, however my own experience as a developer tells me the intersection between what is needed, and what is built, is the place with the most leverage to bring about good software development, and the place where the translation goes most wrong. It’s why I prefer the term ‘requirements analyst’ rather than ‘business analyst’, as the main focus is clear.

Do you enjoy telling the developers what to do

I don’t, sincerely. I have no desire to control another person or impose unwanted ways of working. If I ever landed in a team of performant developers, happily gathering their own requirements and shipping working software, I would leave them to it. However, the teams I work in need some help and welcome a second set of hands. Usually, developers aren’t doing a good job, through no fault of their own, and they appreciate having someone work out what’s required so they can focus on writing software. The requirements format, level of detail, and whether implementation specifications and solution designs are required are discussed and mutually agreed upon with the team. Developers remain in control, and my work is supportive rather than dictatorial. Some teams appreciate greater detail, others less, and sometimes the ideal mix changes over time.

Business analysts shouldn’t design the solution

Get real, designing the solution is the fun bit and makes the pain of requirements gathering seem worthwhile. But there is a world of difference between developing a high-level solution as an elaboration of the software requirements versus solutioning on behalf of the stakeholders because you think you know what they want. The former is excellent professional conduct, the latter a disservice to your employer.

I was actually designing an API today to exchange data between Optimizely CMS and some back-end customer data stores. The business requirement was for ‘highly personalised website experiences’, the potential solutions were many. Instead of throwing the one liner over the fence to IT to decipher, I decided spending time elaborating the various solutions would allow the business to better understand what was likely, and IT to assess the feasibility of each. Other solutions may exist and certainly haven’t been ruled out.

What I am absolutely not trying to do is design the low-level implementation and tell IT how to do their job, rather I’m trying to better communicate the already gathered requirement at the next level detail. I’m combining what is needed by the business with what is known about existing (and potentially new) IT systems and capabilities, to promote better conversations and good decision making. Doing some ‘requirements gathering’ with IT to better understand their needs and the systems landscape is also a necessary part of the process.

Developing high-level solutions is probably beyond the remit and technical know-how of most business analysts, but it’s incredibly powerful when done well and should happen in advance of developers starting their work. A technical architect or technical lead often do high-level solution designs as well, but an experienced developer with some lateral vision might be just as capable.

Our business analyst is not very good

Average to poor performance across the whole IT industry is pretty common, unfortunately. Regarding technical BAs, poor quality requirements quickly become apparent once developers get involved. If you have an underperforming technical business analyst, expect to see: developers needing more guidance in their work, developers frequently becoming blocked in their work, clients noticing bugs in product demos, features not working, high levels of rework, unhappy users and unhappy developers.

Often, I perform a mini audit when walking into an existing project; perhaps something similar would help you? Ask your team if they have a clear product vision, high-level roadmap, prioritised software requirements, acceptance criteria, dedicated test and prod environments, and robust release procedures. Additionally, do you gather feedback directly from actual users, and do your developers review requirements before coding them? Have your business analyst focus on poorly performing areas, agree on any training and support they need, and repeat the audit in time to track progress.

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.

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.