How Microteams Change the Way We Collaborate. Again.
Over the years, the way organizations and teams operate in software development has changed quite a bit. In this post we explore Sander Hoogendoorn’s talk on how organizations and teams doing software and product development can transition to focus on delivering value using the ever-evolving and self-organizing power of microteams.
A lot has changed in the last 20 years, and as time goes by, the speed of change increases.
In 1954 computers were the size of a car and only 6 were expected to ever be in the world.
In 1981 IBM PC 5150 came on the scene — the first home computer that you could program. You didn’t have to go to a huge computer that was somewhere in a data center — you could program in the office and at home; you could run your software in the departments you were working in.
In 2006 Amazon came up with EC2. You could now run software, run code, store data and everything else on someone else’s computers. You could run software virtually with the same power as the big banks with their huge computers.
With this rate of change, companies now face two big challenges:
1. Disruption
Speed of change — we live in a world where anyone can enter any market from anywhere at any time because everything is on the cloud
Time it took to reach 50 million users
2. 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
Cynerfim framework
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.
Shorter Cycles
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.
Beyond sprints
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.
Smaller Teams
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.
Communication
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.
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
Conclusion
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.
Takeaways
- 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
CONTENT
When It’s Time to Change, Then It’s Time To Change … A Talk on Adaptability
Temporal Modelling
Governing Agile Delivery
