May 23, 2011 at 9:13 pm
Comments posted to this topic are about the item From Great Idea to End Result
May 23, 2011 at 11:40 pm
Your products single greatest feature is release.
May 24, 2011 at 2:13 am
I wholeheartedly agree. I'm lead developer on a new application for the bank I work for. We've been stuck in the familiar, drawn-out process of scope creep, revisiting specs half way through development etc. Development has been ongoing for months now and I can't help but feel that delivering an unfinished product as a starting point for further development would have allowed the business to make better decisions about the functionality required. One good decision I made was to break the large application into three smaller sections and agreeing to deliver each phase in a rolling deployment. This has made development much more focused (not quite the same topic but semi-relevant nonetheless).
I'm also interested in technologies like microsoft's lightswitch and will definitely be keen to try it out when it gets released. I hope these rapid development tools will let developers get to the situation described by Steve sooner.
I like the concept of final applications being seen as prototypes by the business but I have a feeling our risk review team (I work in a medium sized private bank) won't appreciate it too much!
May 24, 2011 at 4:03 am
I have worked in commercial IT since 1974 and have seen many approaches to getting applications delivered. The agile methodology using Scrum (and its variations) is by far the most effective way I have seen for delivering useable value to the business.
The key feature of Agile - incremental development and delivery - can be an initial shock to the business, but at my place and many others I have heard about the business soon grow to love this process.
Ultimately product development is about delivering business value as minimum cost, time and risk.
Approaches such as Prince try to deal with these issues by identifying all issues before incurring the development cost. But too often Prince fails as the cost and time of identifying issues adds significantly to the project and Prince does not do enough to reduce the risks associated with the inevitable change that occurrs while the project is running. It may be a bold statement, but in terms of risk reduction the experience of many organisations is that Prince is not fit for purpose.
Agile expects change to happen. The position of the organisation in the market-place is continually changing, and business priorities change as a result. A product deemed critical to success in month 1 often needs to look very different by month 12 if that success is to be achieved. Incremental development allows the latest needs to be scoped, risk-assessed, developed and delivered before they become obsolete.
it may well be that a well organised development team will deliver much the same number of Function Points using Prince or Agile. Certainly this is what we feel. But we also feel the points delivered by Agile were produced in less time, with less analysis staff, and are what the business needs. The Prince points too often ended up being what the business thought they needed some time back, and not what was actually needed at time of delivery.
Hopefully nothing too controversial in all that... 🙂
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 24, 2011 at 6:10 am
Ed, I agree about Scrum, it's a very interesting formula.
I also agree about velocity. Being in IT isn't the easy job, trying to figure out how to do things quickly without creating a mess that you (or the next guy) will have to clean up, mumbling the entire time. It's not all our fault, but some of it is. I like to think we're getting better at it.
May 24, 2011 at 7:15 am
I have to agree with Scrum as well - although I went through the training in my last role I jumped ship before doing too much.
I think it's success depends a lot on the management of the process, people adopting it and the politics being right in the organisation. There should also be enough documentation so that people are clear once agreed what is being developed. I've heard of a few examples of Dev's trying to worm their way out of things due to a post-it going missing or not enough detail.
May 24, 2011 at 7:29 am
Shudder.
Steve, that's a recipe for absolute disaster.
First, you're falling into the "get it out the door, we'll test it afterward" trap. Second, users will initially love it, and cause it to scale into failure, then abandon it and think IT are a bunch of idiots who can't program their way out of a paper bag.
Having said that, you can't allow feature creep either, and flexibility for future expansion isn't a luxury, it's "the only thing". Having been bitten by that bug more often than I care to think about I now ignore anyone who says "oh, that can't change, it's fundamental to *everything*. I just don't tell anyone I'm building flexibility into the design...
Ha.
You'd have thought 255 monetary denominations would have been enough for a USA only app too!
As a developer first and foremost I'll tell you that all the agility in the world won't help you if the foundation isn't nailed down nice and tight. Systems analysts may be out of vogue, but the need for what they do isn't.
You're quoting from the Great Management Book Of Fail, and it makes my blood run cold.
IT is always too slow for everybody--but guess who has to take the blame when that hastily prototyped project scales into immobility and there's no budget to fix it?
May 24, 2011 at 7:36 am
I have to agree with roger.plowman. I am in a small company with an equally small staff.
Projects routinely get started with a good plan and scope. After a short period of time the decision is made to just "get it out", with or without half of the requested features (usually reporting or administrative maintenance). Once it is out and working (no matter how well or not) we move on to the next greatest thing. We then spend to much time fixing/training/reparing data/etc.
May 24, 2011 at 7:56 am
To avoid doubt, Agile does not mean deliver whatever state it is in. There is a lot of rigour around Agile so that you only deliver what is working, and that what you deliver meets a minimum acceptable feature set. There is also tracking of 'technical debt', so if you cut corners it becomes obvious what you have done and how it affects ongoing delivery velocity.
BTW, one of our teams has some metal ducting over their team area, and they clip any cards describing technical debt on to this with magnets. It graphically shows how this debt could fall on their heads if not properly fixed.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 24, 2011 at 7:59 am
After about 25 years of this stuff, I'd have to say that my experience is that all successful application builds are "agile" regardless of name used on the method. The single track, up-front design methods are predicated on a chimera: No user community ever knows--or can know--exactly what the end product should do. They have dreams and thoughts and desires--some of which are spot-on, some of which are foolish, and all of which may seem perfectly reasonable on paper.
I recall one project in particular, an application to track customer claims (product deficiencies). There had been two previous attempts to write an application for this use, but the users were still tracking with spreadsheets, email, and conference calls. And not doing a very good job of it. Money got paid back to customers on claims, but root causes were not found. However, the job they did by hand was better than the (impossible to use) custom applications that had been written to the user's specifications.
The problem was, as I see it, that the users were being asked to do a job of creation--envisioning the end result in one fell swoop. Anyone who's ever done any art--or programming--knows that creation has revisions. Very few get it right on the first cut, and the problems we address are not normally capable of being so well defined. To end this cycle of developing useless applications to spec, I (at first) refused their input on new features. I gave the developer strict orders to only examine what they did now, a quick and dirty use case, and automate that. This decision was about as popular as you can imagine.
Even so, within a few weeks the developer was able to deliver a first-cut program that automated the job they were doing by hand. At this point, with the application in use--and it was seized and used immediately--we opened the door to suggestions. A number of those came in--some useful, some not. The entire operation took only a few months (maybe a tenth of the time that had been wasted on previous attempts), and the product was successful enough that in about a year, the quality issues had been tracked and handled well enough that the application was seeing very limited use--there were barely enough claims to track.
This wasn't a pure application of any methodology, but it sure was agile. While a success, it wasn't perfect. I believe I am still remembered as the guy who told the users "no, you are not first going create list of feature demands." And the project took place in the usual swirl of too much to do, so it could have benefited from tighter supervision. The DBA at the time was also managing the department (guess who that was). Some of the things the developer slipped into his application and database shouldn't have been. Even so, it followed the rule of figure out the basics, get something working and built on some kind of a stable foundation, and then add to that. Time will then tell if more money needs to be spent.
This is not to run down all the various methods for capturing needs, laying out functions, and so on. And I do agree that “just get something out the door” is not the way to go. I’ve fixed too much crap for that. But there is a middle ground. No method, or lack thereof, substitutes for judgment.
May 24, 2011 at 8:02 am
Nice one John!
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 24, 2011 at 8:21 am
Internally developed applications always seem to grow legs and walk away. The development staff gets roped into a support role. They resent not being able to work on the "new" stuff, and the Support teams are always chasing the developer/archtects to figure out how to make the damn thing behave! Agility without focus is fairly useless. Apps that are released to the world without a support plan, or a way to formally pipe the feedback in (and out) of the entire environment will not succeed over time.
May 24, 2011 at 8:37 am
roger.plowman (5/24/2011)
Shudder.Steve, that's a recipe for absolute disaster.
First, you're falling into the "get it out the door, we'll test it afterward" trap. Second, users will initially love it, and cause it to scale into failure, then abandon it and think IT are a bunch of idiots who can't program their way out of a paper bag.
...
IT is always too slow for everybody--but guess who has to take the blame when that hastily prototyped project scales into immobility and there's no budget to fix it?
I haven't said don't test it or throw it out the door. The decision to move something out before it is complete doesn't mean that the parts that are complete don't work or aren't tested. They're working, but not necessarily adding all the functionality. Note that I said that management has to buy in and either invest more in what they want or throw it away.
The past is the past, and continuing to cling to the idea that we just get done and move on, letting the work limp on isn't acceptable. That's the message that you want to bring to management and have users bring up as well.
May 24, 2011 at 8:38 am
mpalecek (5/24/2011)
I have to agree with roger.plowman. I am in a small company with an equally small staff.Projects routinely get started with a good plan and scope. After a short period of time the decision is made to just "get it out", with or without half of the requested features (usually reporting or administrative maintenance). Once it is out and working (no matter how well or not) we move on to the next greatest thing. We then spend to much time fixing/training/reparing data/etc.
That's not what I advocated. Go back and read my piece. Management has to invest in those projects that they want to grow and expand.
May 24, 2011 at 8:39 am
dduensing (5/24/2011)
...Agility without focus is fairly useless. Apps that are released to the world without a support plan, or a way to formally pipe the feedback in (and out) of the entire environment will not succeed over time.
Well said, Mr. dduensing!
Viewing 15 posts - 1 through 15 (of 52 total)
You must be logged in to reply to this topic. Login to reply