Everybody seems to be doing Agile these days. Start-ups do it, big organisations do it, all the cool companies do it. That’s even how autonomous cars are being developed - the agile way. Even though it’s been agreed that ‘there’s no silver bullet’ in software development, well, apparently there must be and it’s Agile. Right?
Don’t get me wrong. I love Agile. And that’s exactly why I hope it will never turn into Coldplay of software development. Sometimes it seems that Agile is becoming this crowd-pleasing, catchy thing, that slowly loses its meaning. What does it mean to be agile these days?
I am not Kent Beck to be a judge on this one, but I guess it’s safe to say that you do not become agile just by doing the Stand-ups or talking about velocity and story points. You do not become an agile company by making everyone do their Scrum certificates or changing their positions’ names from Project Manager to Scrum Master etc. I hear ‘A Sky Full of Stars’ in my head when I write this.
It’s tricky to even focus on the term ‘Agile’ itself when there are so many Agile-related terms these days - you have squads, you have definition of ready, MMF, release trains… The thing is, it can be quite overwhelming. And it can impact the ability to communicate. We can make laugh of the big corporations having their own slang for everything but the same thing can happen when you overdose the ‘good’ terminology as well. Agile is about simplicity after all. And doing Scrum or Kanban is not what the software development is about.
“Individuals and interactions over processes and tools”
And honestly, it concerns Agile processes and tools as well. They can support the team to achieve their goals but they are not the goals in themselves. If Burndown charts and Fibonacci sequence-based story points become one of the things the team feels it needs to deliver rather than use as a support, it can mean that something’s not quite right.
“Working software over comprehensive documentation”
Even the agile one.
Kjell Ljostad during his presentation at Beauty in Code 2019 said that doing the actual methods, like Scrum or Kanban, is something that you grow to. I think you can develop that to: you need to grow into needing them. The place you should start at is the Agile Manifesto. Then just be reasonable and thoughtful - what is it that your team, your stakeholders, need? If it is the whole Poker Planning and Burndown charts shebang, then great. If it is just the shift to working closer with the client and delivering software in small increments (whatever you want to call them) at first, with the Agile Manifesto pinned to your board, then that may be great for your team right now. I guess the main thing is to adapt and evolve as your team does.
“Responding to change over following a plan”
In every aspect. Not just specification and requirements.
And then, there’s a client. Who cares about the value he or she is going to get from the system. The real value. The impact the system will have on their users and the return of the investment. Let’s get to know his or her needs, no matter if he or she knows how to work the Agile way. If he or she can prioritise the User Stories upfront. Because that’s what the Agile is for.
“Customer collaboration over contract negotiation”
And that’s just it, really. I believe in Agile, even the one before the actual term ‘Agile’ has been coined. In its early 60’s forms of just ‘delivering in iterations’. Because it asks you to be a reasonable, organised and empathetic human being. And then choose the right tools. I think that’s how we do Agile at Bright. We can call it Bright Agile. And, come to think of it, maybe we can make people do certificates on it… ;)
P.S. If you love Coldplay, then sorry for this. I really liked “Parachutes” though.
Originally published at brightinventions.pl
By Katarzyna Łukasiewicz, Project Manager @ Bright Inventions
Email
Top comments (0)