I’ve spent the last year as a software engineering manager for teams building a new product. Our tribe (the group of teams) is part of a larger organisation. Here are 14 things I learned:
I often see situations like this in software teams:
Alice: “We can’t begin testing because we’re still waiting to hear from Bob about when the RC will be ready. He will let us all know in the official Slack channel. Stand by.”
Bob: “I know you’re all waiting for the RC but I need confirmation from Craig first, and he’s not responding to his email”.
Craig: “Usually it’s Dan who makes this decision but he’s on holiday and he didn’t brief me on this when he handed his tasks over to me…”.
Typically, I (mis)diagnose this as a problem of ignorance. The roles and responsibilities are not clear enough! Let’s make another checklist, create another role, set another OKR. This will help people to understand exactly when they’re right or wrong. …
I recently read an article about how scrum disempowers developers due to its focus on value rather than technical excellence. This is something that resonates with me, so to “pump” my intuition I want to do a little thought experiment where we try to stay within the scrum universe, but try to solve the main problem (developers being disempowered by scrum) by modifying the scrum framework.
As the author of the article states, “Scrum has a master, product has an owner, but no-one is empowered to advocate for development priorities.” To remedy this, let’s add a new role to scrum called the craft master. The craft master guides the team to understand their work as a craft, and to help them reflect and improve on it. This person does not necessarily have to be an individual contributor (much like the scrum master). The craft master has excellent technical leadership skills, deep technical knowledge and keeps abreast of what’s happening in the world of “software craftsmanship”. The craft master makes sure that the team’s notion of quality and craftsmanship manifest in the Definition of Done, and brings the Definition of Done to the foreground as an integral part of scrum. …
Something I realised recently (which I knew in theory but ignored in practice) is that reminding teams that they are the ones responsible for quality (through incrementally developing their Definition of Done) is crucial.
Entropy is inevitable. Technical debt will accumulate as time goes along. At some point, technical debt becomes so much that teams will want to add “technical stories” to sprints. People start arguing that senior engineers should have equal footing with Product Owners about what goes into the backlog. “We have so much technical debt — we need to treat it just like any other story and prioritise it into sprints!” the team would murmur. …
Me and two friends started Glio in September 2012. By day Glio was a consultancy, offering website development (mainly with WordPress on LAMP) and graphic design services. By night Glio tried to be an incubator — we hashed out hypotheses and ran lean experiments, but unfortunately nothing sustainable ever emerged from these endeavours.
We finally shut Glio down sometime at the end of 2014. It goes without saying that I learnt loads during these two years. This post attempts to chronicle these learnings.
Many software projects take on the form of a transaction between vendor and customer. A transaction is an exchange of value. The vendor supplies software to the customer that solves some problem (scope), costs a certain amount (budget), by some date (schedule). The customer (hopefully) pays the vendor.
In any exchange of value, there exists the possibility of an unfair exchange. That is the situation where one party gains more value out of the transaction than the other for some reason. This possibility of unfairness is the risk associated to the transaction.
Typical contractual agreements between vendor and customer distributes risk in a certain way. …
There is a certain narrative that is prevalent in contemporary startup cultures. Its story goes something along the lines of “failure is good so long as you’re learning from it”. On the surface it suggests speed and adaptiveness: fast-moving iterations driven by a tight feedback loop calibrated to avoid waste (who wants to spend hours building something nobody wants, right?). I’ll be the first to admit: it sounded smart, tenacious and brave.
But this version of failure has a subtle consequence: stagnancy. All of a sudden the act of failing becomes a mundane event, just one of many more to come. Failure loses its power. It strips you of the ability to question the bigger picture. …
I’ve recently learned a lot about Ruby, and I’m also quite interested in R, a programming language for statistical computing. The book Exploring Everyday Things with R and Ruby naturally piqued my interest.
Overview of the book
The first two chapters does a quick primer on Ruby and R respectively, and does a sufficient job to get you up and running with both Ruby and R.
The remaining six chapters each tries to “explore” a question. …