Many companies start their Agile adoption in IT department without any connection to company business, its strategy, product vision or current goals. It is neither good, nor bad. There is only one visible and quite frequent implication I would like to emphasize. If such start of transformation was successful, IT teams face quite soon problems with other units and departments.
IT teams become more efficient and focused, work with priorities, deliver value and want to show something during demonstration to get a feedback, but the rest of the company doesn’t work like this. They still juggle too many priorities at the same time, have too high work-in-progress, jump from one project to another, have big and long projects and don’t have time to visit your demos and provide feedback. Moreover, they also don’t get feedback on their work and they aren’t responsible for your project, so why should they care?
Among others, there is one key root cause causing this cooperation problem with other units, but mostly with customers. The root cause is the form of the standard IT contracts. We call them fix-price contract, but in the practice they are fix-all contracts. If only the price is fixed and we as the vendor can adjust delivery date (time) and the scope according to real world conditions, it would be perfect. But reality is different. Customer often fixes the scope, delivery date as well as the price (or winner is the one with lowest offer), and we are forced to commit to it. How many times is this realistic? Answer yourself based on your own experience or ask your friends.
IT market is deformed
Software development is mental, cognitive and creative work that is by nature hard to imagine and estimate upfront. Yet, all IT vendors are forced to commit to quite big ambiguous projects with unclear needs and scope and need to provide precise time and cost estimates based on such unclear or undefined scope. And yet again, quite many (maybe all) IT vendors still play this game. We do not try to educate the clients and rather consider such conditions as standard… Therefore don’t blame the customer, but us IT people first.
What is the result of this acceptance? Lack of interest from the customer during the project, late, over-budget and buggy projects, not delivering what was expected (we call it value). Byproduct of this attitude is many additional change request generated. The intention is to deliver at least some value for the customer because original project hasn’t involved the core needed features. And there is also the vendor’s concern to earn some money on this, because the project is usually underpaid. You can imagine what does this approach cause to original project idea and designed architecture. The result is IT Frankenstein J
Agile contracts
Agile contracts are constructed in a different way than the traditional ones. There are more possible models you can use, but what all have in common is a description of cooperation routine and the way of working, not the detailed scope, although it is also presented, but more high level.
The basic structure of Agile contract is usually following:
- Frame agreement covering the business goal of the project, business needs and benefits, intended length, planned number of releases, only high level scope, roles and the way of working (who is responsible for what; who participates in planning, demo and other sessions; how to plan, change and accept the scope)
- Delivery/Release agreement covering more detailed scope of 1 shorter release taking something like 1 to 3 months (typically 2 to 5 iterations). It can be in form of epics and stories or use cases, but the point is good enough detail for understanding the need, provide estimations, do the planning and start the implementation of the first sprint.
Introduce possibility to change
You may say, this is a huge step and neither our lawyers, nor customers will accept such a big change. Moreover, contracts with state and government authorities could be even impossible to change to such form. For these reasons the only step you can take can be quite simple: introduce the possibility to change the scope.
If you realize during the project that something important is missing and it can be changed for something planned but less needed, it can be the way to deliver the value without prolonging the project. Only what you need to do is to agree on the role that can do it and the way to estimate and accept it (in simple enough form, e.g. email from product manager).
Listen what Lukasz Wegrzyn, senior lawyer at Maruta and Partners, says about it in our interview taken during Agilia conference 2016 (11 min):
So, don’t worry, you don’t need to start your Agile transformation with huge steps! You can spread Agile principles and way of working to other departments and to customer step-by-step. Your lawyers don’t need to be replaced by total new group of Agile hipsters neither. Small step regarding contracts can be the possibility of change as Lukasz points out in his interview.
Have you tried any of these steps? Was it easy or hard? What is your experience?
O autorovi: Jaroslav Procházka je kouč Agilních a Lean technik, mentor a školitel soft skills.