Time it took to reach 50 million users
Legacy Usually defined as ‘the stuff that works’ but really comes with a number of disadvantages including:
Code grows organically over large periods of time Standardization is limited Tech diverges rapidly Frameworks and operating systems are versions behind Automated tests lack Maintenance becomes harder Time to market is too high Innovation is tedious
The dilemma zone
The zone in which you need to decide when to stop adding new features and stop building on top of what you have and make the jump over to newer technologies in order to not get left behind and overtaken by emerging startups.
Over time, developers are continuously inclined to add feature upon feature onto code bases and neglect to change their architecture, coding standards and automated testing. If you don’t innovate, new companies will take over your business.
How to jump the dilemma zone
It’s scary to jump through the dilemma zone, so what do you do?
Continuously optimize for speed, agility and adaptability by learning by doing — experiment, find out what works and what doesn’t by seeing the world as a large collaboration of small movable parts that consists of four things:
Deliver smaller features No more doing projects — deliver smaller stuff more often.
In even shorter cycles Continuous flow — scrum cycles of 2-3 weeks aren’t short enough, they need to be a lot shorter.
With even smaller teams Self-organizing and autonomous — organize yourself beyond being agile, organize in ways that you can continuously supply value to the business, not every 2/ 3 weeks (which is not continuous).
In even smaller components Microservices and serverless.
Delivering smaller features
In short, the Cynefin Framework is a way to model where you are as an organization or team, containing four zones:
Obvious zone – you have a problem → you have a solution → you fix the problem. This is considered to be the ideal zone, but very few companies find themselves here, almost none.
Complicated zone – multiple good practices, but no single best practice.
Complex zone – you know the direction → take small steps → get further down the road. By experimenting you can get two outcomes: it works or you change direction.
Chaotic zone – no practices, nobody has done this before. Where do you go? You don’t know if the experiments you take are going to be successful.
Most companies find themselves in the complex or chaotic zone. Planning doesn’t work because we are continuously jumping the dilemma fence. Small steps are the fastest way forward — stop doing projects.
Scrum ≠ Agile: Scrum doesn’t mean you’re being agile, it means you’re implementing an approach to do stuff in cycles of 2-4 weeks.
Agile ≠ Scrum: you can easily be agile without doing anything from scrum.
There is no relationship between one or the other.
Becoming a master of a discipline takes on average 10 years of daily practice. Yet you can take a 2-day scrum course and be called a master of scrum. A lot of people take the course and come into the industry hitting the ground running, quickly realizing there is no shortcut to mastery.
Every discipline requires practice, including developing software, and a lot of new scrum masters realised that quite quickly.
With enough experience and practice you eventually realize you can continuously improve the way you do things beyond doing sprints — sprints are basically mini projects — there are more efficient ways of doing things.
The evolution of cycles
Waterfall – single cycle
RUP – 4-6 months DSDM – 4-6 weeks Scrum – 2-4 weeks Continuous Delivery – same day Continuous Deployment – multiple times a day
The Agile Manifesto
The agile manifesto didn’t specify delivering software in cycles of any number of weeks
, but rather early and continuously.
To deliver small with a continuous flow:
Pick a piece of work and find the fastest way to put it into production Automate everything with pipelines that run with every code change Automate in small steps Test everything from day one
Test from day one
You need to have unit tests for everything you do — automate your tests and fail fast to get feedback as fast as you can.
IT has become the core of everything, IT people are everywhere — they’re in every industry and, as a result, there’s a shortage of developers.
This means if you’re in a team running a project, you need to grow your skills beyond the small area of expertise you have on a particular language, framework, architecture or testing technique.
As developers, we’re generally introverted, communication is hard, and to try combat this we’ve created too many meetings when
we don’t need more communication, we need better collaboration.
Clear communication is key to better collaboration — better collaboration comes from working in smaller teams — if you work in a smaller team of three, it’s much more efficient than working with a team of 10.
Team of three Three lines of communication Team of five 10 lines of communication Team of ten 45 lines of communication
Autonomy at work
Being able to decide what to do, how to do it, when to do it for yourself and not having a manager deciding this for you is really important. But self organization is hard and out of many people’s comfort zone. A good way of making this easier for people is to introduce fewer rules.
The fewer rules you give people, the more they need to pay attention to their environment, to other people and to other teams to see how they are working to see if you can interact.
We’re not good at estimation
In complex and chaotic zones (mentioned earlier in the post), you’re constantly experimenting and can’t plan what’s going to happen, making an estimate is impossible.
How do you estimate something that you (or even anyone) have never done before?
You don’t, and if management asks, say you’ll prioritize the most important items first.
Think for yourself
Don’t just copy someone else’s model. What works for someone else won’t necessarily work for you. And even if a certain model worked for someone at one point in time, the likelihood that it still works years down the line is pretty low — think for yourself and adapt as you go.
The only process you really need:
1. Pick a small problem
2. Form a small team 3. Discuss 4. Do the work 5. Mark as done 6. Disband small team 7. Go home 8. Repeat next day
Most of us find ourselves in either chaotic or complex contexts, that means experimentation is key. No more waterfall and no more traditional approaches. It means making everything smaller and shorter: shorter cycles multiple times a day in smaller teams building smaller components.
Solve one small problem every day Small steps are the fastest way forward If you get stuck, take smaller steps It only takes one person to start change