Agile is Bullshit

You can’t have a fixed price agile project.

There, it has been said.  If a project is billed as Agile but has a fixed proce attached to it then someone is lying.  There is no way around it - fixed price and the agile philosophy don’t mix.  There is a technical and a philosophical reason why.  Let’s go over them both briefly.

The technical is simple - agile projects are rarely completely scoped.  As part of “Working Software over Comprehensive Documentation.” Agile projects are very rarely comprehensively scoped.  If you don’t write the requirements and do the design up front, there is nothing to base a fixed price on.  Even sales people know you can’t bid a job if you don’t know how big it is at all.

You can set an hourly rate though.

Anyway, that issue is important, but I have seen people ignore it.  They either do requirements anyway and write 10,000 change controls, or they just guess, or they have a standup and call it agile, whatever.  The technical issue pales in the comparison to the philosophical one though.

Strategically, Agile depends on Customer Collaboration over Contract Negotiation.  Hourly rates encourage collaboration.  The customer wants to make sure its money is spent wisely, and communication is required to keep the work flowing and thus the money coming.

Fixed price projects immediately put the contractor at odds with the customer.  At the moment the contract is signed, it is the contractor’s responsibility to work as little as possible for the project. Conversely, the customer is responsible for getting as much work done for the same money as it can.

Immediately, we are in a competition for which there is no real winner.

Does that sound like collaboration to you? Me neither.

If a customer requests a fixed proce, just tell them no.  Send them here. Explain.  If they insist, turn down the project.  It isn’t worth it. Very little good comes from projects that try to be Agile with the customers and contractors at odds.

Testing is awesome.

Many developers think that writing code is their job. That is not true. The job of the developer is to “Deliver working software frequently…” If you don’t test it, it isn’t working.

There is a limit to what can be reasonably tested, however. It is unreasonable to test what happens if SP1 isn’t applies to SQL Server. You can test for it, but it isn’t reasonable. It is reasonable to require that QA matches Production. Sometimes it doesn’t, though, and if you haven’t tested for that eventuality then you have a production failure.

In an attempt to make that limit of what can be tested as far away as possible, some opt for “Test Coverage.” Test coverage shows the number of members of the logic classes that are covered by unit tests. The instances are usually mocked to maintain atomiticity of the tests. The idea is that one test tests one method that has a single responsibility, and you can see right where your problems are.

Unit tests are a poor way to test software though. It is true that most errors are in the logic of a transactional system, but all of the rest of the potential problems - those related to system interaction - are utterly untested by unit tests.

In transactional systems, integration testing is where it is at. Unit tests are awesome for complex methods, but really you want to test is the integration between modules. If you happen to catch an error in one of the modules then fine, fix it of course. The integration test will catch those and the communication. The unit test will just catch errors in the module.

Wouldn’t you rather catch both? I would.

So why the focus on unit testing? A couple of reasons. First, you can legitimately design your software using the unit tests. It’s called Test Driven Development, and it is all the rage.

Don’t do it.  If you need design, then design. Tests are for testing, not for design.

The second is for atomicity. Atomicity is testing one thing at a time. Awesome in theory. In practice, however, the line with the error turns yellow and has a big box next to it. Oh, don’t use an IDE? Sorry, you are too cool for me. You get what you deserve.

The third is laziness. Integration testing is hard. Sometimes, it is really hard, and takes as long to write as the code itself. Unit testing is usually fairly easy. It isn’t always easy - especially to write good unit tests. But most people don’t write good unit tests, and even bad integration tests are sorta hard to write. So, people write mediocre unit tests, and point to the TDD manifestos as a reason for being. Meh.

Remember what testing is for. It’s to make sure the software works.

Remember that “Working software is the primary measure of progress.” Code coverage isn’t. Number of unit tests isn’t.

Remember that saying “That error in production was one that wasn’t covered in my unit tests.” does not excuse the production outage.

Remember that the goal is to astonish the customers with software that does what they expect. They don’t care about your metrics. They care about working software.

What’s the opposite of Agile?

Waterfall of course! Right?

No, actually, waterfall doesn’t really exist. The term was more or less created as a term of derision by supporters of Rapid Application Development based on a paper by Winston Royce back in 1970 titled “Managing the Development of Large Software Systems.” He was asked by the Department Of Defense to create a rigorous process for the development of software with zero defects.

He designed such a process. Even he admitted that “the implementation described above is risky and invites failure.” He notes that the process allows for no changes in requirements. He notes that testing is too far from development, and failed tests mean expensive redesigns. The client must accept these costs.

What’s more, the term ‘Waterfall” doesn’t appear anywhere in the paper.

The paper was prepared for IEEE and as such it is difficult to read between the lines. It seems to me that Dr. Royce was trying to point out eh infeasibility of such a scheme, and even lay the path for a more RAD style of development methodology. In short, I don’t think he meant for people to take him seriously.

But people did.

Now, if you are coding software for the space shuttle, the Royce process might actually work. You are coding against set hardware capabilities, so requirements don’t change. There does need to be zero defects. And money is less of an issue (until recently).

But in a business environment this is clearly not the way to build software. Anyone who thinks it does is addled. And yet, Agile purists constantly cite the paper an the zen example fo why software development sucks in the 21st century.

Royce says that for every million dollars worth of project, there needs to be at minimum 300 pages of specification based on his research. Just specification!! So what do the new-agers say? Zero documentation! We are so good we don’t need to write anything down.

Please. There is middle ground here. I’m sure the devs on your team can code everything right from requirements without writing anything down or having it looked at by a lead or architect, but, well, the rest of us can’t. So please stop telling people to never document things. It’s an awful idea.

That said, “Simplicity is essential.” You don’t need to write everything down.  You don’t need to slavishly use the document forever as a barrier to change. Creation of a document for a complex design or to make certian everyone is on the same page is not a replacement for face to face interaction with the business unit.

Planning isn’t bad. Sitting down and figuring out how to get things done, what to get done, and about when these things will get done is doable and even expected. Notating every single detail is - and always has been - impractical. No one was ever suggesting it was a good idea, and it isn’t a good idea to make a 180 degree shift, either.

The 12 Principles of Agile Software Development get quoted and mentioned quite often on these pages.  Seems a good time to present them in whole, and talk about what they are and are not.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This means deliver features, not code. This doesn’t mean spend more time giving show and tells than coding.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This means don’t be a slave to the requirements. This doesn’t mean you shouldn’t collect requirements.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This means you should create feature batches that fit within defined work units. This doesn’t mean to work a logarithmic number of hours every three weeks.

Business people and developers must work together daily throughout the project.

This means just what it says. If you aren’t doing this already, we got trouble.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This means get good machines and software, keep them up to date and stop complaining. This doesn’t mean force your team to use VIM.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This means have standups and feature design meetings. This doens’t mean the dev team has to cram in a room and sit on beanbags.

Working software is the primary measure of progress.

This means shipping is a feature. This doesn’t mean you can skip user docs, status reports or integration tests.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This means work 40 hour weeks, or less. This doesn’t mean you have to sell your life to the project.

Continuous attention to technical excellence and good design enhances agility.

This means you need to sharpen the saw. This doesn’t mean you need to change languages/IDEs every 2 weeks to be a good dev.

Simplicity—the art of maximizing the amount of work not done—is essential.

This means write less code, write less specification, make less stuff. This doesn’t mean import every framework on sourceforge into your project.

The best architectures, requirements, and designs emerge from self-organizing teams.

This means there shouldn’t be more managers than devs. This doens’t mean there should be zero management.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This means your team should hold retrospectives. This doesn’t mean you should change frameworks every iteration.

The principles are great guidelines. Don’t read too much into them.

Nowhere in the Agile Principles does it say that the development team should mock estimation.

This comes from an understandable source. Project managers, in their haste to make detailed plans using evil tools like Microsoft Project and whatnot, force developers to make unreasonable and unrealistic guesses as to what it would take to develop against a set of unfinished requirements. In backlash, the developer uses one of the principles to tell him to stuff it:

Working software is the primary measure of progress.

I don’t blame them. Really I don’t. I am often quoted as saying my primary job as a software analyst is to make the project manager cry st least once a day.

Nonetheless, this is about the most sub-realistic idea I have ever heard about software development. No business will buy any service or product without some idea of what it will take in terms of money or time. Sorry, that’s just stupid. Hate to break it to you, but the dev team is a cog in a larger wheel, and the rest of that wheel won’t just hang out while the dev team just tokes and sings Kum Ba Ya.

At some point, the development arm has to answer to the rest of the organization. But that’s just it: the dev team is part of that wheel. They should have a seat at the table, not be represented by a informationless project manager, and speak up for themselves. From the Principles:

Business people and developers must work together daily throughout the project.

That isn’t optional. You - the developer - needs to sit at the table with Finance and Marketing and Engineering and Sales and Accounting and HR and who ever the hell else is involved, and realistically put your two cents in.Now, does that mean that you have to tell them face to face “Hey, I can’t even give you an estimate until I have had my team analyze this fully and make sure you haven’t missed anything”?

Yes.  Yes it does.

Fear of speaking out? Too bad. Hire someone who can.

Then, once you have helped the rest of the business understand what it takes to get your job done, do your fucking job. Figure out what it is gonna take to get the job done.

Then do it.

Don’t know how to estimate? Too bad. Hire someone who can.

Personally I have run almost seventy five million dollars worth of projects through Function Point Analysis, and have never been off by more than ten percent. Did the scope change? Sure. Did we have to manage expectations of the rest of the team? You bet. Did we do it? Uh huh, because it is part of our job.

So, the next time a consultant tells you that you need to be educated on the worthlessness of estimation and would you like to be introduced to sizing, tell them that you are planning on delivering working software frequently, and yes, yes you will be telling the rest of the team what will be done when. Then ask them to leave.

It all started with a sales pitch:

“We bring cloud based solutions into your development team with an agile methodology that ensures delivery on-time and on-budget.”

“What bullshit,” I said.

“Excuse me?” the admittedly calm sales rep proffered. “You disagree?”

“Describe any two of the four parts of the Agile Manifesto.” I challenged.

“Agile Manifesto?”

“I’m sorry, I have programming to do.” I left.

For every sufficiently complex problem, there are a few solutions and a thousand charlatans that purport to have the solution. Agile breeds those people like flies for some reason - flies on bullshit. I don’t know why. But it is true.  Look at every “about us” page for every consulting firm in your city.  They will all have some claim to Agile Software development.

The problem isn’t even that many of them don’t do Agile properly. The problem is that few managers can tell the difference so it is the company with the slickest sales pitch that often will get the work. Yes, I know, it all comes out in the wash and the best software will win, blah blah blah. But it isn’t like that. Some companies and projects have deep pockets and can throw good money after bad and win through sheer attrition.

That sucks.

Fact is, Agile is simple. It is, as my friend and mentor Pete Gordon put it, all about communication, trust and accountability. Some ten years ago now several of the best minds in software analysis and development came together to write down a few straightforward truisms:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.[1]

None of this changes how we develop software, really. Those of us who do it well will still use the best tools available and occasionally write down how we are going to do things. What the Agile Manifesto is trying to remind us is that we are in cooperation with the business, and that cooperation is what makes the good software good.

Everything else that people shoehorn in as a ‘part’ of Agile is just bullshit. Test coverage is not part of Agile. Eschewing estimation is not part of Agile. Dynamic and functional language programming is not part of Agile.

Agile is communication, trust and accountability. And that’s it. The rest is bullshit.

For more of what Agile is, read the Principles[2]. For more of what Agile isn’t, follow and learn.