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.

Why agile?

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?

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

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.

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.


Thanks for reading!

Hobbyist photographer, dreamer, UXer and DYIer