To be honest, I think the reason there's so much resistance to Agile in a lot of technical/infra teams is because it feels like a whole load of extra admin. No techie likes doing admin drudgery
True it's a bit like documentation.
Or meetings.
Agile working (none software)
- Thread starter theone8181
- Start date
True it's a bit like documentation.
Or meetings.
Sounds like there's lots of misunderstanding over what Agile is, which is reflective of the software development industry, especially in older organisations. A huge part of my job is grappling with this for a large company.
What I've learnt is that scrum isn't agile. Kanban isn't agile. Agile isn't a process that can be defined and adhered to, which is what most executives want sold to them by consultancies as that's the only way they can often think. It isn't something that can be easily scaled up, either. Scaling it kills it if you think of it just in those terms.
There is a big difference between Agile (with a capital A) and agility. Agile (TM) is what has been adopted by companies and consultancies as a way of working or process that can be sold to you with the promise of improving efficiency, lowering costs etc. Many companies exist just to sell this to organisations and it has created a whole industry around it.
Agility (small A) is a mindset and a set of values. Take a look at the manifesto for agile software development (unfortunately still using a capital A!). The values expressed here are old, but still relevant I think. If your teams can embrace these values, then you can become more agile and may see some of the benefits often claimed, such as improved quality, reduced time to market etc.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The thing is, nobody can tell you or your team how best to adopt these or design a process for it. The team must agree their own ground rules and continuously evolve this themselves by introspection, innovation and a continuous improvement mindset. There are some good places to start or draw inspiration from, but I wouldn't recommend a prescriptive methodology like Scrum(TM). Start with a simple flow based system with a backlog, chunking your work and getting better at estimating size and team throughput until you have some appropriate forecasting ability. Get closer to your customers, make sure you have an environment that allows you to get the best from every team member.
The most unfortunate part of this is that the real agility is not something that can be bought in or something you can tell your teams to do. With most company executives looking for an easy solution, the tendency is to attempt to buy this in or hire expensive coaches who will sell you their particular flavour of Agile (TM), which leaves most people in a worse state than where they started. I can't think of an organisation who decided to 'do agile' and either buy it in or follow a prescriptive methodology that I can use as a good example. There are, however, some organisations that developed it themselves and found that it could be great, but don't think you can just copy their methods as they most likely won't work for you!
EDIT: Worth also saying that my perspective here is one of software development. Other things can use some of these principles for sure, but if you try to say, use Scrum(TM) for contract negotiations or infrastructure deployment, you may find it even more difficult than something like a unified SDM methodology that would have been more traditional. Not saying it's impossible, but some methods are better suited to different things and only you and your team can figure out (by thinking or ideally, trying) what that might be.
What I've learnt is that scrum isn't agile. Kanban isn't agile. Agile isn't a process that can be defined and adhered to, which is what most executives want sold to them by consultancies as that's the only way they can often think. It isn't something that can be easily scaled up, either. Scaling it kills it if you think of it just in those terms.
There is a big difference between Agile (with a capital A) and agility. Agile (TM) is what has been adopted by companies and consultancies as a way of working or process that can be sold to you with the promise of improving efficiency, lowering costs etc. Many companies exist just to sell this to organisations and it has created a whole industry around it.
Agility (small A) is a mindset and a set of values. Take a look at the manifesto for agile software development (unfortunately still using a capital A!). The values expressed here are old, but still relevant I think. If your teams can embrace these values, then you can become more agile and may see some of the benefits often claimed, such as improved quality, reduced time to market etc.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The thing is, nobody can tell you or your team how best to adopt these or design a process for it. The team must agree their own ground rules and continuously evolve this themselves by introspection, innovation and a continuous improvement mindset. There are some good places to start or draw inspiration from, but I wouldn't recommend a prescriptive methodology like Scrum(TM). Start with a simple flow based system with a backlog, chunking your work and getting better at estimating size and team throughput until you have some appropriate forecasting ability. Get closer to your customers, make sure you have an environment that allows you to get the best from every team member.
The most unfortunate part of this is that the real agility is not something that can be bought in or something you can tell your teams to do. With most company executives looking for an easy solution, the tendency is to attempt to buy this in or hire expensive coaches who will sell you their particular flavour of Agile (TM), which leaves most people in a worse state than where they started. I can't think of an organisation who decided to 'do agile' and either buy it in or follow a prescriptive methodology that I can use as a good example. There are, however, some organisations that developed it themselves and found that it could be great, but don't think you can just copy their methods as they most likely won't work for you!
EDIT: Worth also saying that my perspective here is one of software development. Other things can use some of these principles for sure, but if you try to say, use Scrum(TM) for contract negotiations or infrastructure deployment, you may find it even more difficult than something like a unified SDM methodology that would have been more traditional. Not saying it's impossible, but some methods are better suited to different things and only you and your team can figure out (by thinking or ideally, trying) what that might be.
Associate
- Joined
- 5 Apr 2004
- Posts
- 1,215
To caveat below, as has been suggested by other people. Not all meetings require active participation, as some are essentially just relaying information where it's fine for you to play a passive role. (i'd argue some of these could be done asynchronously)
Also this is based on an organisation that recognises the value in teams owning what they do and have the autonomy to make decisions on how to organise themselves to achieve goals.
To clarify my points:
Respect - To actively participate in a meeting, shows respect to the person facilitating and to the rest of the team. (see engagement) If you don't feel like you need to engage in the meeting, perhaps because you think of it as being a waste of time, to me that shows a lack of respect. It also seems fairly pointless you being there.
Engagement - Turning up and playing an active part in the team. Contributing to what's being discussed in the meeting because you have shared team commitments, that you work collective to achieve.
Collaboration - see above around shared commitments
Associate
- Joined
- 5 Apr 2004
- Posts
- 1,215
And this is why I shudder when people talk about scaling frameworks such as SAFe or harp on about the Spotify model.
At least Scrum is intentionally fairly vague and has big gaps for you to work out yourself.
The goal becomes the application of the process, not the outcome that applying that process was originally meant to achieve.
Spotify still haven't put in features that have been requested for years and have a terrible UX, so not sure they should be held up as a paradigm for anything.
Associate
- Joined
- 5 Apr 2004
- Posts
- 1,215
Spotify still haven't put in features that have been requested for years and have a terrible UX, so not sure they should be held up as a paradigm for anything.
A quick reference if you're not already familiar https://www.atlassian.com/agile/agile-at-scale/spotify
Essentially the Spotify model describes how Spotify worked at a point in time. Something that had evolved to suit their needs and situation. Copying it because it might have worked for them, fails to recognise the journey they went on to get to it. Also it's just a point in time, so probably doesn't reflect who they are now.
I'm less bothered by the Spotify model as it doesn't try and address as much as SAFe does, which feels like neatly packaged controlled management of software delivery, to provide certainty.