|
The software ideologies thread below got me thinking about the flexibility of some people and how well I work with them.
I just got out of a team who wouldn't want to start working on a user story until every little detail was crystal clear (but they still called it agile).
For example:
The story: As an admin I want to see the address of a user on the user overview page.
The questions: How do you want the address formatted? Where on the form do you want to see the address? Do you want address and house number in one field or in two separate fields? Do you want to see the address in that other page too?
That's a very short and simple story, but notice the amount of questions that HAD to be answered before they could put it in a sprint.
Personally, I'd put it in the sprint and I'd ask the story owner about the first three questions. That last question is out of scope, this is about the user overview page, not the other one too.
My current job is the exact opposite.
They want an entire application, possibly with about 10 third party tools, but they don't even know which ones yet (this has been going on for about a year).
And now I can start building... Figuring out the requirements as I go (which is probably about 50% of the job).
For Juun Software, my own business, I got a job "here's a fairly complicated Excel spreadsheet, we want that in an application. Good luck."
Alright, I'll build something, advice about certain subjects, and rebuild it if it's not what the customer wants after all.
Of course with everything clear up front you can make an estimate, you can build what is asked and you'll never have a dispute about if what you built is what they wanted.
With nothing clear it's pretty much impossible to estimate, things will take a lot more time, if your customer is an a**hole he'll give you a hard time for not building what he wanted or taking too long and without the right people these projects tend to fail miserably.
And then there's everything in between.
Personally, I like it when there's some work left for me to figure out. The more the better, like my current project.
Some people really can't deal with that uncertainty though (and when working with them I often find myself thinking "just start building already!").
What's your ideal situation?
|
|
|
|
|
Sander Rossel wrote: How do you want the address formatted?
It is often faster to simply add a setting for those than to go through the ladder and get opinions on how stuff should be formatted. "Just make it configurable" is a good answer to most of those questions, and a good way to teach them not to ask stuff they can answer themselves.
Sander Rossel wrote: Of course with everything clear up front you can make an estimate, you can build what is asked and you'll never have a dispute about if what you built is what they wanted.
Even if the specs are 100% clear, that hardly means that the estimate is correct. I wouldn't wait for the specs to be at 100%; even when old-fashionably waterfalling that's a bit too much (and yes, I still do).
As long as your customer realizes that changes will also mean that the estimates change, you don't need to pour your specs into concrete. Code is very mallable in that respect, cement isn't.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: It is often faster to simply add a setting for those
Only if something somewhere is already configurable 
On my current project everything is configurable, as it should be.
I'm not even halfway and it already paid itself back when the customer said "oh yeah, we were thinking we also want this and that" and I was like "you can add it yourself, it's all configurable" 
Eddy Vluggen wrote: Even if the specs are 100% clear, that hardly means that the estimate is correct.
It will be when you add the manager modifier of "developer's estimate x 2"
|
|
|
|
|
80/20 rule.
Deliver the bulk of the requirements, the must have, the basic functionality, and put the details, the 'nice to haves' till later. Dont let the second delay the first, thats the key for me.
And every plan can be changed, just make a start, make a decision and head in that direction. If it needs to change mid course, thats OK, at least progress is made.
Thats the way I design SW and run projects, and why I love the scientific method so much. Newtons laws arent perfect, but they are good enough to take man to the moon. For sat nav we need Einstains laws.
'Dont let lack of perfection hold you back' is my lesson from that! 
|
|
|
|
|
Munchies_Matt wrote: 'Dont let lack of perfection hold you back' is my lesson from that!
An ex-employer used to say "perfection is the enemy of good enough" 
|
|
|
|
|
Let me add that to my list of favourite quotes!
|
|
|
|
|
Good enough begins to make money. Perfection just keeps costing money. This is a fundamental that separates businessmen from programmers.
I'm pretty sure I would not like to live in a world in which I would never be offended.
I am absolutely certain I don't want to live in a world in which you would never be offended.
Freedom doesn't mean the absence of things you don't like.
Dave
|
|
|
|
|
Mind you, those dealing with problems and failures, such as lawyers and doctors, make even more money than those who do good, such is the human condition.
|
|
|
|
|
DRHuff wrote: This is a fundamental that separates businessmen from programmers.
Almost doesn't count*
Depends upon who decides it good enough, doesn't it!
Something about per-ordained third-rate quality that goes against my grain.
Possibly because, although I love getting my check, it's never been about the money. The work you do is your art. Do you want to be proud of what you did or proud of what you got away with?
* (yeah, I know, except in horseshoes)
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
The days are long gone when UI's would be actually storyboarded, though there are some great online tools -- I can't remember the one I used, but there's a plethora of them now. The idea being that all UI elements would be designed, the online storyboarding app that I used, you could click on controls that would actually do things, you could annotate the storyboard with questions, etc.
I found such tools really useful for discovering deficiencies in the UI and the UX. Really helpful to identify those things early.
To me, agile basically means "prototype." OK, there's a "process" part of Agile, but again, that's basically prototype iterations. At some point, the prototype ships, but the project never really started from a solid design.
So my ideal situation is where the UI, UX, data models, etc., are all designed before a single line of code is written. The design tool should then be able to generate UI, code, SQL, and models, leaving the programmer to deal with the real job of gluing it together, performance tweaks, testing, etc.
To me, Agile is just a BS game we play to compensate for the lack of planning but make it look like we know what we're doing. From my experience, anyone that actually has a functional Agile shop or defends Agile is actually doing good software development, and "Agile" is just the name they use because that's what the ignorant masses want to hear.
|
|
|
|
|
|
Marc Clifton wrote: To me, Agile is just a BS game we play to compensate for the lack of planning but make it look like we know what we're doing. From my experience, anyone that actually has a functional Agile shop or defends Agile is actually doing good software development, and "Agile" is just the name they use because that's what the ignorant masses want to hear.
The very idea that I practice "agile" development cracks me up, we have stand ups and the PM used to try and put things into "sprints" and I still keep churning out applications like I have for the last 30 years. The tools have changed but the methodology is basically reiterative waterfall.
I have seen 1 enterprise project that was done with the whole "agile" culture implemented and it worked, even when outsourced to India. I was astonished! Then I found out they used my prototype done in WPF that took me 3 months as the basis of their Java web solution. Took 10 guys 18 months to build. Ok so there was lots of stuff I did not need to implement (eg. security) 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Standups get to me. The idea of "let's punish everyone by making them stand so they won't talk too long" sounds like something from elementary school, not how professionals act.
Just tell the professionals to limit their talk time, take longer discussions offline after the meeting, and have the scrummaster ride herd on the little doggies who forget what professional behavior is.
I refuse to stand in our "stand ups", and when asked why, I merely stated that I am an adult and a professional, and standing up like that is for children.
Then the whole idea of carving out daily meeting time whether it is needed or not, just seems so bureaucratic to me. I call this an article with my views on Agile, but some may call it a rant.
[^]
|
|
|
|
|
I used the word "prototype" once many years ago, and my manager freaked.
I meant and still believe in "iterating" (from a "good" knowledge / design base).
(He assumed prototype meant a "throwaway" at some point).
Part of iterating is "demonstrating" that everyone is on the same page.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Sander Rossel wrote: How do you want the address formatted?
And the very first question is wrong. defining about the presentation before considering the data.
It only gets worse, "address and house number in separate fields." what? Now you know they are clueless (not all addresses follow this format).
I would stop them there and ask them one simple question: "when are the properly qualified people coming?" If they don;t know ask their boss because all they are doing is wasting your time with zero accomplishment to show for that.
There's not one iota of Agile in that, anybody who calls that so should find a new career asap.
Signature ready for installation. Please Reboot now.
|
|
|
|
|
I'm really not sure what you're going on about...
Sounds like a perfectly valid question (when considering that we only have Dutch addresses in our system and that's not going to change anytime soon).
Perhaps everybody considered the data, but you? 
|
|
|
|
|
Sander Rossel wrote: How agile are you?
Put it like this: if my username wasn't "OriginalGriff" it'd probably be "SessileGrog"
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: it'd probably be "SessileGrog"
That's a real Downer.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
In my experience, Agile works when
0. Customer know what s/he wants.
1. Product owner knows what cutsomer wants.
2. DEV knows how to change the Product owner to software.
3. QA tests what DEV delivers,
For any defects all teams Product, DEV and QA collaborate again.
4. Infinite loop 0-3 steps till the final product delivered.
It's really rare to find/build such team, due to skill, willingness, ability to pay more ...
Luckily I able to experience it since the customer is the owner of the Product, it's also participate in DEV and QA cycles.
How agile are you? I only work 30-40hr per week, but much effective with my teams.
In short Agile needs a team collaboration, from customer to product owner, DEV and QA. Otherwise you can't make it to be agile only because you have employees...
Logic will get you from A to B. Imagination will take you everywhere
- Albert Einstein.
|
|
|
|
|
If stakeholders understand how it works and are also agile I am willing to fill gaps o my own.
Of course I probably will miss something anyway, but I don't need to worry that someone will nag.
On the other hand if someone complains after sprint and stories were not specified well enough.
Then the only option is to push back next time.
|
|
|
|
|
Sander Rossel wrote: As an admin I want to see the address of a user on the user overview page.
You missed the zero'th question: Are you actually allowed to see that data under GDPR rules?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That's not really the programmers job to figure out
|
|
|
|
|
How about a "software engineer"?
You want to be treated like one?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I have the strong inclination to split some hairs here but I think it needs to be said. In your two scenarios you are talking about two very distinct things, neither of which have anything to do with AGILE. That happens to be the hair I am splitting. There is a highly important second word that the community has a nasty habit of leaving off when referring to "agile" and that it isn't "agile" it is "agile development". Like I said, a bit of hair splitting but important. Regardless of using agile, waterfall, or whatever; you have to have some basics. You have to have requirements (agile ends up using these to come up with the user stories, or a bunch of different names), waterfall uses this as requirements and etc. through other methodologies but they have to exist first.
Where this comes into your two scenarios is in the first, the questions that are being asked are being asked because the requirements are incomplete and unclear, in the second the requirements are not complete but this fact is being ignored. Agile is supposed to make it easier to develop and handle requirement changes but the community seems to accept, at least in my encounters, that agile is actually designed to allow us to not have all the requirements, and the ones we have not be complete, and we develop without them.
In practical experience what this leads to, at least in my experience, is the first method will ensure that the best application possible comes out in the alpha, beta, or whatever, with the minimal amount of time involved in basic things like layout and page views; the second method is going to result in a large amount of time spent in tedious things like altering a page layout a half an inch so one text box lines up with another, and repetitive views and things like this. I just wrapped a project, as an example, where a page had a registration form and nobody laid out the requirements and by the time we got close to the end, the one view, a simple registration form had been re-done seven or eight times with the irony of the me pulling up the original page and the final page and everybody realizing that the original and the final were exactly identical but we had redone it seven or eight times.
The first reminds me of someone understanding a real development process, be it agile or whatever, and the second being cowboy coding with no regard to thinking things out, wasting effort or repeating work.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
