AgileOrganizations

Projects, are to many people, the place development is done and where all focus should be put. With this approach the maintenenance activities are forgotten and/or reduced into something that is only a cost. This is a real problem and the root to many evils in organisations today. The reason is that by its very definition a project has a start, a pre-planned life and a closure/death. In fact this approach very often hampers the possibility to financially motivate efforts in automation, retrospect, reuse and continously improve processes between projects.

A product can be created, continously changed and ultimately phased out based on what value it brings to the company. The lifespan is much longer than a project, naturally so because a project is a major change in a products lifecycle, but only that. Which means that automation, retrospects and reusability makes more sense in a financial perspective. Continously improved processes are also much more relevant because they are not only paper tigers but a very tangible assets supporting change and live outside the any project. Examples of product oriented assets are automated regression test suits, environment provisioning and known risks with mitigations. Since these live outside the project they can and should be reused and actually gives the company tools to govern the project improving the delivery of any project.
Another benefit is that since a product needs to motivate its existance in added value, any changes made to the product should be possible to quantify in added business value.

Agile practices are focused on maintaing a product in evolutionary steps, iterations, based on a known baseline i.e. assets in a deployment pipeline. This means that maintenance is elevated into the new normal where you engage in smaller or bigger changes that can be done in the form of projects, or not. In essence Agile development practices are really an advanced form of maintenance work and projects specific changes where you actually can specify in some detail the outcome.
From a funding perspective looking at Agile as an advanced maintenence activity makes more sense since you have similarities like not knowing the actual outcome, having a line organisation over time supporting and maintaining all forms of assets and experiences.

There are certainly situations where Agile engagements are best suited and also situations where traditional projects are best suited. In any case, development can be benefitted by the guardrailes created with a product perspective on the lifecycle.

There are a number of people coaching teams and groups of teams to better utilize Agile practices and improve their daily work. The focus is improving coding practices and make the deployment pipeline as effective as possible. There are less people focusing on coaching business people and IT people to better collaboration using Agile practices and mechanisms. Since transparency is a fundamental piece of Agile developement the information available can and should be used to keep everybody informed. The approach to communicate through prioritized lists is an excellent way to involve business people in prioritizationed needed to accomplish the objectives. Today, too often, prioritization is done by the wrong person creating distrust between parties. Examples of this can be found when business prioritization is in fact done by IT since a requested change is affecting multiple systems with different stakeholders. Likewise there are situations where business are taking IT decisions when specifying the solution too much, not leaving room for IT to add their expertise and experience.

The coach needed here is someone who can talk both to business people and IT people and creating interfaces that are accepted by both parties. I call this role an Enterprise Agile coach focusing on business – IT collaboration external to development teams.

For an Enterprise Agile Coach to be effective there needs to be a known baseline of practices, supported by technology and services, to continously discuss and evolve.

What does Agile really mean?
Especially when a company says they want to offer Agile tools and services?

Too often the answer is that the company want to capitalize on the word Agile implying that they do things quicker and more reactive than before and the competition. They do NOT base the statement on Agile practices evolved in Software Deveopment but simply focus on speed improvement and cost reduction as a result of using their tools and services. If you look in a dictionary that is a fair interpretation, but it is only a small part of what Agile development practices based on the Agile Manifesto really is. Hence the word Agile is often reduced to just another buzzword…

The essence of Agile software development based on the Agile manifesto is increased collaboration, open dialogue and releasing decision-making down to the individual/team that is closest to the problem. By doing so, there will be a very high level of transparency and this drives trust amongst all involved. If you have trust in your collegues making the right decision at the right level you can be very reactive and responsive to change. This will most likely NOT be because everybody works faster according to a set plan, but rather they will be able to decide only to do the things that generate identified value.
So, the irony is that Agile software development is faster because you do less (but smarter), not everything faster…

At present Agile development practices are found mostly in IT development organisations but closer collaboration, better transparecy and trust is very relevant in all organisations.