When I first arrived in Ghana in January 2015, it took me some time to get my bearings – coming from a large global software corporation, the nascent startup scene in Accra felt acutely unfamiliar, the complete opposite side of my industry. As I learned more about the local space, it became clear that program management wasn’t a “thing” here – yet there seemed to be a huge unmet opportunity on the product side both to share in and learn from the unique challenges African software startups face in hitting the ground running.
I soon had the opportunity to immerse myself in exactly that at MINC, and it opened my eyes to a group of talented engineering teams already moving mountains on a daily basis, as well as the need to bridge best practices from our broader industry to help already-lean Ghanaian startups move faster, smarter, and execute more consistently on delivering products that solve the challenges in their target markets.
My own journey to join the staff at MINC started with a guest talk at MEST’s Product Forum in March, where I shared my experiences leading Scrum teams in the Xbox division at Microsoft, and lessons learned from developing consumer apps at a global scale. The talk struck a nerve on the need for more rigor in the development methodologies practiced by MINC companies, and Scrum offered a clear structure for focusing teams’ efforts.
What’s Scrum all about? Simply put, it’s a mindset and process framework for building software in a way that embraces constant change. In today’s crowded startup space, nimble teams have the best chance of out-executing their competitors, and Scrum is a battle-tested way of empowering startups to deliver software more efficiently while putting their customers first. The Scrum Alliance has a great primer if want to learn more.
We expanded our efforts into running an Agile Boot Camp as part of this year’s NewCo orientation, which I led as an Entrepreneur-in-Residence. Showing the ropes to new companies Asoriba and Flippy Campus helped spread the word within the incubator, and these days I’m also plugged in to the product development efforts of Suba, SynCommerce, and Kudobuzz as a tech fellow, where we look to incorporate Scrum into the companies’ existing engineering workflows as well as feed learnings back to the school side to help integrate key concepts into the curriculum for incoming EITs.
Boot Camp in particular was a great experience – despite running for two solid days, I was pleasantly surprised by the energy of our group, and everyone’s enthusiasm and eagerness to learn. Starting with the basic ‘language’ of Scrum we quickly dove into its agile underpinnings, mindset and emphasis on end users, the rhythm of a sprint, and some of our favorite tools you can use to help implement it.
Interactive exercises helped solidify the concepts by taking the companies through compressed backlog grooming & sprint planning sessions for their own products – prioritizing user stories, writing acceptance criteria, playing estimation poker, and defining story tasks – and brought more than a few surprised faces when team members quickly realized how seemingly simple things could be interpreted completely differently by different people!
Putting Scrum into practice for the first time is always a challenge, and having a set of ‘course correction’ notes handy can help address the common pitfalls teams face as they make the transition. With that in mind, here are six of our favorite Scrum tips my teams and I used on our way to becoming well-oiled agile development machines.
1. Get team buy-in from the start
This one might seem obvious, but old habits die hard, and it takes an upfront commitment from the entire team to really get Scrum off the ground. Rather than appointing a lone Scrum Master to bring about the change, we found that bottoms-up consensus was a much more effective way to hold the group accountable for practicing the new behaviors.
2. Maintain accountability with clear role assignments
In the rush to derive immediate benefits from Scrum’s tools and processes, our teams occasionally glossed over the important jobs of Scrum Master and Product Owner, hoping for more ad-hoc results. Yet these are the champions who are accountable for tracking and removing impediments, or prioritizing the backlog according to business needs, respectively. Both roles are crucial to ensuring a Scrum team runs smoothly. We found the most success when teams avoided having the same person wear both hats, and were open to rotating the roles periodically (both to help manage the time demands, and to build empathy with the rest of the team).
3. Have a clear (and strong) definition of what it means to be ‘done’
Sprint acceptance reviews are meant to be objective, like checking items off a list – but at times we might notice our review discussions becoming subjective, where some behavior assumed to be a given in fact wasn’t written down in the acceptance criteria, or anywhere other than in the Product Owner’s head. We found that writing an explicit definition of done (and referring to it regularly) helped codify those givens and reduce churn in sprint acceptance reviews as a result. Revisit it from time to time though – after all, Scrum is all about continuous improvement!
4. Always honor valid acceptance criteria, even when it hurts
An inevitable growing pain for most new Scrum teams is getting to the end of a sprint and realizing you’ve overcommitted. We had to avoid the temptation to extend the sprint a few days to finish, or to accept stories at a lower quality than we normally would, in order to prevent technical debt from accumulating. Instead, during the sprint acceptance review, we’d punt all stories that didn’t meet our team’s definition of done to next sprint (or sometimes, split off just the unfinished pieces into new stories). It always presented itself as a good learning opportunity in the sprint retrospective – we’d discuss the warning signs and set ourselves up for success the next time around. If you find yourself in the same boat, don’t give up – you’ll get a better sense of your team’s capacity with every sprint you do!
5. Confront ‘hidden’ work head-on by adding it to the backlog
Quality takes time, and so does fit and finish – when teams didn’t account for this time by buffering their estimates, or by explicitly adding stories/tasks for research or e-mailing customers or such, they found it coming out of someone’s nights or weekends, or not getting done at all. Scrum already provides the tools to be upfront about this work: don’t forget that the customer in a user story can be the Scrum team itself! Once they were properly tracked, our teams learned how to prioritize these efforts appropriately against end-user-facing work, and as a bonus, learned exactly much time they really needed to take out of capacity to get it done. (By the way, being a great Scrum Master or Product Owner also takes time – see above.)
6. Keep your ceremonies as lean as possible
Often we might hear, “all these ceremonies take away from time we could be coding” – and while it appears true on the surface, digging deeper the key we found was to run each ceremony in the most efficient way possible, while still creating the desired outcome. For example, to prevent our grooming sessions from going on as long as our backlogs are deep, we timeboxed the meetings to force the team to work within those limits. This worked best when our Product Owner pre-groomed stories ahead of time with as much detail as possible, so that not every acceptance criteria had to be written from scratch during the meeting. Similarly, daily stand-ups presented the best opportunity to keep the sprint task board up to date – our Scrum Masters helped set a quick pace, prevent derailing, and still capture details that need to be drilled into after the meeting.
What’s next for our agile portfolio companies? I’m eager to see the impact Scrum will have on the quality and growth of their products, and hopeful that it’ll serve a gateway to adopting other complementary best practices like continuous integration, thorough instrumentation and telemetry, persona walkthroughs, experimenting in production and regular bug bashes. But above all, I’m excited by the culture shift of delivering constant incremental improvements to customers they deeply empathize with – and I can’t wait to see what ships out of MINC next!
Author: Sean Gabriel