In the afterglow of the Frontend Developer Love Conference in Amsterdam last month, our development team got inspired to share with you some insights. Every week we’ll post one article, in a series of 5. So stay tuned for more!
In this first article we’ll zoom in on Sander Hoogendoorn’s talk. He is an independent software craftsman.
“How thinking small is changing software development big time.”
Sander Hoogendoorn
The world is changing fast and with it, technology is evolving at a crazy pace. The market is diversifying and competitiveness is higher than ever before. The last couple of years, we saw many companies entering markets that were not their base ones. Think about Facebook introducing its new Libra cryptocurrency or Apple creating a credit card.
But what does that mean for the IT world and for us developers? It means that we must deliver faster to implement new features all the time. More and more companies are consequently migrating their waterfall projects to agile projects.
The real question is, how do we cope with change in IT then? Well, badly. There’s always something we need to refactor, migrate or change in the code. Scenarios weren’t foreseen, time was lacking, the pressure was high and deadlines were short. We’re busy with features that, most of the time, are not really needed. As we’re almost all working in agile projects and teams, features are picked up and implemented asap because that is what agile enables. But at what cost? You’re sacrificing quality over quantity. It is how the fast market and evolution makes our code go obsolete, faster than ever before.
Where did it go wrong?
The description given above hits close to home for many developers. Sander Hoogendoorn calls it “Product Owner Driven Development” and it’s the main reason why we’re not producing sustainable code. It seems that organisations automatically assume that just by going agile, Scrum, Kanban or other similar approaches, applications will be built in less time. It’s an overoptimistic approach. There are many factors that can cause trouble and aren’t rare. In fact, they happen in every single project: under or overestimates, weird bugs resulting in delays and changing requirements.
How do we fix it?
At this point, you might be thinking why do we still do agile projects? It is important to realise that simply not all projects are fitted for the agile methodology.
We’ve learned about the Cynefin framework, a simple yet effective method to check whether your project is fit for agile development. There are five decision-making contexts and agile is suited best for Complex situations. You can also use it for Simple projects, but it will surely be an overhead. Complicated projects can sometimes be fine with agile, but the deadlines need to be flexible as that type needs a big part of expertise, sometimes not foreseen in advance.
However, the problem is still there. How to improve the existing agile process? Sander tells us that it comes down to a couple of very simple points.
Deliver smaller features
What we need to do is to be able to deliver as soon as a feature is finished in order to be in a real continuous delivery model. Even more, the features need to be broken up into smaller parts and seen more like problems, in a mathematical way. Solving one problem per day is a good milestone to have in that context and gives more satisfaction to both the teams and clients.
Work in shorter cycles
In ‘waterfall’ times, it was common that it could take several years to complete a whole project. Problems remained undiscovered until very late in the process and failing projects, therefore, cost a lot of money. Then, scrum and agile arrived and introduced two-week Sprints. It was an improvement but what would you say if that period was even shorter? Impossible?
You don’t need to put a fixed amount of days for a set of features or estimate every task in hours. Estimates are almost never met and result in a “red-spring anti-pattern”. Sprints as we know them don’t add any value and often end up in burnouts, loss of developers’ motivation or other issues.
How can we speed up the process without having too much on our plates? The answer is automate.
- Use existing DevOps practices
- Automate your tests, like unit or UX/UI, as they’re the most time-consuming part of the work
- Test from day 1, don’t wait days or weeks to run the tests
Then, when tests are succeeding, just deliver. Once again putting the emphasis on delivering continuously.
“Fail fast, fail forward.” – Sander Hoogendoorn
Have smaller teams
We have to take the available resources into account: they’re actual people, so not available all the time. People get sick, go on holidays or have personal obligations. And the more people there are in a team, the more issues can occur with communication and coordination of everyone’s work.
Many managers seem to think that having more people in a team will improve the delivery time. While this can be true in the long run, if the team isn’t too big, the direct effect is a loss of productivity as the team goes through an adaptation period.
Another pain point of agility is the number of rituals the team has to go through. The bigger the team, the longer they take, even though the value they bring goes down in consequence.
To solve these problems, the first step is to have polyvalent people. This way, the project can still progress without being stuck because some members are away. Having this as a basis makes it much easier to divide a big team in little groups of three or four people to tackle small tasks as foreseen in the first point. Smaller teams will be able to keep the communication simple and straightforward, eliminating the burden of too many time-consuming and useless meetings.
“Traditional agile doesn’t solve modern issues.” – Sander Hoogendoorn
Rethink the work schedule
Do you sometimes feel like your productivity doesn’t really match your work schedule? Many of us do. Development is creative work and creativity is not a constant flow.
We need more flexibility with our schedules. Employers need to trust us with our work because 9-5 is clearly an overrated standard that needs to be left in the past. We’re all checking our emails in the morning, but wouldn’t it be great to do it at home or on the train and having that time counted? And by doing that, we would probably solve correlated issues like traffic and commute related stress.
Allow people to self-regulate, it’s important and it works. It makes our lives better and our happiness higher, therefore, provoking fewer burnouts and generating more productivity.
What’s next?
How will Agile evolve in the future? Will it stay as it is? Probably not. Ten years ago, methodologies were very different from today. With that in mind, we can only assume that they’ll evolve again. It is far better to solve a simple problem every day than wait until delivery.
