AgileOrganizations

Being Agile does not mean following a specific framework to the letter. It is more about how to adress problems, how to collaborate and how to implement change.
In another post I have written about agile vs. Agile, in this post I want to highlight the Agile mindset.

* Problems are adressed with curiousity and as opportunities to make change. Change is positive and continous. Solving problems is a stepwise exercise where you size workload in each iteration depending on the capacity you have. After each iteration the output is evaluated and based on result the next step is planned. This means that you probably never come to a fixed solution …
* Collaboration is impled. Not if, but when issues appear they should be brought to the attention of all in a transparent way. This is not to put blame on indivuduals/groups but to drive learning and gaining experience. It is ok to fail, you should fail occasionally to learn and progress. Youd should not make the same mistake twice though…
* Implementation of change is a continous exercise with a regular cadence. Stakeholders and implementors are in the same team, there is nowhere to hide. Stakeholders work on detailing the problem at hand by clarifying the problem statement, iteration by iteration by evaluating the output, comparing to objectives and updating problem statement. Implementors update the working code adding their expertise and experience iteration by iteration and work together with stakeholders on what is possible.

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.