11 Agile Myths and 2 Truths

I deliver a lot of Agile training courses and I give a lot of talks about Agile (BCS Bristol tonight). There are some questions that come up again and again which are the result of myths people have come to believe about Agile. Consequently I spend my time debunking these myths again and again.

I’ve been keeping a little list and there are 11 reoccurring myths. There are also two truths which are a bit more difficult for teams and companies to accept.

Agile Myths

1. Agile is new: No, the Agile manifesto was published in 2001, the Scrum Pattern language was works hoped at PLoP 1998, the Episodes pattern language (the forerunner of XP) was workshopped at PLoP 1995, Tom Gilb’s Evo method dates back to 1976 and there are some who trace things back further.
2. Agile means No Documentation: You can have as much documentation as you like in Agile. Documentation is just another deliverable, if it brings you value then schedule it and product it like anything else. Please be aware: documentation is often unread, often fails to communicate, is used as a defensive tool and is typically the second most expensive think on a large software project (after rework).
3. Agile means No Design: No, Agile probably means MORE DESIGN. Design is inherent all the way through development, at every planning meeting and more. Agile does mean the end to big-up-front design which is invalidated five minutes after someone starts coding.
4. Agile means No Planning: No, again, Agile probably has more planning. Again planning is spread out through the whole development exercise rather than at the front and it is the work of everybody rather than one or two anointed individuals.
5. Developers get to do what they like: No, if this is true for you then you are doing it wrong, please call me. Agile needs more discipline from the team and what gets done should be lead from a specific role usually designated the Customer or Product Owner and usually played by a Product Manager or Business Analyst. If developers are doing what they like then there is a failure of in this role.
6. There is a right size for a User Story: There is no right size for a user story. Every team is different, get over it.
7. Work must fit in a Sprint: If you are doing Hard Core Scrum then Yes. If you are playing Agile the way I do (which I now call Xanpan) then No. In fact I advise letting stories span sprints in order to improve flow. You can have stories spanning sprints but we won’t let them continue for ever and we will try and break them down into smaller pieces of work.
8. Scrum and Kanban are sworn enemies: No but the marketing efforts behind each they can get a lot of eyeballs by playing it that way. Xanpan is a Kanban/XP hybrid, and XP isn’t that different to Scrum so there you go.
9. Agile doesn’t work for fixed deadline projects: No, Agile works best in fixed deadline project environments.
10. Agile doesn’t work on Brownfield projects: No, Agile works best in brownfield environments. Granted retrofitting automated unit tests is harder but it is far from insurmountable.
11. Agile doesn’t work on Greenfield projects: No but your first objective is to get yourself to a steady state where you can think like a brownfield project.

To my mind the ideal project to start an Agile initiative with is a brownfield system with a fixed deadline in about 3 to 6 months where development has started but requirements are still unclear.

1. Now two truths about Agile:

1. Agile will not work for us because… (complete this sentence for yourself)
2. Agile is a good idea but … we should wait until we have finished X, got Y to buy in, bought Z and the (new) Pope has given it his blessing

You can always talk yourself out of it or find a good reason for not doing it today.

Agile Advice for Aviva (and many other big companies)

I’m starting this blog entry on the train returning to London after speaking at Sync Conference in Norwich - and I’m finishing sitting in my local coffee shop on Tuesday. (My conference presentation Agile in 90 minutes is online (PDF) or via Slideshare.)

An awful lot of people at SyncConf worked for Aviva and during the day I spoke to many of them. Aviva are trying to be “Agile” but like every other big company are struggling.

Personally I’m pessimistic about their chances. Someone asked me if I could name a big company which had made the Agile change and I struggled. Yes, many big companies are trying Agile, and yes there are many successful teams in these companies. But has an entire company made the entire change? I don’t know of any.

All the banks are trying it, and all are failing in similar ways (see Reverse-Tolstoy and Why Agile will Never work in Investment Banking). Many other big corporations are trying and most of what I here is not positive.

During the day I did build up a picture of much that is happening inside Aviva and I did give some advice in conversations. Now I’ve thought about it there is some more, bullet points below.

(I can say this because Aviva are not my client - OK, I did do a little work with them years about but it was insignificant. If Aviva were my client I wouldn’t be writing this blog, I don’t speak openly like this about clients. I try to avoid talking about active clients at all in this blog. Nor am I in the habit of giving unsolicited free advice to clients.)

Advice for Top

• There are no Silver Bullets: Conway’s Law, Reverse-Conway’s Law, Brooks Law, Goodhart’s Law and dis-economies of scale constrain what can be done.
• Take Software Craftsmanship seriously: Start and apprenticeship programme - speak to Jason Gorman about how the BBC do it
• Let a thousand flowers bloom: dump any attempts at standardised working and let people experiment, let them have fun as they learn and change. In a few years time when you’ve made lots of progress start to mine out your own “Good practices” and sharing them amount teams.
• (That also means be prepared to work with multiple difference consultants, coaches and advisors. Accept they will give you different advice. Yes engage with some big players but also work with the small players.)
• Embrace dis-economies of scale - you don’t have time to be involved with the details so delegate
• Get with Quality: the Quanlity v. Time trade-off is the reverse of what you think; higher quality (i.e. reduced bug count) makes for shorter scheduled, shorter schedules makes for lower costs, together this make for happier customers and more responsive business
• Get clear about what you want: if it is cutting costs say so, you can use some of the Agile toolkit for this but don’t expect to use it all or achieve Agility. There is nothing wrong with not being Agile if you have a better alternative.
• Pay the SyncConf Norwich team to re-run the conference again (with a few tweaks) inside the company. (You’ll have to pay the speakers but this will be a drop in your ocean of your IT budget.)
• Go further and let give employees attending seed money, let them spend it to sign up for courses and bring in some of the consultants they liked into the company. Yes this is radical, no apologies.
• If you want to be Agile then accept that it won’t be the lowest costs, it should result in the greatest value overall so focus on value not costs
• Your business and IT operations need to be more joined up. Maybe you want to dismantle your IT group, at least embed it in the business.
• Your annual planning cycle needs to relax, you need to learn to start small pieces of work without having every T crossed an i dotted.
• In the long run you want to look to Beyond Budgetting.
• Don’t worry about your CMMI or ISO or whatever accreditation, my clients have FDA and ISO-13485 approval, if they can do it so can you.
• In the meantime give up on strategic planning: that idea died in the paddy fields of Vietnam thanks to Robert MacNamara. Go read Henry Mintzberg “Rise and Fall of Strategic Planning”.

Advice for the Middle

• Visualise, visualise, visualise: boards, graphs, everything!
• You have to lead the top, they don’t know how to spell TDD so educate them
• Involve “the business”, their representatives in everything
• Get with the Quality Agenda: ditto the above, embrace and push quality to eliminate bugs. Give your team support, send them on training, hire consultants to come and coach, buy them books.
• Architects must also code
• Celebrate every little success; make sure the whole company knows about a realise
• Spend on travel: Indian outsourcing doesn’t work because you paid TCS, you actually have to go there and see, they have to come here and see, you need to talk, talk, talk. Skype, VOIP, everything
• Don’t spend money on expensive test tools
• Manage teams as a whole: not a Test Team and a Test Manager there, and a Dev Team and a Dev Manager there, and a BA…. the whole team wins or looses together.
• There is no long term future for Test Managers, you options are: a) focus on Test and work to improve the Testing Process, specifically Automation; b) focus on management and manage the whole development team; c) disentangle Test from Quality and become get Quality throughout the process
• Form self-support book study groups: spend an hour, meet for lunch every other week, agree a book, agree a chapter in advance, someone volunteer to summarise it. Open each meeting by going once around the table and having someone say something positive (“Tell me something that made you smile today?” “Tell me something you learned this week?”).
• Good luck: you have the hardest task, and its lonely. Some of you will need to lay down your jobs to make this happen

Advice for the Workers

• You control the means of product, Agile is in your hands, Make it So. Your greatest weapon is Quality, you have the power to improve it today.
• Embrace Test Driven Development, Refactoring (i.e. emergent design.) Dump big-up-front design, get coding on day-1 and work out the design later.
• You have to lead the middle and they will lead the top. Neither of these two groups knows as much about your work as you do. Lead by showing them what works. Which means…
• You have to do it, make those improvements. Developers start learning TDD, spend your own money if you need to. Testers: download the open source test automation tools and enrol developers to help you get them working.
• Testers: Automation, Automation, Automation - get with the Open Source tools - Selenium, FIT/Fitnesse, Cucumber, etc. etc.
• Form your own study groups
• Make sure retrospectives happen and action items are actioned

Most of this advice is applicable to any large company. I really don’t know that much about the inside of your company, I’m assuming. Nor is this list really that different from the one I published on InfoQ last year - 10 things for making your Agile adoption successful.

Finally, Aviva, you don’t have to take any of my advice but a) I guess your paid advisors are saying similar things and b) if you don’t change new competitors will kill you; you are big so it will take time but it is never nice to watch a big animal in pain.

Speaking at PAM - Project & Analysis Management Summit (Poland)

I’ve never been to Poland so when the invitation arrived to speak at the Project and Analysis Management Summit in Cracow it was hard to resist. However, I probably should have trodden more carefully. After a talking it over with the organisers I agreed to give a talk entitled:

“Is there a role for Project Managers and Business Analysts on Agile?”

For many Project Managers and Business Analysts this is The Big Question. Indeed, their jobs are on the line. While I’ve talked about both halts of this question before I’ve never put it all together. Now I’ll have to, a challenge, I’m part intimidated, part enthused.

So to start off with I thought I’d take a slightly different approach to the synopsis, let me know what you think:

Pity the poor Project Manager

There have no place in Agile,

Or so they say

Scrum Masters rule! Or rather they don't

Facilitate, Teach, Inspire, anything but Manage!

Or so they say

And where is the Business Analyst?

A void in every Agile book, blog and Tweet

The silence is defining

So tell me why, Why do many Agile teams have PMs and BAs?

Tell me, Do they add value? What should they do?

And tell me why, Why do Agilists dislike them so?

In this session Allan Kelly will attempt to untangle this conundrum, answer these questions and more.

SOA is software equivalent of a fast breeder reactor

A fast breeder nuclear reactor is a wonderful idea. Basically, you put in used nuclear fuel from a conventional reactor, burn it, produce useful electricity and at the end of the process the used fuel has changed into a form you can put back into a conventional reactor.

Alternatively, another use for the final product is put in nuclear bombs but we don’t like to mention that.

Fast breeders have been shown to work but have failed to take over the world. They are very expensive to build and operate, pose security dangers and are hideously complex to operate - as you might imagine of a device cooled by liquid sodium, lead or mercury.

In other words: they are not commercially viable.

They aren’t even sensible to Governments.

I have come to the conclusion that in the software world Service Oriented Architecture, SOA for short, is the equivalent of a fast breeder.

SOA works in the laboratory. The technology can be shown to work by big service companies - IBM, Accenture and co. It seems like a great idea.

But… SOA doesn’t make commercial sense.

Let me explain why I believe this.

SOA is all about Reuse. Reusable code and systems.

Reuse does not come for free, you have to write code for reuse. Figures on cost of reuse v. cost of single use are not common. As a general rule I refer to Fred Brooks 1974 observation that it costs about 3 times more. Admittedly not a solid reference but the best I know.

The first problem is: do you know it is going to be reused?

If you write an SOA system and then find it is used once then it is very expensive.

In order to know it will be used more than once you need to accept requirements from multiple sources.

Which means your requirements costs go up, response times go up, responsiveness goes down. Which means you loose time and money.

Worse still, the loss of focus leads to distracted teams, complicated stakeholder management and competing interests. You risk producing a camel rather than a horse.

There is also an assumption here that there is enough commonality that can be factored out for reuse to make the whole thing viable.

Now SOA, and reuse, are sexy. Its something all developers want to do. And they want to do it properly. And such projects tend to be technically driven.

So they loose their business focus and get absorbed in details.

Then there is the matter of testing. Testing costs also go up.

Add in maintenance: fixing a bug in one system is going to hit other systems, all of them need testing. (“Write once, test many” as we used to say in the early days of Java.)

And who pays for this?

If it comes out of the IT budget we again loose business drivers and increase technical focus. But if one group pays for it they are paying far more than they would need to for single use. And if you apportion costs you are going to spend a lot of time arguing.

In other words: SOA works in the lab but not in commercial environments.

My advice, as is with any type of reuse: write it for the problem in hand, get something that works, have plenty of automated tests. And wait. When someone comes along with a problem that looks similar, a real candidate for “reuse” modify the thing you have just enough to cope with this, with tests. Then wait and repeat.

This way you only pay the cost of reuse when someone actually wants it.

SOA and Fast Breeder reactors both belong to the class of technologies which while possible, even fascinating, don’t stake up commercially. Actually, come to think of it that covers most forms of software reuse and nuclear power.