Page 3 of 3
Posted: Fri May 04, 2007 3:35 pm
by Jenk
My only experience of that was when I was still in support, in a very rigid process control situation, trying to work with developers who were agile and I can honestly say my groups performance was a lot worse than theirs. We were making promises we couldn't keep, whilst the developers were just not making those promises in the first place and so forth.
That's as far as the client facing part goes, and from the client meetings we (rarely) had, I can tell you they were much more satisified with the developers than they were of the entire (1,500 man) support group whom had cleary defined entry/contact points and all the other stuff.
As for the relationship between support and developers, we found ourselves adopting an agile approach, atleast as far as the developer<->support relationship went, without even realising it. We would receive a request over the phone or email, rush it along to the developers with a "When can this be done?" message, and the replies were always "Not sure, but we can provide updates [literal and actual] every 14days. Pass the customers details to us and we'll sort it." which left us and the client very satisfied.
I was only in that role for 6 months, so not a wealth of knowledge about it I'm afraid. I've kind of jumped from one to the other without much of the inbetween.
Posted: Fri May 04, 2007 3:53 pm
by RobertGonzalez
I'd certainly be willing to try it. Like I said, I come from a Toyota background, so the process of very appealing. I just think selling it to the company would be hard to do.
Posted: Fri May 04, 2007 7:48 pm
by Kieran Huggins
I'm at the point now where I pretty much refuse to use contracts and deliverable dates and all that. If the client isn't willing to work as a partner in an "agile" manner, I won't waste my time with them. Short iterations and constant feedback are the only way to fly.
To re-state what Ryan said (far more eloquently than I) in the video I posted: contracts promote an adversarial relationship between the developer and client. How many times have we had to pad our figures to cover our asses? The client is trying to do the same thing. Then feature creep makes the whole project an all-out battle and quality suffers as a result!
Well I for one refuse - that's just not the kind of work I'm interested in. I don't have a hard time finding work (and no-one talented should) so I insist on holding out for the right clients. It was tough to do at first, but does it ever pay off in the end!
Posted: Fri May 04, 2007 11:56 pm
by alex.barylski
I suppose we all have our own methods what matters most is your getter done.
Personally, I would never expect a client work with me in a "partnership". Thats like saying, open your wallet and perpetually dump money into my mine please. Of course, I explain, software development is an ongoing process (never ending - when it does the project dies), but I give timelines, I find it helps kick me in the butt when deadlines are nearing. I'm not disciplined enough maybe, to work with no set goals.
I break an application into atomic parts, which are easy to guesstimate. A sum of these breakdowns often yields a pretty accurate timeline. obviously I forget or miss things, and feature creep of course, but the gantt charts just keep changing, but still reflect an end goal, something tangible for the end user and all other parties involved.
Meh...what I do works fine for me, I can't see myself ever giving up deadlines, just streamlining my ability to approzimate and make more efficient use of my time - after all as developers efficiency is what were all about.
Cheers

Posted: Sat May 05, 2007 8:31 am
by Jenk
Hockey wrote:Personally, I would never expect a client work with me in a "partnership". Thats like saying, open your wallet and perpetually dump money into my mine please.
No, it's the complete opposite. It is saying "Come and sit with us, and watch how we work. We would also like you to do this, so we can ask you immediately, in real time, all those little questions and for examples so that we don't have to make assumptions, and will save you money because we won't need to come back in 6 months to fix/remove those assumptions."
Posted: Sat May 05, 2007 8:40 pm
by DrTom
I work for a company that writes account management software for several large banks and lending companies. Here's how we handle development.
On day 1, the core group of developers involved in a major new feature release or totally new product release will be brought into a room to meet with the business managers and go over expectations and what not. We'll find out the core functionality which inevitably will grow before release. We'll also find out a release date. This date is inflexible. There's too much planning involved on the part of our clients to go "We may have it this day, or maybe a month from then." It's just not a feasable answer to them. After this meeting techincal and requirement spec documents are drafted.
Usually within a week after the developers have had time to thorougly review spec documents there will be a meeting involving the developers, client, and business people involved in the contract. The developers and client will work together to hammer out the details of each feature as much as possible and possibly even suggest new features to hopefully avoid the creep later. Then together we'll set a few dates including dates for them to see test versions of the product and a release date. These dates are pretty inflexible.
Development starts.
Alpha date comes. Core developers hop on a plane and fly to the clients office and start to demo the product. Track any feedback they have on the product and come back to the office after a week or so.
More development
Beta date. Core developers on a plane again. More feedback. Lots of coding taking place as they watch to change interfaces and whatnot to whatever they want and also keep track of any missing features/reports/etc..
Live date. Same thing as beta only no new features thats for version 2.
It's not a truly agile method, but kind of a hybrid of both and makes sense for a company like ours where we have contracts with customers world wide and they'ren ot always available to sit at our desk and tell us what they think. I've worked at both traditional and agile shops and I feel that a hybrid similar to this allows me as a developer to be the most productive. I don't have a client breathing down my neck when I'm working on the base of the product, but when I'm finishing it up I have them there to help hammer out the final details. It works out pretty well for us.
Posted: Sat May 05, 2007 9:06 pm
by Jenk
DrTom wrote:
It's not a truly agile method
That's very far from being agile.
Posted: Sat May 05, 2007 11:59 pm
by Kieran Huggins
Don't get me wrong, when I say "work with the client" I don't advocate sitting them down beside me while I code - that's just ridiculous
What I mean is using prototyping and refactoring in short cycles and getting feedback from the client about how they use the app. Clients are often a wealth of wisdom and insight into how their apps should be built, you just have to learn how to communicate with them.
Likewise, sometimes you have to educate a client about how to give you appropriate feedback. I find a good starting point is to tell them to explain their problems/concerns to you
rather than to offer solutions.
@Tom: your method sounds to me to be a fairly adversarial one. Feature creep doesn't happen because clients are dumbasses who are trying to rip you off, it happens because they don't understand everything that's vital to the success of their application. Rather than just telling them "sorry, that will have to go on the whiteboard for version 2" you could instead tell them how long you think it will take to build in for the next iteration. Let them judge if it's important enough to do now, it really should be their decision. Besides, then they won't complain about the useless dev company that took forever to build the app that isn't really what they need anyway.
OK.. I have a feeling I'm just ranting here. I just want to minimize the opportunity for animosity on both sides, and agile development seems to work best for that in my experience. I make a point of never telling a client "no" - instead I try to tell them "how much" and if they have better options.
Posted: Sun May 06, 2007 6:48 am
by Jenk
Kieran Huggins wrote:Don't get me wrong, when I say "work with the client" I don't advocate sitting them down beside me while I code - that's just ridiculous

Why is it "just ridiculous"?
What better way is there to ensure you are making a product the client actually wants? What better way can you get feedback? What better way can there be to get input you need, when you need it?
Posted: Sun May 06, 2007 4:17 pm
by alex.barylski
It's silly because SME's seldomly have the time or budget to dedicate a staff member to sit and watch people program.
In fact, although I did sort of get that impression from the various Agile/XP books, etc I have read, that is another tactic I just don't agree with in my own experiences. Like team programming (although effective no dought) takes and SME's cannot justify that cost.
Expecting a client to sit beside me while I develop software, would be...not very effective.
1) Having someone distract me while in "code mode" would be annoying - I think you may have misinterpreted Agile a bit?
2) Most of my time writing code is spent, hammering out ideas, testing, retesting, refactoring. None of which is benefit to my client.
Agile, means (IMHO) incorporating a client as much as "practically" possible into the SDLC, as opposed to traditional:
1) Hammer out specs
2) Agree on specs
3) Any changes there after cost an arm and a leg
Being Agile lets your clients throw in their two cents each iteration (or more) and it's expected the developers are experienced enough to incorporate change easily - without starting from scratch.
The point is, when you suggest a client sits with you while you code:
1) Your an amazing developer and spend every minute writing tangible source - in which case, call me I have a job for you.
2) You have your client sit beside you 85% of the time in absolute bordem watching you tap endlessly on the keyboard.
I think 15 minute a day sit down sessions (at the most) are all that are required - just so both parties have an idea where the others are heading (small to medium projects with less than 10-15 developers on the team which is what I think Agile advocates KISS?)
Maybe I misinterpreted what it was you were saying though?
Cheers

Posted: Sun May 06, 2007 4:46 pm
by Jenk
Paired Programming, with a client is what we do. Not every developer, every second of the working day, but the "Application Owner" floats about the team most days of the working week.
We develop in Smalltalk, which is extremely rapid so there isn't many key tapping moments involved.
Yes, Agile (and more primarily in Scrum) heavily promotes KISS. This is why we are done with deadlines, so we focus on creating a working application rather than "something that works before 'x' date."
Posted: Sun May 06, 2007 5:00 pm
by alex.barylski
My only point is this: Design patterns, methodologies, etc are merely "suggestions" and should be applied accordingly, not followed with an iron fist.
What is good for the goose, is not always good for the gander.
SME's (If you can do do otherwise - by all means 'giver') in my experience will not allocate additional budgets to loan one of their own to a software development project. They usually expect you to come to them routinely and sit down and explain the phases and processes, etc.
IMHO it's the apitimy of Agile/XP. You don't get much simpler than that. Small teams, small projects = JIT deliverables.
I'm not sure I'd want large corporate contracts from what I'm hearing and reading. Perhaps there is more money to be made, but that is not my primary goal in business - it's to provide superior service, support and product. To me, thats Agile.
Cheers

Posted: Sun May 06, 2007 6:20 pm
by Jenk
Unspend's presentation shows the size of the clients they work with, and their working ethic is beyond what is described as Agile. You don't get much bigger than what is on their list. An application has irrelevance to scope of deployment other than what you need to make allowances for (connection pools etc. etc.) there's no comparison to say a factory line, where you will need more man and machine power to create larger numbers of said prodcut. With software you will only ever need to create, and maintain one tree per product (ignoring the baseline/maintanence branches for now.) However, Agile works very, very well for small clients, just as well as large, if not better - smaller numbers of staff equates to a closer knit community I guess.
Support is not development, so although you can be very much agile with support, it's a different cookie - but from the same jar. There is a link in size of project, to number of staff. Development not so. Todays choices of development platform, and more specifically, the vast dynanicism (real word?) and capabilities of those platforms and languages, make the need for fleets of developers (read: code cutters) obsolete, IMO, so development teams should rarely exceed 10 members. However, you can of course have multiple teams for the same project. Operating System developers of course have this structure, multiple teams for the various components of what will be the final product. Networking developers, GUI developers, etc. etc.
I am arguably very biased for Agile, but with good reason in my opinion. I was heavily, heavily, oriented for full process control. If I did not have a clear, defined and prioritised list of exactly what was needed, and by when, before I began work I would kick up a stink. I couldn't, nor did I want to grasp the concept of Agile - the crazy idea of just starting work without so much as a project plan had me scared. Now that I have tasted Agile/Scrum, I just can't get enough. If it were food I'd have been the glutton victim from Seven long ago. I never realised just how powerful, and more importantly
fun the practice of adapting rather than planning and controlling my work can be and is. It just makes so much sense now, before it was a "We must do this because it is how it works. We have to plan in advance." Now I look back and think "But why? Why can't we just do it so we enjoy it? Why can't I ask my client to be more involved [and avoid all those small assumptions]? Why must I stick to a deadline?" Everyone gets bored of monotony, especially developers in my experience, but with "full on" Agile/Scrum like I currently have, the only monotony I experience is the trip to commute to the office and home again, everyday poses new challenges and tasks, not always the most exciting, but new.
Also on the note of providing the complete package, i.e. support as well as the development, this is what Agile is all about. A Long lasting, trusting relationship with your client, creating and maintaining continuously evolving products that adapt to the clients needs, when the client needs them to.

Posted: Thu May 10, 2007 1:54 am
by alvinphp
Agile is a great idea, however the idea is far from new. It has been used within industry standard Unified Processes.
As for not needing a deadline, it is alright to have an end date and still be highly successful and keep the development team motivated. You do this through short releasable milestones, evolutionary prototyping, timeboxing. With this you do what is important first so if you hit the deadline you have the critical requirements done so the application could go live. It is then up to the business to decide if they want to extend the project to complete the lesser requirements.
The first time I saw a development group try to use Agile it failed miserably so Agile is not an instant win button. It can and does fail if not done correctly. This holds true for all SDLCs.