I'm Agile but My Contract Isn't
stridenyc.com
stridenyc.com
Ahhh, in the "Enterprise", we call this a Change Request (we would name and number them CRXXX, for example) and put them in a "register" (Excel doc that got passed around 100x a day). These become so excessive they needed to be managed by a Management Consultant (who charges $250+/hr) who specializes in change management.
> There are three variables to any project: Money, Time, and Scope.
Every project I approached, I would draw the following diagram to the client: http://en.wikipedia.org/wiki/Project_management_triangle and any time one of the corners changed (it always did) I would redraw the triangle and ask the client how they wanted to proceed with ensuring the quality of the project.
As someone who has successfully and unsuccessfully implemented agile in arguably the worst environment possible ("The Enterprise"), my general conclusion is this: if the client doesn't understand agile fully or is already implementing practices that are agile-like, then do not begin the project. Set up workshops, assess their ability to adhere to budget-less (agile) projects, and make a decision then. For smaller clients, I typically ask the client "what's your budget?" and then I work backwards from that. So if a developer is $100/hr, and the client has $5k to spend, I'll say "ok you get a developer for 50 hrs. Most likely we can build this, this and this" If/when the client disagrees ("But I can get 2 people in Malaysia for that price!") you simply tell them to go find someone cheaper on oDesk.
I keep wondering how you're supposed to negotiate the typical big enterprise contract so you're allowed to be agile while executing it. I haven't seen it done successfully yet.
The one that was successful was a $250k project - 3 months. Client insisted fixed price and done "in agile". We estimated the actual work was only 6 weeks, but knew they'd change their minds 100x times (they did). We didn't optimize the timeline properly (as you are insinuating, it's almost impossible to predict), so our margins ended up being quite low.
I do know one company which successfully does agile (within a company that does $100bil in rev). They budget the whole year out for X amount of employees and then do everything in 3 week sprints. They basically "fit in as much development as they can with the resources they have" and disregard the high level 3-year "integration plans" that the management consultants put together.
And even then, no one cares about unit tests, tdd, or whatever is the testing flavour of the month, besides the integration tests at delivery dates.
"Individuals and interactions over processes and tools" means "we come by your office to interact with you as an individual about why your story points haven't velocitized properly in the time tracking system" [2]
In a similar vein, "Customer collaboration over contract negotiation" becomes "we'll hold your feet to the fire about deadlines and estimates, but we reserve the right to change our minds at any point."
In this sense, agile becomes unilateral disarmament in the face of a heavily armed… neighbor. I wouldn't say "foe", yet, but good relationships can turn bad. It's like one side saying "let's do this with trust and work together", but they're the only ones with a lawyer at the table.
In some ways, the agile manifesto almost says "peace and cooperation over fighting and coercion". Yeah! I'm for it. But we both need to do this!
[1] I feel a little embarrassed using the word "agile", but I figure that as long as it's an adjective, I preserve some dignity. [2] I'm not technically a certified scrum master, so I may have some of that slightly wrong.
Back to contracting. If you're a contractor, even if the team you're working with is fully on board with being agile, you can still get burned by higher layers of their organization.
My favorite metaphor: asking for hard numbers from an Agile team makes as much sense as asking Columbus exactly how long it would take to reach India. Software development often resembles cartography work even more so than architecture work.
It is very important to discuss all this upfront with clients, many of them have no idea of estimation, the mythical man month and are horrible at knowing fully their ideas, the level of detail, before work starts yet will want fixed. It is especially bad on clients new to apps/games/web or their first attempt who just see surface level tasks.
Iteration and a more agile approach will hopefully find the way into business and mba textbooks/processes. Right now almost everyone wants fixed-price and flexibility to change at will. This will only hurt developers/designers and ultimately the project chance of success.
And don't get me started on non-competes the most anti-innovation, anti-business, anti-american (if you are in the US) thing ever being fully pushed by business at every turn. Most non-competes want you to come in to help a company compete, then once they know how or you have built it for them so they can compete, you can no longer compete any longer for a time because you helped them, makes sense for kings/owners/dictators but not fair business.
Vendors, obviously, want the customer to take the risk. This is why we see articles like this.
If you want to apply agile methodologies in these situations, you need to keep the scope small and also constrain the time. That keeps the risk for both the customer and vendor manageable.
They usually do not accept and want it cheaper. Then we offer the project at the estimate and to split any difference. So if we use 1 hour less at 200$/h, they get it 100$ cheaper. However, if the project ends up taking 1 hour more it will only be 100$ more for the customer.
I really would wish that the customers would trust us more and accept it at the hourly rate to get the initial work. Then we can iterate on that until they're satisfied.
Customers want business value. Some software systems that deliver that value cannot be broken into components or feature subsets that are sufficiently valuable in and of themselves. In these cases, the value of agile methods to the customer is that they can pull the plug at any time. That's the risk mitigation value that needs to be emphasized.
There are 2 options:
a) The supplier is not an expert in this and will have problems with the project changing scope and maybe running over budget and time which they cannot invoice. This leads to the supplier being at the unfair end of the deal, leading to poor work by the numbers.
b) The supplier is an expert, works on a fixed scope and denies all requests for changes (without renegotiation). This rarely works in favour of the client. I had prospective clients coming back to us after another company wrote them a software perfectly for their spec, but they realized in the middle that the spec was not fitting their business case properly.
We're agile, working with established businesses. We have to take in our clients real world needs into account. Agile is a set of principles and a guide, not a set of physical or economic rules. Sometimes the tool isn't the best for the job, sometimes two conventions (client's work, developer's work) contradict.
In other words, if your methodology is so great, use it to your business advantage.
They won't care to hear about the specific labor pains, but they will love it when you tell them your "agile" development process allows them to get prototypes quickly and provide further input as their ideas take shape.
"In other words, if your methodology is so great, use it to your business advantage."
I did and it resulted six-figures worth of contract work last year from just one client. Part of my sales pitch was to explain agile development in a way that focused on their business.
When I asked the client why they chose to work with me instead of the bigger agency, they mentioned 2 things: 1) They liked the feedback-driven development process and 2) I talked about their business instead of the technology that would go into the software.
The best part is that an agile process helps you position yourself as a trusted advisor instead of a commodity laborer. When you do that, your clients get better results and provide repeat and/or referral business.
TLDR: The best clients do care if you're agile about their business needs.
One of the central weaknesses of agile in my opinion is it is unclear the best way to bill it and therefore it can often be a business disadvantage.
I think this is one of the fundamental issues with Agile, if a client wants to hire a consultancy to complete a project, they want to know how much it will cost and what will actually be completed.
Forming the question as: “How much do you want to invest before we stop?” requires a large amount of trust in the consultancy, personally I have worked with a number that supply below par developers and so asking “How much do you want to invest before we stop?” gives the client no guarantees and the consultancy no obligation to what will actually be delivered.
I think agile can work for in house software teams but not so much for consultancies, where in reality there are normally 2 or 3 of those variables mentioned in the article fixed.
"The general rule is that an individual is an independent contractor if you, the person for whom the services are performed, have the right to control or direct only the result of the work and not the means and methods of accomplishing the result."
As an agile contractor you can give clients options that allow them balance quality & cost without being under "behavioral control." The client gets to say they want to build a widget that does X and Y, then you choose to build it at time T using whatever tools and methods you deem appropriate.
Couple that with offering these services to the public: "People such as doctors, veterinarians, and auctioneers who follow an independent trade, business, or profession in which they offer their services to the public, are generally not employees."
That said, "whether such people are employees or independent contractors depends on the facts in each case" so make the facts obvious in your contract with a section like this:
"Independent Contractor. The Parties agree that Contractor is an independent contractor and that Contractor has full control over the methods utilized in performing the Services. Contractor will not make any representation of an employment relationship between Contractor and the Company and will not claim any benefits provided by the Company to its employees. Contractor has no authority to contract for or bind the Company in any manner, except with prior written consent of the Company. Contractor shall devote such amount of his or its time, attention, knowledge, and skills as may be required to create and deliver the Product and to perform the Services."
(1) Where "what I'm going to do" can be substituted for "what I'm going to try," when the client understands why I can't guarantee something.
But, the contract is 1 piece of the puzzle. In order for businesses to want to hire Agile teams, whether consulting teams, freelancers or otherwise, many factors have to exist in addition to an Agile contract.
These factors include - high quality development teams, visible work, high collaboration, working agreements, trust, a cancellation clause, definition of "done", and more.
- Why not move to a whirlpool (or other milestone-based iterative process) with fixed milestones?
On one hand we have culture and art and philosophy and technology. We have technological culture and art. We have philosophies for creating a culture for creating technology. Then, OTOH, we have this. An inability to collaborate for fun or profit.
We need to account for various skill levels, failures in communication, philosophical differences. Scheisterism, baseless accusations of scheisterism. Bugs. etc. etc.
Collaboration is ultimately a fundamental problem, perhaps the most fundamental one.