AgileOrganizations

Most people outside the Agile communities, and sometimes within the community as well, think that Agile practices mean less control and more freedom for developers to do whatever they want. To some extent this is true since Agile practices prescribe self-organizing, autonomous teams that pull activities to do rather than accepting accepting activities pushed to them.

Looking at Agile methods and practices the focus is always on transparency, collaboration and trust between all parties. Combining that with every persons ambition to look good to his/her peers there are actually some very powerful tools to use, such as dashboards and reports. Therefore, transparency management is very important and must be connected to a vision/mission statement which needs to be accomplished.

Using the analogy with infrastructure for traffic. It is essential that there are roads and feedback systems to guide drivers. Nobody directs people how/where to drive, it is up to the individual but in order to get to the destination safely and as fast as desired, the driver need to leverage existing infrastructure the best way possible. Likewise in software development, the teams/individuals do have freedom to a large extent but they have to stick within existing infrastructure such as testing, environment provisioning and reporting. If they do not, they will not be able to deliver real value and their peers will look at them in a negative way.

One concept within Agile development practices is especially important to distinguish teams/organizations that have adopted not only the practices but also the culture and mindset needed to be fully Agile. This is the concept of having engaged teams/individuals pulling new work rather than having work pushed at them.

People can be interested and have ambitions to control their own work load and work directions but if they feel somehow threatened making decisions they will hesitate or refrain from making them. Those perceived threats can be anything from individual managers working in a control and command fashion with their own agenda to company supported policies enforcing lengthy approval processes. Both examples remove trust in the individual and sets the expectation that the company need protection from the individual contributor.

The contradiction here is that Agile practices should be fully transarent and the mechanisms are there to support transparency. So, in fact the level of control, or rather using the word insight, is much higher than in a phased approach where you rely on peoples perception of progress instead of having tangible working code.

The mindshift from control and command to servant leadership is fundamental and effects most practices. If the team is self-organizing and decisions are made at the lowest level there must be room for teams to make their own decisions.
One example here is how training is presented. Traditionally we have created solutions to problems and then tried to convince teams that this is the best way to solve the problem.

Instead we should provide teams with a smorgasbord of services and tools for them to try out and make their own, to solve their specific problem the best way possible by them. The teams should take ownership of the solution and not spend time challenging someone elses approach. With that said, we do not want numerous different solutions to the same problems. As for any good smorgasbord you need recommendations finding the best stuff, but the final decision is yours.

Technical debt is a concept used in Agile practices to identify actions not done, completing a full implementation of a functionality. This is a consious decision made to be able to showcase progress made within the iteration with the intention to fix this in coming iterations if prioritised. The reasoning behind having technical debt would be to, as fast as possible, drive the dialogue between stakeholders and implementors about development direction. The speed increase found in Agile practices is very much due to what you leave out as not necessary not that you work faster.

The concept of technical debt do not remove following Definition of Done, DoD, delivering working code in the end of the iteration or allowing for a phased approach of delivering a large change similar to traditional waterfall thinking.

I would argue that Agile outsourcing is different from most forms of outsourcing being offered and delivered today. Refering to the Agile manifesto in determining how the word Agile should be used in this context it implies leaving a lot of decisionmaking to the autonomous teams in the Agile factory. This contradicts a typical approach of delivering a service from an external provider where the buyer defines what services they want and detail how it should be delivered.

Most ‘Agile’ service deliveries are based on expected delivery and contracted that way to fit common SLA’s and procurement processes. To really benefit from an Agile factory outsourcing approach the need for control needs to be minimized and trust maximized. To do this I suggest exploring relational contracting models.

Internet of things, IoT, automation and robotics are examples of when machines are making decisions that will affect the commercial relationship between two parties.
From a technology perspective this is opening up a number of new possibilities and potential solutions to problems we do not necessarily know we have.

The backside though, is the legal perspective and how this can be used both on a private level and on an organizational level. From a speed perspective there will not be time to actively approve decisions made and accepting potential outcomes of these implicite contracts.

I do not think our society is ready for this even if the technology already exist!

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.

Most of our contracts today focus on a specific transaction and tries to identify risks and the owner of those risks. It also stipulates what happens if those risks are realized and potential penalties. So, such transactional contracts manages a predefined delivery and the following potential blame game of not following the initial plan.

In Agile software development you are not making big upfront specifications, instead you are defining objectives, work together towards those objectives and where you end up delivering is the result of the collaboration. Hence there is no specification to write a contract around. This is a common situation using Agile development practices and especially when using external services providers. Innovation is a similar thing where you can not know what the end-result would be and therefore can not write a contract managing the transaction in detail. Both these scenarios challenge the way the commercial relationships are managed and how contracts are written.

One way to be better equipped to manage Agile development and innovation is to focus on how people are working together. Work out how the cultural landscape should look like to promote creativity and collaboration. Considering social norms and how culture affects communication and trying to put it into writing. Contracts would then be used to manage how iteraction and collaboration is happening to drive trust between stakeholders. This approach is often called relation contracts and one example is the open source initiative vested.