How agile are you?
-
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 asshole 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?
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.
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.
-
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 :)
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
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.
I wasn't really talking about the agile process, more your own level of agility regarding specs :) Judging from your hair splitting I'm guessing you like everything clear and worked out up front ;)
nightsoul94 wrote:
cowboy coding with no regard to thinking things out, wasting effort or repeating work
Exactly my current situation. There's two things I can do: bitch about how nothing is clear and we're all wasting effort or trying to figure out what needs to be done and make the best of it. I'm going for the latter, with the side note that I actually like working that way as talking to people and figuring out specs is a welcome change from programming :)
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
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 asshole 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?
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.
In over 18 years with the same company, I've never worked from a written specification...the closest thing being a UI sketched on scrap paper. :laugh: When I was new, there may have been more details, but generally my boss would simply describe what a new screen should do...just get it done. Things haven't changed much except now we might discuss what a new application/module should do...the details are left up to me. The phrase here has always been "We're making this stuff up!". Our business model may be atypical in that our software is provided to clients through annual contracts only. We are expected to know more than the customers/end users about their operations current and future needs.
"Go forth into the source" - Neal Morse
-
I wasn't really talking about the agile process, more your own level of agility regarding specs :) Judging from your hair splitting I'm guessing you like everything clear and worked out up front ;)
nightsoul94 wrote:
cowboy coding with no regard to thinking things out, wasting effort or repeating work
Exactly my current situation. There's two things I can do: bitch about how nothing is clear and we're all wasting effort or trying to figure out what needs to be done and make the best of it. I'm going for the latter, with the side note that I actually like working that way as talking to people and figuring out specs is a welcome change from programming :)
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
It is interesting, I am actually okay either way. I usually tend to do cowboy coding if it is a smaller or a personal project but if it is slightly larger or if it is a work project I think having more details makes for a more successful project. As software developers, we are used to having things change and shift and not really be locked down, but our customers tend not to be really comfortable with that, especially depending on the industry. I find most customers need a firm set of dates when things will be available, what they will cost and the level of effort things will take. You can't really give them that without having a significant amount of detail.
Quote:
Exactly my current situation. There's two things I can do: bitch about how nothing is clear and we're all wasting effort or trying to figure out what needs to be done and make the best of it. I'm going for the latter, with the side note that I actually like working that way as talking to people and figuring out specs is a welcome change from programming
This is pretty much my thinking, for the most part, on not having things spelled out. I am pretty able to go with whatever is going on, but I really hate wasting my time and effort even though I get paid either way.
-
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
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)
"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 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 asshole 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?
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.
-
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.
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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
-
That's not really the programmers job to figure out :)
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
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.
A "waterfall" project that is "chunked" small enough, becomes a series of "agile" projects ... It's just a question of being able to prioritize. (Just looked at a RFP from a muni govt with a "diagram" of their "plan" ... there should be a critical path; but it looks like a super nova ... Pass.)
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
In over 18 years with the same company, I've never worked from a written specification...the closest thing being a UI sketched on scrap paper. :laugh: When I was new, there may have been more details, but generally my boss would simply describe what a new screen should do...just get it done. Things haven't changed much except now we might discuss what a new application/module should do...the details are left up to me. The phrase here has always been "We're making this stuff up!". Our business model may be atypical in that our software is provided to clients through annual contracts only. We are expected to know more than the customers/end users about their operations current and future needs.
"Go forth into the source" - Neal Morse
