Agile & DevOps Summit Brussels is a one day conference on agile practices and DevOps. In this post, I will take you along to the various talks that were attended.
Table of Contents
- Agile is (not) only for IT
- Agile Maturity
- How to bring Agile out of software sector
- What we wished we knew before signing up for Agile and DevOps Transformation
- Is Spotify becoming the new Xerox?
Agile is (not) only for IT
The talk started with explaining that all 12 principles of the Agile Manifesto can be applied to all layers of the organization, it’s not only for the IT department (hence the title). The Agile Manifesto enables everyone to focus on the same objective and towards the same goals.
In order to get everyone to focus, it’s important to know in what situation you are. To find out, you can use the Cynefin framework. This framework explains where you belong by differentiating between 4 different domains.
- Complex: non-lineair, never complete.
- Complicated: analysis is needed, a lot of possibilities, multiple possible answers.
- Chaotic: take action, dynamic, nothing is the same.
- Obvious: predictable and repeatable, one or few answers.
To take a real example: ‘Planning a birthday party for your child’:
- If you leave the children all alone the entire afternoon, you have no idea what happens during your absence or what the state of your house will be when you return: Chaos.
- If you plan the entire afternoon, with a timetable, to ensure that everything happens as planned: Complicated.
- If the children are obedient and don’t do anything wrong at all (not exactly realistic): Simple.
- If you set boundaries, rules, adjust continuously: Complex.
When you’re in a complex situation, you can apply the agile principles.
The other part of the talk was about the Agile Wave and how it affects other parts of your organization other than IT. If the IT department starts working according to the agile principles, there is always an impact on the other domains of your organization. For instance, if you have a team that goes agile, there’s an impact on items like budget, bonuses, costs, collaboration, estimation and so on. So the other domains need to adapt as well.
So agile is not only for IT because:
- Agile values and principles are applicable in all domains.
- Agile helps dealing with complexity, which is present in all domains.
- The roots of the agile principles originate from more domains than just the IT.
- The agile journey of an organization impacts all layers, not just IT.
The next talk’s subject was the issue of measuring agile maturity in an organization. Agile maturity can be answered with 3 questions:
- Why am I doing it?
- What am I doing?
- I am convinced about its outcome?
If you can answer those 3 questions as an organization, you’re already far ahead of others in terms of agile maturity.
To determine the maturity, discuss the following items:
- Context: You should know the context of what you’re doing.
- Team: What is your motto? Know your team to avoid turnover. Important values for a team: respect, trust and humility.
- Discipline: Agile requires much discipline, such as timeboxing, estimating, communicating with the customer, collaborating and so on.
- Infrastructure: Must be fast to react to changes. If it’s not, it blocks various agile processes. DevOps is obviously crucial as it will enable faster reaction times.
- Ownership: Taking ownership of what you’re doing. Never shift responsibility to someone else.
Bring Agile out of the software sector
This talk touched the same subject as the first talk, but had a bigger emphasis on why an organization should shift towards agile. There are some organizations that don’t like change, they’re not comfortable with it. Yet inevitably, everyone needs to adapt. In general, IT departments are used to change and quickly embrace it, but other departments might not.
The biggest investment that will be needed when transitioning is people’s moods and behavior. So it’s important to state why agile is useful and what the advantages are:
- Time to volume: It’s easier to respond to changes in requirements.
- Efficiency: People share and collaborate more, which decreases the amount of bottlenecks.
- Engagement: You can retain and attract more talent.
The process of change traditionally follows the Kübler-Ross model.
What we wished we knew before signing up for Agile and DevOps Transformation
Unlike the other talks, this one featured a panel discussion about what you should do if you want your Agile and DevOps transformation to fail. A discussion was had with 3 panel members and the rest of the audience.
- Just rebrand your middle management
- For example, instead of having a regular project manager, now you can have agile project managers.
- Ignore resistance and feedback
- It doesn’t matter what your employees think, the management knows better.
- Discourage experimentation and fire bearers of bad news
- Employees shouldn’t be allowed to try new things and if it’s bad news, everyone should ignore it.
- Don’t plan for productivity loss with new people
- If you add new people to a team, the team should be more productive right away, right?
- Add all agile ceremonies on top of existing meetings
- If we have more meetings, it means we’re discussing items and are productive.
- Do no take minutes, assign no actions
- Everyone remembers what was discussed and knows what to do, many days later.
- Don’t take metrics
- If we don’t see the problems, there aren’t any.
- Don’t measure anything apart from badging hours
- Obviously, there’s a direct correlation between badged hours and productivity.
- Do DevOps with Ops
- It’s a fancy name.
- Infrastructure should still be separate so it can be controlled.
- Create DevOps department to coordinate between Dev and Ops
- More control and coordination is better
- Ban teams from using their own tools
- Management knows best what tools their teams need, all teams need the exact same things.
To be clear, this list contains a fair bit of sarcasm.
Spotify becoming the new Xerox
The last talk I attended was a discussion about the agile model of Spotify that is becoming the new Xerox. The term ‘new Xerox’ is a reference to the generic trademark that Xerox became. When you talked about photocopies in the past, you would talk about Xerox as they were the leading organization in that area. Other examples are Bic, Sharpie, Croc and so on.
The speaker then started talking about the agile model that Spotify uses in The Good, The Bad and The Ugly terms.
- It helps to maintain a team’s autonomy and keep the various teams aligned.
- It helps to scale agile by using the concept of tribes, chapters, guilds, squads and so on.
- It’s a mistake that it’s called a model. It’s an engineering culture which typically cannot be mapped one-on-one to another organization.
- It was released 6 years ago, which is ancient in agile terms. It has evolved and might be completely different now.
- It doesn’t talk about management nor budgets. While agile is less concerned about this, it should still be mentioned if you want the management to follow.
- The context that was used by Spotify while creating this model is not the same as the context that is present in your organization.
The terminology that Spotify uses has some issues:
- Tribes: it sounds primitive.
- Squad: it sounds military.
- Guild: it’s a blocked evolution from medieval times.
To complete the talk, he explained the acronym CALMS that is used for DevOps transformations:
- C: Culture
- Empower your teams.
- Roles should be used instead of functions.
- T-profiles are the way to go.
- Failure should be allowed as long as you learn from your mistakes.
- Work together with the business to achieve the desired product.
- A: Automation
- Everything is code (config, code, tests and so on) and in the pipeline.
- Pay attention to things that can go wrong.
- L: Lean principles
- Constant flow of small changes.
- M: Measure to improve
- Inspect and Adapt.
- S: Sharing
- Learning from your peers.