It’s not finished! If we write software in an iterative and incremental way books would probably gain to be written this way also. So here is my non finished first public version of my book “Agile Leadership – A book about the human factor of software development”. So please enjoy and spread it to people that might like it and give me feedback. It free for non-commercial use and licenses under Creative Common – CC BY-NC-SA 3.0.

Yours faithfully

Patrik Malmquist   

Work is not a place, it’s something you do!

I’m in Barcelona on World Mobile Congress 2013 and discussing how to mobiles enterprises. When looking on technology today everything seems possible but gap between management and today’s mobile knowledge workers grows faster the more technology evolve.

I work with helping companies develop mobile solutions for their customer or creating new solutions in order to make companies more productive. For me work is an activity not a place. I have an office and an own room but when I’m at the office my main activity is to collaborate with colleagues.  When I work with companies that are new to the thoughts of work is an activity and not a place I often hear argument like “how do you know that employees are working when they are at home or working from a location other than the office when you can’t see them?” And that is an important question…

How do you know that employees are doing what they should and are maximally productive in the workplace? Just because you see them does not mean they know what they are doing and how productive they are!

Unfortunately only one answer and it is the same answer as when you’re at work, you yourself must simply be competent in the subject matter and really understand what employees are doing. There is no other way. So do you want more freedom in your job, greater job satisfaction and work when it suits you, you simply get yourself a competent manager. I use the work unfortunately because I don’t know how to tell managers this bitter truth, I often sounds like a “besserwisser” that tells them that they are incompetent.

What is Integration?

Integration is making two or more systems “talk” to each other. The interesting thing about integration is that it isn’t two different systems that understand each other, but two different teams that try to agree about how they see the world. Both teams already have a model of the world in their information model.

The Psychology of Who is Integrating Against Who

When integrating two systems, it’s common for team A to feel that they are doing team B a favor because team B is integrating into the team A’s system, and therefore have more to gain from that integration. Team A feels that their information model is the one that team B should adapt to.

Sometimes both teams get the same feeling that they are doing the other team a favor.  This causes irritations as each team tries to present evidence that their view of the world is the correct one.

Is it a problem to adapt to the other systems view of “the world” / information model?

If the other team has had more integration experience (either by building them or integrating to several systems), it is probably a good idea to let their view of the world teach you. While your system might be easier to adapt to and your team is more agile than theirs, the other team has to make sure the information model works for a lot of different systems.

How to avoid this?

If this becomes a problem for both systems, meet with the other systems owner and do an effect analysis together. Which benefit will each system gain through integration?  Are there any cost benefits or new possibilities? If there are new possibilities for any system, include the people who will gain most by these possibilities.

A business developer might see how and if these possibilities might be “harvested”. If there are no new benefits by integrating, no efficiency gain, no cost reduction, or any new possibilities that can be harvested, integration is discouraged. Another alternative is to get upper management / executive support, either enterprise-wide or between the organizations. Present the new possibilities that integration will bring. It’s always good to have “executive blessing”!

How to use this to benefit your team!

If you fear that your project will be the one that has to adapt to the other team, you can manipulate the situation to your advantage. But do it with caution, because these aren’t exactly “kosher” recommendations.

• Conduct the meeting with the other team in your office or conference room. The other team is in your territory and you’re hosting the meeting.  The meeting host can set the agenda for discussions.
• Be proactive and send out the agenda before the meeting.  That way, it’s easier to chair the meeting. If you are conducting the meeting, the other team will feel that they report to you.
• Take down minutes of the meeting and send them to all meeting attendees.
• If the meeting is via phone or video conferencing, (live meetings) use your account and pay for the facility.

Hidden Stakeholders

Integration projects tend to have hidden stakeholders. Since there are two organizations to be integrated, one has no knowledge of the other. all stakeholders. For the success of the entire project,  it should be made clear that every stakeholder is involved at the beginning of the project. Unfortunately, business people show up only during the testing phase when they should have been present much earlier. In large organizations it also common that there is a specific security department, it becomes very strange when they are not involved early. I has responsible for delivering as system as a supplier to and a week before product delivery the purchaser called and ask if we could have a workshop with the security department and discuss the design and solutions. The purchasor had the prior day accepted all acceptance test so we feelt like this was a bit late in the process to start discussing security design principles might have been better to done this earlier in the project.

The most important success factor in integration projects

The largest factor is relationships – accounting for 53% of success (According to the standish rapport).  For integration projects this becomes more important especially when it is carried out between different organizations, each with their goals and views of the world. Communication and building relationships must therefore be done at every level as well as obtaining upper management’s support. Hold regular meetings – for example every Friday after lunch. Things tend to happen on Friday morning when people promise deliveries or need to prepare.

This will lead to so much more changes than in technology, we will need to:

• We will get a completely new way of relating to work!
• We need to reflect on the relations between time and value.
• We need training, procedures, systems and practices to show our presence at a distance.
• We need training, procedures, systems and practices to collaborate remotely.
• We need to shift from a culture of control to a target-oriented leadership.
• We will change our physical offices, as we come to the office for another reason.
• We will often work  harder in places other than the office. I myself often sit in cafe’s, libraries and hotel environments.
• We will digitize all new processes and situations.

It’s important to acquire new “best-practices” for this change. Some call it a paradigm shift, but I think it is more about evolution than revolution. Personally, it fits very good to sit at home and work when I have a deadline to relate to. But worse if I just work at all, need to cooperate and coordinate different tasks with others. So the work life is changing, our digital work life will become much more mobile in the future.

Who should take the commercial risk?

The buyer can handle the project on their own and just hire or contract some consultants that will work on a per-hour basis, in which case the full risk remains with the buyer.  Or the buyer can outsource a part of the project to a supplier, who also takes an agreed-upon portion of the risk as part of the deal.

This is often handled with a requirement phase that produces a requirement document that one or more suppliers use to develop a bid for winning the contract from the buyer. The contracts often include the total cost, some options (often add-ons) and a time when the delivery shall be done.

The problem with this is that it doesn’t facilitate changes and the flexibility to apply knowledge that you gain during the project very easily. When the project starts, keeping to the original plan becomes more important for both parties instead of maximizing the business value. This prevents either party from incurring cost or schedule overruns that could turn their side of the contract into a losing proposition.

This inflexibility negates the benefits of agile development projects, which are adaptive so as to maximize business value. But there are alternatives to fixed-scope/fix-price types of contracts. I will talk about different kinds of contracts soon but first I would like to explain maximal value focused.

Maximal Business Value

If we only have an idea of what might create the benefit we expect from a specific software solution, it’s hard to create an accurate detailed plan of how to reach that goal. Complex projects have multiple solutions; there is no one BEST way to run a software project. We can’t predict the best solutions. But, if we conduct the project like an exploratory journey looking for the best opportunities that appear to us along the way, we stand a better chance to maximize the business value. This is because whoever undertakes the project is likely to never have done this kind of work before. This kind of work must focus on knowledge acquisition and making the best out of the current situation. At the same time, the project must remain on target toward the long-term grand vision of what is going to give the customer the competitive advantage he is seeking.

The Pareto Principle

The Pareto principle (also known as the 80-20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes. It is a common rule of thumb in business; e.g., “80% of your sales come from 20% of your clients”.

In order to be able to correctly analyze a project as the buyer, an effective approach may be for the supplier to first show how they have estimated the work, followed by a dialog between the buyer and supplier. When doing upfront design of a large scale project, it’s quite common that requirements are finalized and prioritized before the supplier has estimated them. But how can you know whether it costs more than it tastes before the estimate? Showing how estimation is done is therefore something that creates trust between both parties. Then the buyer gets a second chance to prioritize, having learned from the supplier dialog that some things might create more value than others. The suppliers don’t want to reveal their estimates to their competitors, but that issue can be addressed with a confidentiality agreement. Remember the “feature used on failed projects” from chapter 2 which indicates that 45% of the features were never used; they must have cost more than how they tasted!

What are fixed price contacts?

Fixed priced contracts are employed when a contractor takes a commercial risk in order to complete a predefined amount of work. This risk is worth something so therefore a risk premium is added to the original estimation. It could be 20% higher price than the estimation in order to cover the financial risk if estimations turn out to be wrong, such as if bugs are found and for handling “the unknowns” that no one could even think about before the project.

Why not just use Fixed Price Contracts all the time?

The answer is estimation, estimation and estimation! If estimating was easy and always turned out correctly, buyers could easily do high confidence cost analysis by themselves. But in complex situations where things depend on many variables, accurate upfront estimations are almost impossible. You will need to really understand on which level you should put your effort. Any solution can be developed in many different ways, and there is no universal “best-practices” approach; it all depends on the problem context. Therefore, you as a supplier need to really understand the problem context and on which level of quality this buyer expects the solutions to end up on.

What is the Purpose of a Contract?

Contracts should set the basic parameters for a project to create optimal conditions for successfully completing the project – for both the buyer and supplier. But in practice, contracts are often seen as competitive and not collaborative, in which the objective is to place the other party at a disadvantage, especially if things don’t go according to plans. Contracts handle the upside (the motivation to do something) and the risk that obstacles will arise during the journey that will involve additional cost and time to overcome.

Usually when people say fixed price, they mean fixed price, time and scope. This requires detailed, stable and accurate documented requirements, and the technology to be used is well known. The advantage of the agile approach is to handle development when requirements are fuzzier, and do not adequately reflect the underlying reality of business.  Many companies like the idea of writing a contract that fixes the scope and price because they believe it lowers their risk. But as we start developing the software, inevitably things change. In reality, fixed scope, fixed cost and fixed time is very risky for both suppliers and buyers; it almost guarantees delivery of software that the business doesn’t want. I have delivered systems with all requirements implemented, on time and within budget, only to see that the users aren’t satisfied. That time it turned out that it wasn’t just us “the supplier” that learned more about the customer during the project; the users realized what they really needed during the project. At the end of the project they didn’t want what they originally had demanded, but instead a system that reflected their new depiction of the system as of the end of the project.

If buyers want to lower their risk and get more value for their money, projects should become iterative, and then the contract will need to reflect that. What buyers often need is a fixed price contract or a price ceiling so that they can make an investment decision. Time and scope are often not important to fix; allowing flexibility with a more business value driven approach often allows customers to reflect on what they might want to gain. What may appear to be a looser contract might in reality yield two benefits: help raise business value, and lower risk. Neither you nor your mechanic would agree to an all inclusive fixed price to service your car before he looked under the hood. So why put a strait jacket on something that is far more complex, more costly and takes far longer time, such as a software development project? Here are some ideas for how you can create different types of contracts, based on the situation.

Different Kinds of Contracts

The most common kind of contracts used when an outside supplier is to deliver one part of the process is to put a specific set of requirements out for bid. The winning bidder becomes the supplier, whose work is then governed by a fixed price contract.

Fixed price & fixed scope projects

The usual fixed price contract is a plan-driven arrangement, covering a fixed scope for a fixed price. Penalties are built into the terms of the contract, to be levied against the supplier if the work isn’t delivered per the strict terms of the contract. The penalties are usually financial in nature and can be pretty steep. When the buyer publishes the Request for Proposal (RFP), the penalty terms are spelled out in detail so that bidders know what they are getting into before they bid.

This type of contract is good for budgeting and return of investment decision, and works best when the technology is well known and the stakeholders agree on both the requirements and where the project’s business value comes from. With a fixed price & fixed scope (FP&FS) approach, it can be difficult to adapt a full agile view, because you will not embrace change; you are compelled, to stick to the original plan. A quite common add-on is a delta list, on which you log extra work that is needed but wasn’t included in the original plan. But you need to renegotiate the scope with the customer before putting something up on the delta-list. Often, projects adapt some agile principles (for example frequent delivery, automated tests, continuous integration) but not a fully agile methodology when working with FP&FS projects.

“Fixed Price and Changes for Free” option clause

Fixed Price and Changes for Free is not about selling or delivering the (B) + (Something new) – it’s actually to deliver (B) + (Something new) – (Something else). The supplier can use a standard FP&FS contract, but add a Changes for Free option clause in the contract.

The Changes for free options have some conditions:

• The customer must execute this option by working with the team on every sprint.
• Failure to do this voids the clause and the contract reverts back to a fixed price & fixed scope contract.
• The product owner re-prioritizes the Product Backlog at the end of each Sprint.
• Changes are included, with these rules:
  • Changes in priorities are free if total contract work is not changed.
  • New features may be added for free at Sprint boundaries if lower priority items of equal work are removed from contract.
  • All features are prioritized by business value and implemented in order of maximum value.
  • Users follow the project closely and work with the Product Owner responsible for producing a high quality Product Backlog.

Here is a description about the process:

When planning the project you start with some requirement, either as a user story, scenario, or as a use case. Then you make a rough estimate of what it will cost to deliver that requirement. And then, you sequence them all in a product backlog. All requirements have a unique priority; two requirements can never be prioritized the same. One of them is always more important. Then you look on all the requirements and their estimates, and summarize the cost. That gives you a rough budget of what it will cost to implement all requirements. When you start the first iteration (called sprint in Scrum), you look at how many resources you have, for example, 4 people working on this project for 40 hours a week and the iteration will last 3 weeks. This means that you sum up the estimates for the top requirements until you reach 360 (4 x 40 x 3) hours of planned work. These requirements cannot be changed from now, but all other requirements in the backlog can be changed and re-prioritized, or you can remove or add new requirements. At the end of each sprint, everything that has been completed is demonstrated, or better yet, delivered for use. When you demonstrate and users use the software, new requirements will evolve. They might say, “When I see this you will need to do this also, otherwise this has no value!” Now the backlog grows, and the value of all implemented requirements plus all the new ones are higher than what you budgeted for the project from the start. But at the same time, what goes down in the backlog is the requirement that wasn’t prioritized. The total planned work effort is the same, so it means that the requirements that have the lowest business value are deferred or dropped.

Money for Nothing clause

The Money for Nothing clause is about focusing on business value, as in Pareto’s principle about focusing on being as productive as possible while costing less than it taste. With this clause, both parties will have an underlying motivation to reach the greatest possible business value as productively as possible.

The Changes for Free options have some conditions:

• It’s only effective if you use an incremental and iterative process that both parties understand. If this condition is not fulfilled, the contract reverts to time and materials contract.
• Estimates are mutually agreed upon. If this condition is not fulfilled, the contract reverts to time and material contract.
• The buyer and supplier have to agree on the same standard of the level of quality, i.e. what is minimally acceptable. In order to make this possible, the buyer must be available on a day to day basis so progress can be followed.
• The buyer has to analyze the ROI cut-off, where implementation of the next feature costs more than the value of the feature.
• The supplier allows termination of the contract at the end of every iteration and shall receive XX% (for example 20%) of remaining contracts.
• The supplier assumes the risk of late delivery.

Fixed Price & Fixed Date with Money for Nothing and Changes for Free clauses

It’s also possible to combine the “Money for Nothing” and “Changes for Free” clause. This enables the buyer to tune the system to the latest known business value. Any requirements that haven’t already been worked on can be swapped out for others of equal value, and the customer can re-prioritize any requirement. And in adhering to Pareto’s Principle, the customer may terminate the contract early if its value has been fully satisfied, for 20% of the remaining unbilled contract value.

 Some other advice on Contracts

Communicate win-win

Both parties have rights and responsibilities, and these must be divided fairly between the two parties. If either of the parties doesn’t feel that the agreement will treat them fairly, they shall not enter the agreement. And if they feel it to be a zero sum game, they will start acting very defensively as soon as something is not going as planned. Both parties need to feel that they will benefit from this contract without harming the other party – i.e. a win-win proposition.

Underbids

Some supplier might underbid a proposal with the expectation that the inevitable change orders from the customers will allow them to recover the profit margin they are losing in order to get the business. Beware of bids that seem too good to be true. If the sales team is not presenting a competitive yet fair bid, it may mean that the supplier doesn’t understand the requirement, and when they finally do become aware, they might want to renegotiate.

Dependencies to the 3rd parties

A software development project often has interdependencies with other systems that need to involve work on the part of other departments or suppliers. They are not always as happy as you are when a new project needs their attention, as they might have been bidding on the same project or may not have available resources to help you when the schedule requires them. Sometimes they even want to see you fail. The situations where your success is highly dependent on a 3rd party must be identified early, and preferably before the contract is written, in order to cover all legal aspects and ensure continued progress toward the project goal.

Complex sales take time because they build on trust

Selling a complex project takes longer then selling a more simple solution. I think this has to do with the nature of complexity, that stakeholders are far from agreement on both what they want to accomplish and how they are going to accomplish that. What a sales person is doing initially is to help the customer and the stakeholders to be more aligned with their demand. First, sales will suggest different options as to how the system could work, and the stakeholders then talk to each other and arrive at a more aligned view of what they are trying to accomplish. Second, it builds trust; when stakeholders feel that you bring some clarity to their accomplishment, they feel that you understand them and are working on their behalf. It takes time to help the customer gain clarity and become more aligned toward the requirements, and to build trust.

For further reading I recommend:

• Peter Stevens blog post “10 Contracts for your next Agile Software Project”.
• Mike Cohn’s book Agile Estimation and Planning

What risks should each party assume, in a fixed price contract?

I think it’s important to examine different aspects of the project between supplier and buyer, for when things don’t turn out as planned. Exactly how the contract should be written and how the risk should be shared or divided between you and your customer is not easy to recommend. But here is my personal point of view, if you work with fixed price and with one or both of the clauses “Changes for free” or “Money for nothing”.

• If the customer changes his mind about a priority and the feature isn’t included in a sprint, it’s okay to re-prioritize.
• If the customer changes his definition about a function, the customer shall bear any increase in cost.
• If a requirement has been misunderstood, the supplier shall take the cost. This places the burden on the supplier to break down all requirements in small enough pieces to simplify their estimation of them, and make it easier to verify the requirement with the customer.  (That is why you have a risk premium added to the estimate).
• If development takes longer due to underestimation, the supplier has to take the cost. (That is also why you have a risk premium added to the estimate).

Conclusions of Contracts

Development during complex software development projects is like making an exploratory journey – it’s difficult to give hard guarantees of what shall be done, instead the agile view in which we shall be prepared to follow the best possible journey. Fixed Price, fixed time and fixed scope contracts don’t offer any guarantees to either the customer or the supplier, despite the appearance. This is especially true if you lock all three aspects, because then the only remaining variable, Quality, gets compromised in order to achieve the three fixed components. This often leads to one or more of the three fixed aspects being compromised too, in an unconscious way.

But if you prefer more flexibility for adaptive behavior in your contracts, the “Money for nothing” and “Changes for free” clauses are good complements to normal fixed price projects.  The “Money for nothing” and “Changes for free” clauses might also be valuable when working with organizations that have professional buyers that only focus on the price. The company’s Purchasing Department may maintain a frozen requirement specification that they will find the best (the cheapest) supplier for.  A supplier can then offer the purchasing department a fixed price contract with the “Money for nothing” and “Changes for free” clauses so that the internal department can have the flexibility to adapt during the project or to stick with the original plan.

One warning when adapting CI!

The focus of integration and automated builds leads to a false feeling of secure, as long as it builds and all tests passes people tend to be satisfied. But in order to gain all benefits that you strive for, like getting feedback on just work done these test isn’t enough. In order to be as productive as possible you need to really test as close to the development as possible. You will save a lot of time if you find a bug or mistake that you done today or this week, rather something someone may have done to the code base during the last 6 month.

Continuous integration is like one apple a day, it keeps the debug doctor away. But it doesn’t gain its full power if you also complements with frequent testing and verification of the system.

Mel Conway wrote in his book “How Do Committees Invent?” that “organizations which design systems are constrained to produce designs which are copies of the communication structure of these organizations”. When people are dependent on people in other parts of the organization, a conflict of interest can easily appear. People might share the same view today, but in the future, someone’s boss might set different priorities. When that happens, one team will follow its own objectives and might not prioritize another group’s needs as highly as their own. The further away people are from each other, the more disjointed and incongruous their objectives are likely to be.

People working in the same room can easily discuss things spontaneously within the room, or on a short notice attend a design meeting within the room. People on different floors start booking meetings with each other, either officially or in more informal settings such as over a cup of coffee.   People on different offices write memos and specifications to each other have phone meetings and occasionally meet each other in real life. When people are geographically separated from each other, have different underlying motivations or are in a different part of an organization, clearer contract of responsibility and modularization is needed.

Another important concept in agile software development methodologies is technical debt. When you write code you don’t fully understand a problem until you are finished solving it. This means that your application isn’t designed and implemented the way you would have if you were to do it again. If you continue to add functionality and features to this application without aligning the code to what you have learned and understood about the domain, there could be disagreement. This disagreement between understanding of the domain and reality will lead to a decrease in the rate of development. Ward Cunningham called this technical debt; he did an economic analogy to software development to explain code quality.

When you write code, you make a monetary or time investment to understand and solve a problem. And time is money. You have limited resources at your disposal so you prioritize the use of these resources in solving the problem. To meet deadline, shortcuts can be taken. This means that the job can be completed more quickly, but in doing so, time had to be borrowed. Time, as stated, is money.
When you borrow money, you pay interest until the loan is paid in full. It’s the same in software development. If you don’t re-factor your application and align with newly discovered insights about the problem or fix previous shortcuts, you need to adjust other parts of the system. However, this adjustment is in vain because the other parts don’t align with how it should have been built based on current or newly acquired knowledge.
Every minute spent on the wrong code is time spent in vain. It lowers the speed of solving the real business issues. If you keep borrowing money and not paying it back,this eventually leads to your income going to interest payments, bringing down your purchasing power to zero. It’s the same as developing a program for a long period of time and only adding features without reorganizing them for a better understanding of how they work. This translates into very low productivity.
A friend told me that his latest consultant assignment involved a project with a very large technical debt. He was added to the project very late in the development cycle, and he felt like an archaeologist trying to clean up an artifact that would crumble unless he worked very slowly and cautiously. This project had been running for three years and it was now one year late.
When several programmers pointed out that the problem arose because the project was not aligned with the system and did not take into account the new knowledge and understanding of the domain. Management’s comment was there was no time for refactoring as there were only 10 months left according to their earned value analysis, so the decision was to add the last feature. My friend left after a year and the project was only 90% complete.

What happens knowledge is not synchronized with code?
Management indirectly state that they don’t appreciate quality in the long run. If it’s not appreciated in the long run, it might not be so important in the short run either. If you are not allowed to take pride in your craftsmanship you will not do your best, because it doesn’t matter. Mikael Feathers author/blogger says, “We need to see clean flexible code as an asset and count it as an asset.” Whether it depends on deadlines, dispersed teams, or unfamiliarity with a new technology, it’s easier to let code rot than keep it up to date.

I found a great video with Ward Cunningham when he explains Technical Debt that I have to share with you: