As I’m working in frontend development my point of view might be a tad biased. The take-aways of this article should still be applicable to other professions.
You can’t escape agile nowadays. Be it in job offers, companies describing their way of work and very likely at your place of work too.
And that’s a good thing! Our world is ever-changing and becoming smaller, competition is becoming harder with more and more options for customers to choose from. It’s easy for a company to fall behind. And that’s where being agile is a must to keep up. Waterfall processes might still have their place in some niches, e.g. in construction work. But even those niches could probably benefit from agile ways. It helps to minimize risks.
So, what’s the matter?
I’m all pro being agile. I see issues though. On one hand Agile is often only used as a buzzword and on the other hand I think people misunderstand how to deal with the processes. For me, agile is a means to get work done and being able to adapt to changing requirements. All while focussing on shipping valueable tangible results to the customer as fast as possible. Being agile means being flexible, learning through experience and questioning the status quo.
If you’ve not read the Manifesto for Agile Software Development and its underlying principles yet, do it now to get more insights!
The Agile industry
Over the last decade an industry has developed around Agile and its methodologies. Companies and individuals started teaching others the trades of e.g. Scrum, Kanban or Lean. Working with one of these types of Agile flavours is certainly a good thing to do, because one can learn and experience the intentions better by applying them.
See how I’ve written Agile with capital “A” and agile? I recommend this article for clarification.
I consider Scrum to be a good starting point to step into Agile. You get a tested and tried set of rules without too much restriction. Scrum not only gives you a couple of agile ceremonies:
- the daily
- the review
- the retrospective
- the backlog refinement
- and the planning.
You’re going to have a board, define swimlanes, statuses and transitions. You’re going to estimate storypoints, look at burndown and other charts, etc.
You’re going to split workload into epics, stories, tasks and subtasks. And you’re going to organize your time in sprints. All in all, a very solid system.
Structure is good! Not changing structures is not.
And changing structures too early is worst.
With these structures, proper guidance from a coach (especially if you’re new to the topic) and some time, a team can increase its velocity from sprint to sprint, become faster and work better together.
That’s what I meant by saying that changing structures too early is worst. Being agile is an improvement cycle of the phases build, measure, learn. That principle I think applies not only to the way you’re building the product but also to how your teammates interact with each other and externals and how you adapt processes. Take your time to improve and don’t overhastily abandon structures. Because then you’ve just wasted the time until that point.
A retro for example is a good thing for a team in the forming and norming phases of teambuilding. Issues and conflicts are addressed in an open and safe atmosphere. Roadblocks can be solved by the whole team. In my opinion a retro should always end with actionable items.
In later phases and when your team has been working together for enough sprints, then you might start to raise some questions targeting those structures:
- Does a regular retro still makes sense if there are no conflicts and the team performs well? Isn’t the time better invested in other things?
- Shouldn’t conflicts rather be discussed and solved directly when they occur?
- Do we need all these statuses on the board?
- Do we still deliver value to the customer or are we more focussed on scoring storypoints and the burndown?
These are just some examples, you will surely come up with more.
When you’ve reached a point where the “traditional” approaches to Agile don’t benefit you anymore, then it is the time you want to deviate from the given and maybe also start working on your own agile solution. Agile is a tool and a tool should work for, not against you. Nor should you be spending valuable time on sticking to rules that thwart you.
Thanks for reading!