Our Agile Principles

Each process from the definition of the initial need for change to the final delivery of the agreed solution contributes to stakeholder trust, mutual respect, motivation, and willingness to take ownership of the solution components delivered.

This is the philosophy behind our processes, tools, and techniques. They involve the stakeholders in such a way that they feel that the results obtained belong to them. In this way, each process contributes to the motivation for the next one.

Our principles of Agile Strategy Management comprise:

The highest priority is to satisfy the stakeholders through early and continuous delivery of valuable solution components. We understand why the stakeholders need the solution and we know that the stakeholders like the solution.

Working solution components is the primary measure of progress.

Working solution components are delivered frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. The delivery process is Simulated Accept-Testing where the developers of the solution present it to future users, who discuss it with the developers and test it out after thorough education and support.

Changing requirements are welcome, even late in development. The agile processes harness change to obtain improved stakeholder benefits.

Development, Implementation, and Quality Management stakeholders work closely together throughout the project. This is ensured by the environment of technology, communication facilities, space and more. One of our basic requirements is a War Room where the involved parties assemble all that is needed to generate and evaluate the solutions required for decision-making.

Projects are built around motivated individuals. It is ensured that they have the environment and support they need. As the individuals in the Project teams have been selected based on their skill, experience, and competence we can and will trust the teams to get their jobs done. This is “The no excuse for failure” principle. If the team claims that they need something to get the job done then they get that something.

We do not establish or accept conflict during solution implementation; instead, we ask for a mutually agreed solution and progress without further discussion. Once the solution is in place we are happy to evaluate if something could have been done differently and better.

The most efficient and effective method of conveying information to and within a development team is regular face-to-face conversation. One or more War Rooms cater for this behavior. We have even went so far as to establish a contract based situation where software development and solution implementation work was allowed to take place only in the War room. No solution component could be brought in from the outside and nothing produced inside could leave the War Room before it had been fully Accept-Tested and signed off for IT and /or business operation. The War room was a set of containers with about 500 m2 of spaces for work, education, and testing fully and securely supported by the central IT infrastructure.

Agile processes promote sustainable development. This principle ensures that processes can be repeated and evaluated for possible improvement.

Continuous attention to technical excellence and good design enhances agility. Time is devoted to ensure that State of the art technology is used, which again implies that the technology used is a solid foundation for the solutions that use it. Good design ensures normalized processes and data that ensure integrity and valid integration in support of the agreed business needs. Once the business needs change it is easy to adapt good design, while bad design reveals itself under such conditions.

Only agreed necessary work is done. We list work not to be done explicitly only if doubts are raised. This is the Lean principle to avoid doing not required or not needed work.

The best architectures, requirements, and designs emerge from self-organizing teams. It is not the self-organizing that ensures this situation, but the fact that teams have been put together in such a way that self-organizing is possible. We ensure that teams can:

Make decisions
Initiate work
Do the work
Evaluate the progress and the results.

This makes simulated Accept-Testing great fun because the delivered solutions do work, although they may be improved in a meaningful (lean) way.

At regular intervals, the teams evaluate how to become more effective, then tunes and adjusts their behavior accordingly. The evaluation comprises communication between teams and their environment of resource providers and other key-stakeholders.

The teams have fun:

We celebrate visibly our successes, also the small ones
We do not hesitate to show appreciation of the others
We are not jealous, but we like a good fight
An individual achievement is a team victory.

The fun part can comprise games that require professional knowledge and quite often, professional development. The games provoke friendly competition in a team and between teams. The games are a great way to get to understand and respect the value of different personality in a team. The teams do not need rules of the game imposed from outside the team, but they can easily adapt to such rules if needed.