AgileOrganizations

How Agile a group of people want to be, or can be, is not static and should not have to be. When buyng a service using Agile practices it is important to make sure everybody speak the same language to set expectations and govern collaboration. That, however, does not mean pure Agile practices is always best when outsourcing service rather finding a level of using Agile practices that is more or less equal to all involved.

Therefore I recommend a Trust score to be used. The trust score identifies differences in perspections/expectations which needs to be adressed.

How do you size an engagement when you do not know exactly what is going to be delivered?
Very often companies wanting to outsource something wants to specify exactly what is going to be delivered and how, simply because they think that is the best way to make sure they do not get fooled or tricked by a vendor. This behavior works when you can specify exactly what is going to be delivered and how, like in traditional Waterfall projects. In an Agile engagement it is different, so instead focus should be on making a functional capacity available to the customer which can be specified and controlled. The output can not be controlled in the same way, but the assumption, based on mutual trust, is that utilizing the right capacity will produce the optimal output i.e. working code.

So, when buying Agile services focus should be on sizing the relevant capacity to adress the business problem, NOT sizing the estimated effort to create a predefined solution.

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.