I've spoken with a lot of product managers, engineers, and designers across Africa — in Lagos, Nairobi, Accra, Johannesburg — and one complaint comes up so consistently it has started to feel like background noise.
"We say we're Agile, but nothing about how we work is actually Agile."
I hear it from PMs who sit through 90-minute standups every morning. From engineers whose sprint priorities get wiped out on a Tuesday because the CEO had a new idea over the weekend. From designers who are handed a fully specced feature to "make pretty" with zero discovery, zero user research, and a deadline that was decided before anyone opened Figma.
These people are not wrong. What they are experiencing is not Agile. It is something that wears Agile's clothes while running on Waterfall's bones — and across the African tech ecosystem, it has become the dominant way companies operate while calling themselves modern.
This piece is about what actually went wrong, what Agile was always supposed to be, and what it looks like when it is done right.
The Complaints Are Everywhere — And They Are Legitimate
Before we talk about what Agile should be, let us be honest about what is actually happening on the ground.
The Daily Scrum, according to the Scrum Guide, is a 15-minute team-owned event designed to inspect progress toward the sprint goal and plan collaboration for the next 24 hours. What it has become in most African tech companies is a roll call. A manager — or someone playing the role of Scrum Master without understanding what the role means — goes down the list: "What did you do yesterday? What are you doing today? Any blockers?" Each person performs their answer. Nobody actually resolves anything. The meeting ends and everyone goes back to their silos. This is not a standup. This is surveillance dressed in Agile vocabulary.
One of the foundational promises of Scrum is that once a sprint begins, the team commits to a goal and the backlog is protected from outside interference. In practice — especially in Nigerian startups and large corporates — the sprint is just a two-week window within which management continues to add, remove, and reprioritise work at will. The MD gets on a call with a client on Monday and by Wednesday, three new features are "urgent." The team scrambles. The sprint goal collapses. The retrospective, if it happens at all, becomes a postmortem on why the team could not deliver what they committed to — when the real answer is that nobody protected the commitment in the first place.
The retrospective is the most powerful ceremony in Agile. It is the moment where the team stops, looks at how they worked, and decides what to change. But it only works inside a culture of psychological safety — where people can say what is actually broken without fear of being seen as a troublemaker or flagged as a low performer. In hierarchical African corporate environments, particularly banks and large fintech companies, this safety rarely exists. People say what is safe to say. The retro ends. Nothing changes. Teams begin gaming the system, choosing safe and tiny sprint goals so they can report 100% completion, while the real work — the risky, innovative work — is quietly shelved. The "transformation" yields no real change. Employees call it "Agile in name only."
The Scrum Master role is one of the most misunderstood positions in African tech. In many companies, the Scrum Master is just a project coordinator with a new title — someone who updates the Jira board, chases people for status, and books the meetings. That is not what the role is. A Scrum Master is a servant-leader whose job is to protect the team, remove blockers, coach the organisation on Agile values, and push back — respectfully but firmly — when leadership tries to circumvent the process. When that role is filled by someone who has a certification but not the authority or understanding to do the actual job, the whole framework becomes decorative.
Across Africa, a significant number of companies declared themselves Agile because it was what investors wanted to hear, what clients expected, and what the CTO came back preaching after a conference. The Jira board appeared. The two-week sprints were announced. The terminology changed. The behaviour did not. Decisions still flowed top-down. Customers were still consulted last, if at all. Documentation was still treated as the measure of progress. They had adopted the ritual without internalising the religion.
Nigeria and Kenya have produced thousands of Scrum Masters and PMP holders in the last five years. The certification industry is booming. And yet you can sit in a sprint planning session with a certified Scrum Master who does not know how to facilitate story point estimation, does not understand the difference between velocity and capacity, and has never once asked the team what they need to work better. The certificate exists. The competence does not. And because companies hire the credential rather than testing the capability, these gaps get embedded into teams and calcify into culture.
Going Back to the Source: What the Agile Manifesto Actually Says
The Agile Manifesto was written in 2001 by seventeen software practitioners who were tired of heavyweight, documentation-driven processes that consistently produced the wrong things slowly. They agreed on four values:
Read those again. Not as a poster on the wall — actually read them. The manifesto does not say processes and tools do not matter. It says people and how they work together matter more. It does not say documentation should not exist. It says delivering working software is more important than producing documents about software. It does not say planning is bad. It says the ability to respond when things change is worth more than the comfort of following a plan that is already wrong.
The manifesto also has twelve principles. A few of the most violated ones in African tech:
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." — Not to satisfy the MD. Not to hit the sprint completion percentage. To deliver value to the customer, continuously.
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." — This does not mean welcome your CEO overriding the sprint backlog. It means build a system that can absorb real, validated, customer-driven change without collapsing.
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." — Trust. That word appears in the manifesto and is absent from most African Agile implementations. You cannot run Agile in a culture of surveillance and distrust.
"The best architectures, requirements, and designs emerge from self-organising teams." — Self-organising. Not told-what-to-do-at-every-standup teams. Self-organising.
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." — This is the retrospective. It requires honesty. Honesty requires safety. Safety requires leadership that does not punish candour.
What Agile Actually Looks Like When It Works
The difference between Agile done right and Agile done wrong is not the tools or the ceremonies. It is the mindset of the people running the organisation.
15 minutes. The team owns it, not the manager. Nobody is reporting to anyone — they are synchronising with each other. The questions are not "what did you do?" They are: "What did I complete toward the sprint goal? What will I do today toward the sprint goal? Is anything blocking me from reaching the sprint goal?" Every word connects back to the goal. If something needs a longer conversation, it is taken offline. The meeting ends on time. The team walks away more aligned than when they arrived.
Results in a clear sprint goal — one sentence that captures the why of the sprint, not just a list of tickets. The team pulls work based on realistic capacity, not what management wants crammed in. The Product Owner clarifies requirements. The team estimates together. Everyone leaves knowing what they are building and why it matters. Nobody adds new tickets on day three.
The most protected meeting in the calendar. Facilitated by someone with enough skill to create genuine safety. The outcomes are concrete: not "we should communicate better" but "we will have a 30-minute alignment call every Monday before sprint kickoff." Changes are tracked. The next retro opens by checking whether last retro's actions were followed through. It is a loop of continuous improvement, not a venting session that changes nothing.
The single voice of the customer inside the team. They have done the discovery. They understand user needs. They have prioritised the backlog based on value, not on whoever shouted loudest in the last leadership meeting. They are empowered to say no. They are trusted to make product decisions without escalating every choice to a steering committee. They own the what and the why; the team owns the how.
Removes obstacles — it does not create them. Leaders invest in the system, protect sprint goals, and create the psychological safety that makes retrospectives honest. They measure output in terms of value delivered to customers, not lines of code written or tickets closed. Their job is not to direct the work but to create the conditions where great work can happen.
The Specific Fixes for the Specific Problems
If you are a PM, Scrum Master, or engineering lead in an African tech company and you recognise your organisation in what has been described above, here is where to start.
Stop asking "what did you do yesterday?" Start anchoring every question to the sprint goal. Ask the team to identify blockers, not report progress. Timebox it ruthlessly to 15 minutes and move detailed discussions to a follow-up. If managers are attending and it is changing the energy in the room, have that conversation.
This is a leadership problem, not a process problem, and it needs to be named as one. The Product Owner must have the authority to say "this is not in scope for this sprint" and be backed up when they do. Document the interruptions. Show the cost in velocity. Make the pattern visible and bring it to the retrospective. If nothing changes after that conversation, the organisation has not actually committed to Agile.
Start smaller. Use anonymous formats — written cards, digital tools where answers are submitted before discussion. Focus the first few retros on process, not people. Build the habit of action before you demand the depth of honesty. Safety is built over time; you cannot mandate it in a meeting.
Invest in the role properly. A real Scrum Master needs coaching skills, organisational authority, and the freedom to challenge leadership. If the person in that role cannot protect the team from management interference, they are not doing the job — regardless of what their job description says or what certification they hold.
The only fix is leadership education and genuine commitment to the values behind the practices. Be honest in the assessment. The organisations that have genuinely transformed are the ones that were willing to say: "We are not Agile yet. Here is what it will take to actually become Agile."
FAQ: Common Questions About Agile That African Tech Teams Ask
Neither Scrum nor Kanban is mandatory. Agile is the mindset; Scrum and Kanban are frameworks for expressing it. Scrum works best for teams building in well-defined increments with clear sprint goals. Kanban works better for teams doing continuous flow work — support, maintenance, or ops-heavy roles where work arrives unpredictably. Many mature teams use a hybrid. The choice should be driven by your team's actual workflow, not by what sounds more sophisticated in a job description.
This is the most common Agile problem in African companies and it has one honest answer: the organisation has not agreed to what Agile actually requires from leadership. The technical fix is a clear Product Owner with genuine authority over the backlog, and a defined process for handling urgent requests — such as a "break glass" protocol where unplanned work replaces existing work rather than being added on top.
But the deeper fix is a conversation with leadership about what sprint commitments mean and why breaking them consistently destroys team velocity, trust, and product quality. That conversation is uncomfortable. It is also necessary.
Two things are usually happening. First, the retrospective is identifying problems without generating owned, time-bound action items. "We should improve communication" is not an action item. "Taiwo will set up a 30-minute sync between product and engineering every Monday before sprint kickoff, starting next week" is an action item.
Second, the team may not feel that leadership actually wants things to change. If every retro produces actions that get ignored, the problem is not the retro — it is whether there is real organisational commitment behind the process.
This is a real tension and pretending it does not exist is not helpful. The answer is not to abandon Agile but to negotiate what is fixed. In most cases, clients care deeply about the deadline and the budget, and less rigidly about the exact scope — especially if you are communicating regularly and showing working increments.
The Agile approach to a fixed-deadline project is to start with the highest-value items, deliver working software in short cycles, and use each cycle to calibrate what is realistically achievable by the deadline. You may not deliver everything. But what you deliver will be the right things, built well.
Not necessarily — but you should fix them. The team hating the standup is a symptom that the standup is being run incorrectly, not that synchronisation is a bad idea. Audit the meeting: Is it 15 minutes or longer? Is it team-owned or manager-led? Is it connected to a sprint goal or just a status recitation?
Fix what is broken. If the team still finds no value after the standup is run correctly for a few sprints, then have the conversation about whether daily is the right cadence for that team's workflow.
Partially. A tech team can practice Agile internally and get real value from it. But the full benefit — faster time to market, better product-market fit, higher team morale, genuine responsiveness to customer needs — only materialises when the rest of the organisation understands and supports it.
When marketing, sales, finance, and leadership operate on Waterfall assumptions — annual plans, fixed roadmaps, no tolerance for changing requirements — the tech team will always be absorbing pressure that the methodology was never designed to handle alone.
Yes — and in some ways, more urgently than anywhere else. African markets change fast. Currency fluctuations, regulatory shifts, infrastructure constraints, and evolving user behaviour mean that long-term fixed plans fail here more often than they do in stable Western markets.
The ability to learn quickly, respond to real user feedback, and adjust course without waste is not a luxury in the African context — it is a survival skill. The problem is not that Agile is wrong for Africa. The problem is that Africa has adopted Agile's vocabulary without building Agile's culture. That culture can be built. It just requires honesty about how far the current reality is from where it needs to be.
The Bottom Line
Agile was never a project management methodology. It was a statement of values — about people over process, about working software over documentation theatre, about genuine collaboration with customers over internally-produced specifications, and about the ability to respond to reality over the comfort of following a plan that was wrong from the beginning.
What most African tech companies are practicing is not Agile. It is a performance of Agile — the ceremonies without the culture, the vocabulary without the values, the board without the trust.
The good news is that real Agile is achievable. It does not require expensive consultants or elaborate frameworks. It requires leadership that genuinely believes in it, teams that are given real autonomy, and a willingness to be honest about what is and is not working — consistently, in every retrospective, until the gap between what you say you are and how you actually work begins to close.
That closing of the gap is what Agile actually is. Not the Jira board. Not the sprint. Not the standup. The relentless, honest, incremental pursuit of working better.