Haven't posted on this forum in years, and for some reason thought to check back tonight. Glad I did!
Dj_Jestar is the one speaking the most sense in this thread. I hate the 'Oh yah we need to totally do Agile' camp as much as the next guy, but that doesn't mean we don't employ 'Agile methodologies' throughout our business and projects and reap the rewards every day as a result.
As he says, it's not some prescribed thing that you
must adhere to at all costs, it's about using techniques and processes that deliver satisfaction for both you and the Customer.
Once you get past the hipster/jobber types who just
need to be able to say they've got experience of using the latest buzz word, you remember that Agile was created because historically, and to this day, there are very real problems with big software projects failing to deliver on-time, to budget, or to spec.
Yes, you might be able to deliver a website within an agreed timeframe and to an agreed budget, and have the reams of contractual paperwork to say that you will. But a software project with any modicum of complexity? You've made a rod for your own back from day one and you will lose more clients than you will retain.
The reason being because if you're working on anything complex or interesting, you can't accurately predict timescales or costs to any great degree. You think you can document how you'll integrate a dozen disparate systems, across multiple platforms, consider every piece of domain specific strangeness, and cater for all of the vast swathes of minutia before you've even sat down to write a line of code? You're mistaken, or you're working on boring projects or problems.
For the people quoting impressive sounding clients and even more impressive budgets, get a life you snobs. I've worked with lots of blue chip companies, Barclays, Lloyds and so on on £10m+ projects and by far and away the biggest 'takeaway' from each and everyone of them is this:
they don't know what they're doing and they're probably doing it badly. Missed deadlines, poorly managed projects, bad code, angry customers, binned/shelved projects.
Of course, not
every project goes that way, not every waterfall project is a disaster. Nor am I advocating (which I think DjJ is...) that there should be no contract or documentation before coding starts.
So to answer the OP:
- Initial meeting. Discuss broad requirements. Discuss possible solutions.
- Brief sales cycle! Don't waste time and money trying to catch the elusive whale. Present our initial thoughts, possible approaches to the problems presented. Tell them our day rates.
- If they're keen to hear more, small number of follow up meetings or days on site to discuss slightly lower level detail.
- Produce a formal Project Specification. Keep it broad, avoid the detail as all of it is subject to change. Back it up with a similarly broad contract: rates, estimated time scales for features, number of developers, PMs, etc
- Project signed off and they're on the clock. More meetings for detailed requirements gathering, business knowledge, etc.
- Produce brief, quite high level design documentation on Confluence for features/requirements discussed
- Any low-level detail or requirement (e.g. have a screen to show this, make this field do this, we need to store this attribute, use case xyz etc) is an issue within JIRA. It doesn't belong in any documentation.
- Low level details belong to Epics. Epics are roughly analogous with the broad topics covered in the formal specification, though will grow in number as the project grows.
- Produce high level design documentation on wiki (Confluence). Mockups, use cases, UML diagrams, etc
- Have 1-2 week sprints. Employ TDD as appropriate. Each developer is running the testing suite locally dozens of times per day. Every commit is linked automatically to its issue(s) via smart commits. Every issue is linked to relevant documentation. Deploy to testing every day, staging once issues closed. We should be progressing at least half a dozen issues per day per developer, if not the issues aren't granular enough and the developer should be breaking them down into separate issues or sub-tasks
- Conduct daily code reviews (every developer has a review partner, 0.5-1 hour of their day is reviewing their partners code).
- Build/testing server (semaphore) that pulls and builds every push and runs the full test suite, gives code coverage. The dev team for the project all get emailed results (and its integrated into Hipchat...).
- Automatic code heuristics: every push is processed and scored (CodeClimate) for bad code (code smells, vulnerabilities, complexity, etc)
- Have weekly or fortnightly calls with the 'key decision makers' or 'project sponsors' to discuss and demo progress on the staging server (they get to touch and feel it!) or via screenshare. Have monthly on-sites with the client. Every meeting and call is 'minuted' (i.e. notes are made, not blow by blow), these are where the detailed requirements are identified.
- The client has access to everything. The documentation, the issue tracker, every deployment server. They can read, comment on, monitor and track everything we do. This gives them ultimate visibility. They can see we are making progress, and see that there money is being well spent.
- Deadlines are still important, but are only achievable on a granular scale: as well as organising issues into epics we also organise them into versions, versions have due dates and a set number of issues.
Sorry, that ended up being a lot longer than anticipated! But here's the thing: writing it out I'm actually proud that that's the system of work we've put together. The vast majority of blue chips or non-tech public companies would have nowhere near that level of amazing.
For every client we've won, they are still our client. We are now engaged with them on other projects or extensions. Projects have been completed, we have never needed a fixed deadline. Not once have I had to have difficult discussions with them about extending budgets, or finding a price for every feature. Not once have I worried about a meeting or call with them. They have visibility of everything we do, and the costs are agreed and understood from the day the contract is signed. Our clients are happy.
Yes, a company needs to forecast, but they do that at the developer level, not the project level. Fundamentally they're outsourcing, but all of our staff work in our office and get all of the benefits that brings.
If a client came to me with a fixed deadline, a 500 clause contract complete with penalty clauses, I'd quite happily walk away, no matter the budget.
If you can't convince the client that you're selling them your ability to see their vision in detail, and can work for them to implement it, and will be delivering them real, tangible (i.e. they can see/touch/feel it!) value from day one - then you're no good at your job.
As DjJ pointed out - look at any software company that is making software you admire. Microsoft, FB, Google, Atlassian, Twitter, etc. They are all doing this. Then look at the companies that aren't, and the software they're producing. Ask yourself if you'd want to work for them, I know I wouldn't.
Now don't get me wrong, we're still a relatively small dev company. We're not IBM, but who the **** with any clue about his trade would want to be. I started the company three years ago and so far and all fingers crossed we are doing very well, and I owe it all to Agile!
