Skip to main content

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]


  1. IEEE Final Year projects Project Centers in Chennai are consistently sought after. Final Year Students Projects take a shot at them to improve their aptitudes, while specialists like the enjoyment in interfering with innovation. For experts, it's an alternate ball game through and through. Smaller than expected IEEE Final Year project centers ground for all fragments of CSE & IT engineers hoping to assemble. Final Year Projects for CSE It gives you tips and rules that is progressively critical to consider while choosing any final year project point.

    Spring Framework has already made serious inroads as an integrated technology stack for building user-facing applications. Spring Framework Corporate TRaining the authors explore the idea of using Java in Big Data platforms.
    Specifically, Spring Framework provides various tasks are geared around preparing data for further analysis and visualization. Spring Training in Chennai

    The Angular Training covers a wide range of topics including Components, Angular Directives, Angular Services, Pipes, security fundamentals, Routing, and Angular programmability. The new Angular TRaining will lay the foundation you need to specialise in Single Page Application developer. Angular Training


Post a Comment

Popular posts from this blog

Agile: So who's the team manager?

People often call agile teams “self-steering” teams or “self-managing” teams. But surely someone must steer the team towards a long term goal? And how about activities that are typically performed by a department head, such as daily operations, coaching, coordination of vacation days, and employee performance management? The answer to those questions is, as with many things, “it depends”. It depends on the management activity and how far along the organization is in adopting an ABOK (Agile Body of Knowledge) way of working. Let’s first zoom out before we zoom in. Traditionally organizations are divided into silos. The division can for example be based on market segment, or geography, but is usually based on the activities people perform. So usually, IT people are pooled in the IT silo. If we look at such a traditional IT department, then within that silo there is usually more compartmentalization; such as a software development team, a network and system administrations team, a

Agile: planning part 1. Hours versus story points

After I prepared a post about agile planning, I found out the post was becoming huge, so I divided it into three posts: Estimating Short term planning Long term planning This first part is about estimating user stories, adding to the debate of hours versus story points. A lot of project managers who are involved in agile projects see a story point as a measure of time, often using the equation “1 story point = 1 hour”, while on the other hand an agile method like scrum teaches us story points are a measure of effort or complexity, and are at most loosely coupled with time. So should we estimate using hours or estimate using story points? Let’s first build the case for using story points: It is very hard to estimate how long something should take, but it is less hard to estimate whether something will take more time or less time compared to something you know well. To aid the estimating process scrum introduced story points. Story points aren’t a measure of time, but are a