“I’ll share a video with you, Kallia”, said a brilliant colleague of mine when mentioning how happy I was about booking my ticket for the Agile Summit Greece. “It’s called ‘Agile is dead‘ ”, he said.
I think we can all agree that agile is an over(ab)used buzzword and a misinterpreted concept these days. Similar to that other popular concept, productivity. Well, inspired by some of the thought leaders in the field, I think and dare say that agility is a way of approaching work (and also life, why not?). So, bear with me and I’ll explain why.
How to (not) be agile at work
Every organisation nowadays wants to be considered lean and agile. So we tend to talk about the Agile Manifesto, spread around copies of the Lean Bible (which talks only about success cases, while if you think about it, the real learning comes from failures), or study the black and green book. This one explains every tiny detail on the best approach to use scrum. Which, by the way, is just one of the ways to introduce agile in software development organisations. Not a panacea.
We read those books and also tons of articles and case studies and then try to follow them. That is, we, sometimes dogmatically, follow methodologies and adopt agile practices in the exact way our sources describe or explain that we should. Most of us then face an overhead in our daily workload, which brings in resistance to change. Or, we end up introducing almost bureaucratic processes and micromanagement and fail to really introduce anything lean or agile in principle. And even if we are self-aware enough to realize it, we might end up blaming the knife for the murder.
To challenge and twist them…
Don’t get me wrong, good books are of the most valuable and timeless resources of knowledge we humans have. And we do still read, which is good. I was pleasantly surprised to see that I am not the only romantic one that still needs the paper. In an auditorium of nearly 500 people, when the question “how many of you still read real books” popped up, most of the hands went up in the air.
Plus, I’ve always loved frameworks and theories, as well as methodologies and tools. I find that they are the best way to set a common ground within a diverse team of people with different backgrounds, experiences and values, and work as a great conversation starter towards any goal you’re trying to achieve.
The agile way to do it, though, is to challenge and twist them, so that they serve your needs, instead of falling into the trap and becoming their servant.
During the summit I had the privilege to discover and learn how others manage to achieve this in their teams or projects. So, here are some ideas on how you can find your way out of the trap as well.
Estimate only if it adds value
Use the parts of a methodology that make sense for you and your team. For example (and if you are using scrum at work you will most probably relate to this), estimating a task a lot before you get your hands on it can be painful. Well, don’t. If you’re spending a lot of energy or time estimating tasks, without it adding any value in your work at the end of the day, then stop doing it.
Roadmap planning, and then trying to hold the team accountable to it, might work better for you than exhaustive planning and estimation exercises. This doesn’t mean you’re not agile. And what’s wrong with tasks every Monday moving on to the new sprint? They are just a prioritized list of tasks, after all. And regarding story points, it’s okay if you only see them as a way to get the team aligned and on the same page. They can serve as a tool to have the same perception of a task and the work behind it.
Agile is hard, because it’s always different. If you do it more than once the exact same way, then you are not doing it right. Your goal should be everyone being on the same page, working on the right thing, on the right order and time. Following scrum by the book is not agile. So, if you’re not getting value out of it, then why do it?
Oh, and don’t take my word for it, this is coming from Jon Kern, one of the knights of the Agile Manifesto.
Don’t be a copycat
Don’t copy models just because they have worked for others in the past. Because those others aren’t you. And because we live in the present. For example, as Marcus Hammaberg pointed out in a fire-chat between sessions, learn from but don’t try to copy the Spotify model. It won’t work for you unless you’re Spotify back in 2012. Chances are that it isn’t working for them now either, they have changed and evolved.
And also, as Linda Rising, my new role model, pointed out on the last day, there’s not one way that is best or that everyone should follow:
How do you know that the agile that we know now is best?
If you say that everyone should work the same way we are going back to the Industrial age @RisingLinda #AGRS2018— Marcus Hammarberg (@marcusoftnet) 21 September 2018
So, don’t expect to find the way. Experiment and try to find your way. And bear in mind that it won’t last forever. The problem you’re dealing with changes, your team changes as well, your field evolves. So you need to find a model good enough to embrace change.
There are no best practices
Also, as my friend Lisie very accurately put it, there are no best practices. There are only some good practices that you can adjust and tweak in your context, so that they can match your situation and serve you properly and effectively.
It’s all about people
Your people are more important than a handful of agile practices. As placed in the opening keynote by Michael Feathers (although in a different context), you cannot motivate code towards better behavior. Base finding your own agile way on the dynamics of your people and the nature of your work. Bear in mind that it all comes down to people. And culture. It’s all about getting the best of everybody, not the most.
That said, unless your starting point is embracing principles like trust, transparency and accountability, then you’re not doing it right. Moving authority to the information, reducing hand-offs, limiting work in progress (I should remember this next time I engage in multitasking), practicing humbleness and self-awareness (practice is a keyword here). How many of them can you and your team tick off this checklist?
Schedule time for play
“Playfulness, doing things just because they’re fun and not because they’ll help achieve a goal. Includes anything that makes us lose track of time and self-consciousness. It’s not just an escape. Done well, it is a pause that refreshes us and creates the clearing where ideas are born. It wakes up our creative self. So, always remember to find some time for play.” Credits and kudos go to Brené Brown for this beautiful definition.
So, when was the last time you engaged in something fun, flexible and freely chosen, with no particular reason or goal? Something that made you laugh out loud until your belly ached. As Portia Tung suggested in her ending keynote speech at the end of the first day of the Agile Summit Greece, unleashing our brain and giving ourselves permission to play is the first step towards a healthier adulthood. And to take this one step further, we should create a safe environment for people to be able to play while at work. Because people who play together stay together. And we do want our team(s) to be happy and stay together, right?
Remember that:
“We don’t stop playing because we grow old; we grow old because we stop playing.” -George Bernard Shaw.
Final thoughts and a note to self
Agile as a concept is misinterpreted nowadays. The spirit of being agile has been lost behind a mountain of process. The agile movement is in a crisis, fighting for the essence hidden between the buzzwords.
What is of vital importance, after you’ve trained yourself a bit, is to step out and look at the big picture. Of course we need to read, listen, study and be informed. But, we also need to be resourceful and mindful of our own team, product, needs, situation, environment, you name it. Agile starts at personal practice. Observe, sense and then experiment. Just don’t go by the book, don’t adopt things uncritically.
Always be a student. Who here has stopped learning, anyway?
First published on Medium, on Sep 24, 2018