We use sort of agile techniques for some projects, which makes our job in security that much harder, as instead of going away, having a think and perscribing a set of controls and getting the project to sign off on the residual risk, you end up doing a set of controls, and then having to attend a huge series of scrum meetings where you have to find ways of saying no which sound like yes... Works for some projects, but not all.
How is work planned/done at your place?
- Thread starter antijoke
- Start date
The thing is rapid iteration and testing has been the basis of software development since the 1970s, you don't need to wrap it up in any modern lingo.
There are issues with the Agile approach even if the project would work well with Agile methodologies. This has been highlighted in this thread by others sharing their real-world experience. When a company pays for another company to do something you need some kind of reasonably detailed contract to explain in black and white what exactly will be done, what will be the cost, and when the product will be delivered. If you don't then it opens up huge amount of legal issues. If there is no detailed contract then when the software company deliver what they think the client wanted and the client doesn't like then perhaps they simply wont pay because the developers have produced what was asked for.
That legal contract is best done as a detailed specification of the customers requirements. Then there is a black and white legally binding list of of deliverable and the client has no way out. If the client changes their requirements then new contracts with new specification and new price negations can be legally documented.
Sure, if a company is its own customer then all of that business reality goes away and you can forget detailed specifications. We do this ourselves for our internal stuff, we just code away without any notion of iteration because development is continuous. Ever push to git gets released on the alpha server, ever couple of days alpha gets pushed to beta. When QA has passed beta is pushed to production when it wont interfere with clients. that might happen within hours if we are adding an urgent feature for a client, it might not happen for months if nothing important is developed.
1: Get a request from someone in the business
2: Say I can or cannot do it
3: Go back to business for some brief specs
4: Build a test version.
5: Business Feedback
6: Tweek the test Version
7: Business Feedback
Until
20: Business is happy and application/utility built
21 - 5000000, deal with constant requests for enhancements and new features.
2: Say I can or cannot do it
3: Go back to business for some brief specs
4: Build a test version.
5: Business Feedback
6: Tweek the test Version
7: Business Feedback
Until
20: Business is happy and application/utility built
21 - 5000000, deal with constant requests for enhancements and new features.
Associate
- Joined
- 24 Jun 2007
- Posts
- 1,869
- Location
- Landan.
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:
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!
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!
Last edited:
Associate
- Joined
- 24 Jun 2007
- Posts
- 1,869
- Location
- Landan.
Primarily Ruby/RoR, but we've got C# and Java projects too
While I generally agree with slylittlefox I find it interesting that all the software companies listed make their own products. They aren't software houses, they can define their own work pattern / release schedule etc far better that when an external entity (perhaps with no understanding of how software development works) is the source of income.
Just to re-iterate i'd love to work in the environment slylittlefox does, just hasn't ever worked as smoothly as that everywhere i've deved so far.
Just to re-iterate i'd love to work in the environment slylittlefox does, just hasn't ever worked as smoothly as that everywhere i've deved so far.
Interesting thread, thanks to all those who answered.
1/ Feature requests / bug reports come in from customers and within the company
2/ Someone who thankfully isn't me sorts these into a priority queue
3/ The top few things from the queue form the aim of the next sprint
Testing is pretty hardcore. Unit tests and integration tests run locally on demand and on CI servers. Performance tests on the CI servers. Then unreasonably big system tests. Probably some manual testing on occasion as well.
Agile seems to be working out pretty well, possibly because the customers are developers themselves and fairly easy to sell on the concept.
1/ Feature requests / bug reports come in from customers and within the company
2/ Someone who thankfully isn't me sorts these into a priority queue
3/ The top few things from the queue form the aim of the next sprint
Testing is pretty hardcore. Unit tests and integration tests run locally on demand and on CI servers. Performance tests on the CI servers. Then unreasonably big system tests. Probably some manual testing on occasion as well.
Agile seems to be working out pretty well, possibly because the customers are developers themselves and fairly easy to sell on the concept.
I've quoted the relevant part. That statement alone means you would never do work do defense, aerospace, national security, or government. If that is the areas your company is supposed to operate in then that isn't a successful business model, end of.
I've done work for government, defense, national security. They loved the iterative approach and minimal faff with documentation and contracts. "End of."
And what an ego you must have to think you can ignore such a swathe of information to focus on one tiny little bit and call that the only relevant part.
And what an ego you must have to think you can ignore such a swathe of information to focus on one tiny little bit and call that the only relevant part.
I didn't ignore it, it is just not relevant to the discussion in hand.
Your experiences entirely different to my experience dealing with defense contracts and the like. The parent company I work for recently was awarded a share of a 100m+ defense project - Ive seen the 500page specification in person. It took 5+ years to secure the funding, any changes to the funding or timeline will require approval from senior admirals in the US air-force.
Don't forget, the waterfall model is iterative, merely the iterations are over larger timelines due to the scale of the projects involved.
this thread just highlights the issues with Agile aficionados, they are just so closed minded and fail to look at the bigger picture. there are multiple different project management techniques suitable for software development. they all have pros, they all have cons, they all can work very well, they can all fail very badly, they can all work better in than others in specific domains, there is no empirical evidence that Agile does any better than anything else. End of. Agile can work, so can others, it depends on the project and the PM, not the ideologically stance one takes.
As I said, we use an extreme version of Agile for our internal projects because that is what works the best for a startup. That doesn't work in other areas. That isn't rocket science but common knowledge of open minded developers.
https://blog.udemy.com/agile-vs-waterfall/
Last edited:
All of it is relevant. You just decide to ignore that which you can't refute or something.
As for you "agile aficionados" comment - you were the first to draw a line in the sand. What does that say about "Waterfall Aficionados" ? You're also the one simply dismissing anything posted that isn't your way of doing things under the "Agile bubkis" umbrella. So who is that is really having problems seeing the bigger picture, D.P. ? You've been exceptionally "my way or the highway". Pot calling kettle black.
Waterfall is "iterative" in the sense that it has a single iteration over the course of the entire project. "Plan as much as you can, then action it, then everything else charge as T&M" is not iterative. (Before you try to rebuke this as not how you work - it is exactly what you describe in this thread, with the ever so quaint arrogance of "anything else is just more profits")
As for you "agile aficionados" comment - you were the first to draw a line in the sand. What does that say about "Waterfall Aficionados" ? You're also the one simply dismissing anything posted that isn't your way of doing things under the "Agile bubkis" umbrella. So who is that is really having problems seeing the bigger picture, D.P. ? You've been exceptionally "my way or the highway". Pot calling kettle black.
Waterfall is "iterative" in the sense that it has a single iteration over the course of the entire project. "Plan as much as you can, then action it, then everything else charge as T&M" is not iterative. (Before you try to rebuke this as not how you work - it is exactly what you describe in this thread, with the ever so quaint arrogance of "anything else is just more profits")
Last edited:
Aren't you worried that will take a very, very long time to come through?
I don't work in web development but I do write software, for a very well trained client - I am employed BTW, they pay my employer for my services.
Since I know them very well and they know and trust me, they give me an idea and I run with it - they pay T&M. For anything complicated I start with producing the screen and once they are happy with it I fill in the logic behind it. I find they often don't know what they want until they see something that isn't what they want!
However this comes from a position of exceptional trust. Given that I am worth of that trust, it's far cheaper for them than a more formal approach which would include time writing a formal spec, signing it off, and contingency.
In other words there isn't a one size fits all approach to this. This customer also uses a full-on Prince2 for some projects which don't have a better outcome than the ones run very loosely with me. In fact they usually turn out worse and cost a lot more.
Since I know them very well and they know and trust me, they give me an idea and I run with it - they pay T&M. For anything complicated I start with producing the screen and once they are happy with it I fill in the logic behind it. I find they often don't know what they want until they see something that isn't what they want!
However this comes from a position of exceptional trust. Given that I am worth of that trust, it's far cheaper for them than a more formal approach which would include time writing a formal spec, signing it off, and contingency.
In other words there isn't a one size fits all approach to this. This customer also uses a full-on Prince2 for some projects which don't have a better outcome than the ones run very loosely with me. In fact they usually turn out worse and cost a lot more.
D.P. is right imo, and between the rest of the comments in here, I think the whole agile vs waterfall thing has been mostly covered. Waterfall needs bang on requirements, and can suffer very badly when the requirements captured do not reflect the vision of the consumer. Good engagement and contractual flexibility is key to this.
Agile fixes this, but can suffer from scope creep and lack of direction, good project management, and stakeholder management in particular is key to preventing this. A bad or inexperienced team can quickly turn agile into ad-hoc.
This point here is really the key to deciding what method to go down. Trust. When you are working on big government or defence systems, the supplier is trusted only in a very limited extent. It is very often the case that different teams on the project are siloed from each other, and only a small number of people have oversight as to what is being made as a whole. When this is a case, sprint planning is practically impossible. D.P. mentioned a senior admiral having to sign off changes, having to have very senior military and civil service officials is very common on large projects, and again prevents pure agile working.
The final point to consider is in the awarding of contracts, if you have a tightly defined scope and detailed requirements, then it is normall easier to evaluate supplier responses to your proposal.
Agile fixes this, but can suffer from scope creep and lack of direction, good project management, and stakeholder management in particular is key to preventing this. A bad or inexperienced team can quickly turn agile into ad-hoc.
This point here is really the key to deciding what method to go down. Trust. When you are working on big government or defence systems, the supplier is trusted only in a very limited extent. It is very often the case that different teams on the project are siloed from each other, and only a small number of people have oversight as to what is being made as a whole. When this is a case, sprint planning is practically impossible. D.P. mentioned a senior admiral having to sign off changes, having to have very senior military and civil service officials is very common on large projects, and again prevents pure agile working.
The final point to consider is in the awarding of contracts, if you have a tightly defined scope and detailed requirements, then it is normall easier to evaluate supplier responses to your proposal.
Its abut as relevant as what I had for breakfast or what OS I use.
Why should i try to refute something I agree with? You are just off on one of your tangents trying to an argument out of thin air.
This is what the OP asked:
Where did he ask about TDD or code review?
Unlike you, i am completely open mined about different project management ideologies and will happily employ whatever models work best for the project in hand. I am well aware of all the pros and cons and don't pray to a single Agile God to solve all my real world problems. Where have I said anything about "my way or the highway". All I have mentioned is that many clients and many projects do not suit an Agile approach, that isn't my opinion, that is a well known and well publicized fact and one of the many critiques of Agile. I have also interjected that many real world constraints prohibit the use of an open-ended development process - clients do have budgets and deadlines, business need to crate legally binding contracts to avoid being sued. As many others in this thread have pointed out [Soootylad, Mynight, touch, lsg1r, melvis], a decent spec upfront ensure both parties are not left open for litigation or disappointment. i've mentioned time and time again that Agile can be great, that nailing the client's specs can lead to issues as they are almost certainly wrong, my only point and that shared by a MAJORITY of responses to this thread, is that businesses need override ideal PM dreams. Clients believe they know what they want, they have definite budget and they have definite deadlines - that is how business works. If no formal contract is developed with enough detail to stand up in a court of law then both parties leave themselves in a lot of trouble. If the Agile developer goes way over time and way over budget because the client kept changing specs then the client can sue the developer and end up not paying. A robust spec document protects the developer from such litigation. "Client wanted X, Y and Z, we provided X,Y and Z as designated in the agreed upon and signed off spec documents." I have also said we use an Agile approach for all our internal stuff because we are our own client, understand the potential benefits and wont sue ourselves if we fail to hit the objectives.
No, the waterfall model has a series of stages, the sequences is then reiterated again and again until the customer is happy. Each iteration will seek to find desired changes and extensions based on testing feedback. If the client wants a load of new features then a new iteration can begin. Furthermore, within some of the stages iteration can happen, the development cycle itself can be just as iterative as Agile. Iterative software development has been a foundling principle since the 1960s.
Your entrance into this thread:
So open minded.
You change your tune so often it's impossible to know what song you are singing any more. You've gone from the above to now describing an iterative approach. Full U-turn.
So open minded.
You change your tune so often it's impossible to know what song you are singing any more. You've gone from the above to now describing an iterative approach. Full U-turn.
Last edited:
Yes, which is exactly why Agile doesn't work - the budget and deadlines are relatively fixed, as are the specifications because the specifications were derived over a period of 10 years in this instance. After extensive testing and analyzing they may come back with new specifications and will tenure a new project. Budget is allocated annually for these kinds of things and will be adjusted based on federal budget changes, so even when a project is greenlighted it will take a few years before the money is thereto initiate the project.
Something else to consider on such projects - every single line of coded is analyzed by multiple security professionals to ascertain safety, liveness and security risks. Avery time consuming and expensive project but obviously necessary otherwise the developer could put in all sort of fun things things, like a backdoor for the Russians. Hence, testing is infrequent and occurs once the developer has signed off that the specifications are complete. The code is then burned to DVD and delivered by hand by a military personnel in a handcuffed briefcase.
And Agile isn't what client's want *most* of the time, it is what developers want, and is what developers want clients to want. In the real world, as pointed out by many posters in this thread, that simply does not happen.
You are just so closed minded you have an outdated list of preconceived notions regarding any other PM technique other than your chosen religion. Nothing stops you doing TDD iterative development within the development cycle of a "waterfall" project.
Last edited: