Agile: not "just another way of doing the same"

Despite being decades old agile is hot and is being introduced and implemented in many organizations which is great. With this post I'll very briefly try to explain that agile however is not some plug-in replacement of current ways of working. You can of course take an existing team and start scrumming with them, and it may lead to improvements, but you will not reap all the benefits. In order to be agile, you have to understand the agile concepts. Those concepts may be obvious, but in the daily madness people tend to focus on the wrong things. Think about this analogy; I use the train for my daily commute, and if you ask the employees of the Dutch Railways in what kind of business they are, the majority will tell you that they are in the railway business, while in fact they are in the people transportation business. This illustrates one of the driving forces behind agile: with everything you do, you should ask yourself who you’re doing it for, and whether there are ways to serve that person even better. Agile is not just another way of doing the same, and agile in itself is just a means to reach your goal of sustainable customer satisfaction. How you reach that customer satisfaction is by being able to change, and one big step towards reaching that is by producing work in short cycles.

Speaking of agile, when I write agile I actually mean ABOK; the “Agile Body of Knowledge”: best practices from fields such as Scalable Agile, Scrum, DevOps, and lean 6 sigma, comprehensively abbreviated to Agile.

So how should you take steps towards implementing an agile way of working?

Don’t take an existing team, and hire a scrum master to manage that team. Why not? Because most likely your current team composition is based on the type of work they do. You might for example have an infrastructure team, or a user interface design team, or a functional application management team, etcetera. Those teams might be good at what they’re doing, but by having those specialized teams you have to solve alignment issues, you have to translate requirements between those teams, and the teams are likely to be more focused on their own challenges than the customer’s wishes.

So you should create a new team that will be end to end responsible for the whole value chain. On one end of the value chain that means the team receives the end user feedback, leading to better understanding of customer wishes and problems they encounter. This also leads to pushes for advancements like Application Performance Management, production pilot deployments for specific users, etcetera. On the other end of the value chain that means the team is responsible for the operations of the products. This leads to pushes for things like easier (automated) deployments, better monitoring, and high availability. In short: if a problem arises, it is the teams responsibility to fix it, they will not be able to point to another department to fix it, nor will they have to wait for another department.

Since business knowledge is important for such a team, you should invest in a good product owner. This product owner must be a subject matter expert, so have good knowledge of the whole value chain, and should have affinity with IT. The product owner must also be mandated, so whenever the team has to make a decision, then the product owner has the authority to approve that decision. And, this product owner must be available for the team.

Being a product owner is an intense job, it is not something you do on the side; a full time product owner can have at most two teams but a product owner dedicated to one team is a good starting point.

So don’t think lightly about introducing agile, get expert advice and don’t stop short, it would be a shame if you wouldn’t get the full benefits!

--
Kenneth van Grinsven

[This article was first posted on LinkedIn Pulse]