> “No changes will be effective unless and until memorialized in a written change order signed by both parties.”
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'm wondering up to what size you managed to do an agile project for 'The Enterprise'. From what I've seen, as soon as an enterprise contract is big enough to involve a tender, bidding round and separate purchasing department, agile is impossible. Being agile actually works against you, since regular demo's will bring up more opportunities to point out how you aren't sticking to the letter of the contract, flexible scope means adding scope and never reducing it, and grooming as you go along means uncovering big requirements which are sort-of-kind-of in the contract halfway through a big project that's already late. And those are the easy projects compared to government contracts.
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.
You're not incorrect. But I always like to think there is always a possible ;) The reality is agile is such a strong buzzword in 'The Enterprise' now that you can't even avoid it anymore.
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.
The key is to have a strong project sponsor who believes in you, and if done correctly, you can actually make your sponsor look really good as an executive who "gets" technology. Believe it or not, the term Agile is making its way into the dictionary of senior leaderships of traditional organizations.
I came to the conclusion it is impossible to do agile in the enterprise, the best one can hope for is when sprints are seen as a kind of "mini-waterfall".
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.
This article really addresses the need for agile development to be a two way street [1]. I loved the manifesto when I first read it, and I still do. But I've noticed it really goes wrong when both sides don't adhere to the principle - when one side tries to be "agile" and the other side lawyers up, the agile side will get railroaded if (and probably when) the relationship turns sour.
"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.
Let's step away from the contracting scenario for a minute. Let's say it's purely in-house, and the team is committed to agile. That's great... until you run into a layer of management that doesn't understand agile. They still want the old waterfall-style progress reports, and they still make decisions based on them - decisions that can kill your project. This can force you to suddenly be less agile, or to present an interface to those outside your team as if you were not agile.
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.
Seconded. This is just the kind of framing I use when trying to explain why, at our workplace, our "Agile" (or even our "Scrum") process seems so ineffective.
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.
In projects I've seen (both inside and from the outside), one side usually wants to use the term "agile" as a synonym for "we don't write anything down", nothing more.
Clients almost always want it fixed-price, but those same clients, when it comes to the actual project, they turn into agile scope creepers.
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.
The underlying issue is risk management. Customers want certain features within a certain budget, hence their need to constrain at least two of the variables mentioned in the article. They want the vendor to take the risk of going over budget.
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.
I agree whole heartily, but the risk that is rarely protected by the contract is whether those features will actually give the client any return on their investment. Keeping the investment small (in terms of scope and time) only reduces the exposure in terms of cost/time to the client, yet vendors are making countless decisions that affect the outcome (e.g. ROI) of a project. The "scope" in a contract tends only to specify "what" and not "how well" or "why". At my company been experimenting in trying to solve that problem by contractually committing to outcomes (e.g. a measurable goals connected to the business case - e.g. reduce churn, increase sales, etc.) and tying part of our payment to meeting those goals.
We have a different approach. If the customer wants a fixed scope and price, we make an estimate (considering both our internal cost, and the value of the work for the customer) then double the price.
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.
More concretely, your post is a suggestion to do something along the lines of "write a contract for a demo/alpha/MVP, then do a separate contract to improve things, iterate until done", right?
That would be ideal, but in my experience it needs to be phrased as a risk mitigation strategy, not as constraining one of three project management aspects.
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.
Absolutely agree that it's a risk mitigation strategy. Even if we can get to a 'do an MVP' and then iterate, I still see these types of contracts trying to fix more than 1 project aspect.
Fixed contracts (Option 4) are extremely problematic for clients. I rarely seen one of those going well.
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.
This clause sounds more like it has to do with changing features that a developer may see as an improvement and a client may see as a "holy crap, what happened, now I have to retrain my staff."
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.
Reply to self: Of course, as relationships grow, we know our clients better and they trust us to make the right decision or fix it quickly on production.
If "Agile" really works (and I have no opinion on whether it does), then its use should be an implementation detail that the client doesn't need to care about, but which allows the consultancy to offer much better estimates of time and cost for a given scope.
In other words, if your methodology is so great, use it to your business advantage.
Agile is definitely an implementation detail but good clients will care about it for precisely the reason you provided.
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.
If agile really works (I do have an opinion but not an orthodoxy) one of its main premises is that one of the failings of traditional project management techniques is isolating the client from the development process. This "implementation detail" is the central premise and the client should be exceptionally motivated to care about it.
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.
The real advantage of Agile though is to allow a flexible and reprioritized scope because of the failings of Waterfall. The main benefit is the ability to respond flexibly and avoid building "the wrong thing". Fix scope and estimate time and cost is clearly a problem that Waterfall solves better, it's just generally a bad approach to producing valuable software since it means pointless features are built, while useful things aren't added.
The article mentions this as a question if you want to confine the amount of money you spend: “How much do you want to invest before we stop?”
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.
Yes, it does require trust. I have personally seen Agile work for consultancies (It works well for my consultancy, Stride). The trust factor is paramount. We take a lot of care and implement many practices outside the contract to ensure we deliver what the client wants.
If as the OP says, it's about treating the contractual relationship as an investment to deliver value then I believe we can do better than simply "fix scope". I've recently written about this at length including why the contract model (and agile derivatives) do little to align the interests of client and supplier to deliver value. (http://www.energizedwork.com/weblog/2014/09/commercial-contr...)
In the US, if you're "agile", you're an employee, not a contractor, for tax purposes. Read IRS Publication 15-A, page 7. A fixed-goal, fixed price contract is a real contract. "Agile" puts you under the "behavioral control" of the employer at a more detailed level, which makes you an employee.
It's not that simple. Being "agile" does not necessarily makes you an employee in the US. From IRA Pub 15-a:
"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."
It sounds like the author is working with contracts that are too detailed. Contracts should specify the legal obligations and structure of a relationship between two parties, but if it is getting into procedural detail, or dictating the policies of an organization, it is just asking for trouble. At that point, an internal process change could violate a contract clause. That just doesn't make sense.
Moving away from a fixed scope for a fixed price is a legal obligation, so the process I recommend in is simply that - keeping the contract as broad as possible to write what the legal obligations of both parties are. Instead of stating the obligations are 'X scope for $Y", I advocate "$Y", which is actually less detailed by intent.
You can always amend a contract. Just write a sideletter. A contract should always contain a definition of the services and the mode they are supplied and invoiced in.
I work with two types of documents: master consulting agreements and work orders. The master consulting agreement has all the "standard" stuff like IP, confidentiallity, indemnity, etc. The work orders are where I specify what we're going to do(1), how much it's going to cost, and when it will be delivered. Both are dated and signed. This works well for me and allows me to do agile-style sprints with work orders. This is usually in addition to a ballpark price range for ballpark scope.
(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.
Based off of reading this, I can imagine a lot of people not wanting to hire you. I get what you're saying, but all you've communicated to the customer is that you always need enough wiggle room to successfully screw them over. You should still place contractual bounds on how something can change.
Yes, if all I offered a client was an Agile contract, they shouldn't want to hire us.
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.
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.
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.