Victor’s Software Development Blog

It’s a question that often gets asked and puzzles even the top managers of many consulting companies.

If you are going “Agile”, how to go about negotiating contracts? Aren’t “fixed bids” fundamentally incompatible with Agile? If so, then how can you handle potential clients who want a number to be quoted?

It turns out there are a number of ways to go about Agile contracts, described in more detail at

http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts

1.  The “Sprint Contract”
2. Fixed Price / Fixed Scope
3. Time and Materials
4. Time and Materials with Fixed Scope and a Cost Ceiling
5. Time and Materials with Variable Scope and Cost Ceiling
6. Phased Development
7. Bonus / Penalty Clauses
8. Fixed Profit
9. “Money for Nothing, Changes for Free”
10. Joint Ventures

Here’s another very useful collection of links on the subject, put together by Joe Little:

http://wiki.kittyhawkconsulting.com/Agile-Contract-Summary

The 2009 Standish report on the success of IT projects is out. Perhaps surprisingly, it shows that there has an increase in failure of IT projects, from previous years

http://www.standishgroup.com/newsroom/chaos_2009.php

“This year’s results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions” says Jim Johnson, chairman of The Standish Group, “44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”

In my opinion, the increase in failures is due to a few more or less obvious factors:

- technology has been increased in complexity

- adoption of Agile practices has been surprisingly slow

- there is a difficult economic environment, with scarcer resources (such as investment money) leading to more stressful and error-prone environments

To these, I’d like to add Jeff Sutherland’s remarks that with most current practices, project success doesn’t pay because …

“* Industry incentives now are for projects to be late.
*Many vendors only make money if the project is late
and over budget due to change requests and building
functionality the end users do not want.
*CIOs participate in this dysfunctional behavior using
their current proposal and contracting process.
*The whole industry could be viewed as driven by bad
incentives and faulty practices”
(http://jeffsutherland.com/scrum/2008/08/agile-2008-money-for-nothing.html)

This is quoted with permission from Joseph Little

In the course of my work, I hear people talk about how hard is to get things done in organizations. (This happened again recently.)

And I know from personal experience too, it is hard.

But I wanted to emphasize that organizational politics is not as hard as we make it for ourselves (at least sometimes it is not).

Here are a few nuggets mined in the field of hard knocks.

A few suggestions re ACTION (perhaps you find one useful):
* When boxing, do not expect to have the first punch be a knock out.  Set ‘em up for the kill in the 4th round.  Lots of combination punches.
* The truth is hard to resist.  (Yes, I know people will deny the truth and will often kill the bearer.)  Keep finding ways for the truth to be repeated and dealt with.  Scrum throws up the truth.
* If a bunch of people go together to a manager’s office, it is much harder for the manager to resist.  (Make sure you have the truth on your side, and that your idea makes sense.)   Maybe even harder if the manager comes to the Team room.
* Justify your impediment removals.  Do much better cost-benefit analysis.  Do them as small experiments (eg, show the actual results later).
* Justifications include: higher NPV for the product, higher velocity for the team, faster delivery, etc, etc.  Make the link from your improvement back to these key things.
* Make the case.  Make it so obviously right that the only question is: “How do I know your numbers are right?”  Managers only like to approve obviously right things.
* Ask to do an experiment.  Make sure the test sample is big enough to draw conclusions from.

Go get ‘em.
Nothing I said guarantees success. Accept that the other person is free and you can’t make him change.  Give him some respect.

According to the Standish report, “User Involvement” has been ranked as the number-one factor in software projects success. The following is the complete list of factors found to significantly impact success:

1. User Involvement
2. Executive Management Support
3. Clear Business Objectives
4. Optimizing Scope
5. Agile Process
6. Project Manager Expertise
7. Financial Management
8. Skilled Resources
9. Formal Methodology
10. Standard Tools and Infrastructure

(Source http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS)

How to achieve an optimal user involvement?

First off, we would need to define who the “user” is. The user is anybody who will benefit from the use of the system. This term is not to be confused with “Client”, the latter being a certain entity who wants the software to be built. The Client may or may not be the ultimate user of the system.

In any project, there should be a designated “Product Owner” (an Agile/Scrum term) who has detailed knowledge of the business domain and user needs. Often, technology companies are started by such a person, who has identified a clear business need and knows what the right product for it will be. However, this ideal situation is not always the case: sometimes, the initial idea needs to be developed in much more detail beyond the initial insight. In other cases, an existing company wants to develop new products about which it has an intuition, but not yet a complete understanding. Both of these scenarios provide challenges in which the product owner may not yet be knowledgeable enough about what needs to be built. One solution is to develop that knowledge through group studies and interviews with the target users, and to pair the Product Owner with other stakeholders.

Another challenge in building software products is distinguishing between end-user needs and wants. Roughly defined, we could say that a want is a feature that the user thinks the system should have. We define a need, on the other hand, as something that the system should definitely have, from the perspective of the software implementer.

Users will often demand certain features to be incorporated, because of the perception that they would make their life easier. However, it is exception rather than the norm that such a want SHOULD actually be translated into a feature. The reason is that individual users, from their own perspective, have only a limited view of the problem. It is the Product Owner who can have an integrated, “holistic” view of the needs across the entire spectrum, and who SHOULD decide what wants will be translated into needs. A common mistake is trying to add features for every want.

The Product Owner also needs to be aware of the difference between a function of the product, and the visual interface for that function. It may sound like common sense, but a great deal of products do not place enough emphasis on user friendliness because the product owner doesn’t have that skillset. In that case, it is vital that the Product Owner collaborate closely with a user experience specialist. Apple is an example of a company that understood it is not just about the feature, but also about the best way to interact and express that feature.

Finally, there is a need to understand the technical details of the implementation in the Product Ownership group. That idea is alien to traditional software approaches, but central in Agile. If the Product Owner doesn’t have the necessary technical skillset, a sharp separation is often imposed throughout the development cycle, which could be catastrophical for the project. The solution is to have the Product Owner in continuous collaboration with the technical team - such as by pairing them with a technical lead. At every step of the way, feature feasibility and prioritization should be considered together with the technical details - the result being much better choices, faster development time, and ultimately a better product.

Recruiting software professionals for a new technology is difficult. Coupled with a general job-seeker’s market and a region short on technical talent in general results in an even more serious problem. Such was our experience with one of our New York City-based clients; the particular technology in question was Ruby on Rails (RoR).

Ruby on Rails is no longer extremely new, but still considerably less popular than Java, .NET or PHP. And the reality is that most technical people would rather live on the West Coast than in the hustle of NYC.

As with every challenge, there are ways out, and it can be turned into a big opportunity. In fact, since most companies will face the same problem, the opportunity to solve it will be all the better.

Here are the approaches that proved successful for us.

1) Recruit people without explicit experience in the particular technology, but who are totally capable and eager to learn it

Almost all of the strong RoR developers around had a job or enough contracts. What to do, stall the project or change the technology? Not the smartest thing to do.  Our approach was to get promising people, with a background in related technologies - in this case, PHP and other Object Oriented Programming languages. These developers learned Rails quickly and were able to surpass our expectations.  Interestingly enough, this principle runs counter to some people’s advices advocating only hiring people with at least a Rails project in their portfolio.

2) If faced with a choice, get someone with a lot experience and skill in a similar technology, over someone with a little experience in the same technology.

Unfortunately, some of our offshore consultants were in the second category - that is, they had some Rails experience, but their overall web development experience was low. Fortunately, we made the opposite choice when we recruited the on-site people. A developer with significant background in PHP, CSS/Javascript and databases proved to be an exceptional Rails developer in a short period of time.

Which brings us to the next point:

3) Do not underestimate the teaching power of the web

A lot of technical problems have been already solved, and chances are someone out there posted a description of how to do it. A significant number of programming constructs (plugins, modules) have already been made. And for Rails, the web community is so good that often all it takes to uncover how to do it is a simple Google search. Therefore, knowledge of the specifics of a particular technical language has become even more irrelevant - and someone who has a strong understanding of the principles is the best asset.

4) Recruit people with communication skills. Encourage and grow communication skills.

It is common to assume as a given that IT professionals lack good communication skills, but that doesn’t need to be the case. In fact, particularly if the development methodology is intended to be Agile, the assumption is unacceptable. If there is a need, management can (and should) set up processes that will encourage better  communication. We were able to get people with both technical abilities and excellent communication skills at the same time and that was instrumental to the success of the projects.

5) Engage technology professionals in the hiring process

It is tempting to try to delegate the candidate search to recruiters, whose sole job is to look for people. Yet sometimes with new technologies it is the developers themselves who can be more successful at getting new hires. Through their memberships in various online communities, personal networks and knowledge of specific job boards, excellent referrals can be obtained.

Conclusion

In conclusion, not starting or stalling a project just because people with that particular skill set can’t seem to be found is not a solution. Lost opportunity can be a lot more costly. A good principle is to look for people showing the general traits of adaptability, passion for technology, general technical ability and work ethic.