Going Agile

It seems like these days Agile is everywhere. Everybody’s doing SCRUM, every team seems to work in sprints and we put all our backlogs in JIRA. From startups to corporate giants, everybody’s on the bandwagon. Or so it seems.

You see it doesn’t matter if you’re working in sprints of 2 weeks if you’re only releasing software every 6 months. And it also makes no sense to pay for your JIRA server when all you’re doing is putting your Excel sheet rows in the backlog.

That’s not at all what Agile is about. Yet, for many teams it’s become a reality. Nevermind the Agile manifesto, do what you’re role in the SCRUM team prescribes and you’re good.

Uh, no you’re not. In a market that is oversaturated with advice on how to set up your ideal Agile process that fits your company perfectly I think it’s time to realize that for Agile to work you need to change your own thinking. About your market, about your products and how you actually make people’s lives better. (I mean, do you actually make people’s lives better at all? – think about that)

I start this series of blog posts with a sole purpose: to go back to what it means to be Agile. Building your business and development processes in an Agile way needs a solid foundation. So we’ll build that first, the rest will follow quite naturally after that.

So keep an eye out. I’ll be covering the basics of Agile, some simple tools and some best practices along the way. In the end it’s quite simple to do “the Agile thing”. But it’s a lot harder NOT to do the traditional, familiar thing (that was hurting your business in the first place).