Inspired by SharonDee's comment (and JoeP's replies) in the What's Up With You? thread, here is a thread for discussion of Agile Methodologies.
The company I work for makes software to support businesses that are employing Agile methods, thus one of the requirements of employment is that all new employees must earn ScrumMaster certification. To that end I just finished two days of Scrum training, so the theory is pretty fresh in my mind.
Ironically, we aren't really using Scrum at work. Sure we have small, mostly self-organized dev teams that work in sprints, do daily stand-ups, bi-weekly retrospectives and sprint reviews, and a few other things. However the closest thing we have to a Scrum Master is the "team lead" (a developer) on each of the dev teams, and the closest thing we have to Product Owners are what we call Product Managers who aren't officially part of the dev teams.
We're doing Continuous Integration and eyeballing Continuous Deployment, but we have a ways to go before we get there. I'm the "DevOps guy", so it's essentially my responsibility to coordinate design of and help build the infrastructure to support that goal. As such I drift in and out of all the dev team's different meetings as well as attending daily standups with the IT team. Even at a small company like this one, the Us v. Them between dev and IT is fairly pervasive.
Anyway I could go on and on, but I'm more interested in other's (surely more extensive) experiences with Agile methodologies, so please share.
Hm. Can't help you. Don't know Agile. Where I work, the amount of content gets multiplied by 3 and dumped on the developers 3 weeks behind schedule, if they're lucky.
__________________
The flash of light you saw in the sky was not a UFO. Swamp gas from a weather balloon was trapped in a thermal pocket and reflected the light from Venus.
-- Official Bunny Hero
I find it amazing how IT people can take the simplest ideas and formalize them into something that has little to no relation to the original idea. Especially when it comes to software development methodologies. First there was the flow chart, and top-down-structured programming. That turned into all the iterations of Structured Analysis. Then came objects which morphed into RUP, now there is agile which somehow has morphed into Scrum and Kanban. Kanban actually being a very loose interpretation of a Japanese manufacturing engineering methodology. And Scrum actually based on a WWII method of planning.
There really isn't much to being Agile, and thus for IT people, it is almost impossible for them to do it.
Inspired by SharonDee's comment (and JoeP's replies) in the What's Up With You? thread, here is a thread for discussion of Agile Methodologies.
The company I work for makes software to support businesses that are employing Agile methods, thus one of the requirements of employment is that all new employees must earn ScrumMaster certification. To that end I just finished two days of Scrum training, so the theory is pretty fresh in my mind.
Do you do user stories?
As a member of FF, I want to have an active thread on agile methodologies so that interested members of FF can learn useful stuff
I don't dev so I'm not directly involved in agile development, but I'm keen on agile principles applied to the process and service management stuff that I am involved in.
One of the challenges I see the dev teams in our organisation facing (but not really understanding) is connecting the big picture to the deliverables of a 2-week sprint. We continually fall into traps of prioritising a backlog to maximise the number of things a given team can deliver ... and end up with the product team they deliver to achieving nothing (or worse, delivering a live product to paying customers that can't be maintained or supported) because key dependencies weren't understood at the backlog grooming stage. It should be so simple to manage a set of requirement dependencies ... but it isn't.
However, the waterfall style "solution" of fully understanding your market and your business and your architecture and your solution before starting to develop, let alone build the IT infrastructure, is worse - because you deliver the right thing 18 months too late and everything has changed.
Having been a Certified ScrumMaster for 15 minutes, I can attest that such issues as you describe typically result from having a weak Product Owner. As the one closest to the stakeholders it is her/his responsibility to ensure that the business requirements are understood and well-defined in the product backlog.
What I frequently see is the sequestration of the developers from the actual users. So unless they are capable of distance mind reading, from the getgo if they get it right it's by pure accident. And then they eventually end up at a later stage going through the standard code/fix death march that is typical of many end stage projects.
The original version of this was created over 50 years ago, and it is just as applicable today as it was when it was first printed.
When I'm first told about a project I'm to work on (usually very sketchy information from the sales team) I always ask if I can talk to the customer. I'm frequently prevented from doing that: 'Oh no, you can't ask them about that - they think we've already been working on it for the last month."
Most customers don't know what they want anyhow - you usually have to implement some imagined solution first so that they can then tell you, 'Yes we want it exactly like that except for...' and then go on to list several things that mean a complete rewrite is in order.
Perhaps it's for the best - you can always code the second or third solution more cleanly and faster, based on all the mistakes you made implementing the first one.
For many kinds of apps it may be a detriment to speak directly with customers. Especially first of a kind apps. However, all I do is contracting and that usually means CRUD. The pitfalls of CRUD are not the actual CRUD implementation, it is all the niggling business details that you can only get right by talking directly to the users to see what they are actually doing. And if you want the users to love the software you've got to not only get the details right, but you've got to save them time and make it easy for them to do their jobs correctly and seamlessly. You can only achieve this by direct contact with end users and by watching what they do and asking a whole lot of questions.
However, the waterfall style "solution" of fully understanding your market and your business and your architecture and your solution before starting to develop, let alone build the IT infrastructure, is worse - because you deliver the right thing 18 months too late and everything has changed.
Exactly! This current pre-Agile project is over 5 years old now--I know because that's how long the consultants have been here--and we're no closer to Go Live than we were three years ago. We have some pretty complex business requirements for such a small shop and planning things out, working on them, showing users what they'll (someday) get has had to compete with supporting (and enhancing) existing legacy code while we're at it.
At one point we had to rip out and rewrite whole sections of code because one of the user analysts came up with another bright idea--which ever unhelpful PR thought would be great--that completely changed how we pay our affiliates. So brakes were put on while we changed direction and pushed completion dates out further.
So waterfall is the suck and I'm already inclined to like Agile, at least the way we're doing it.
Under this method--as our CIO explained it, anyway--when a situation like that comes up again we simply show the user what will have to be put on the chopping block to grant their new wish. "Great, we'll do this new thing but that means you won't get previous Wonderful Widget when you wanted it. You choose which is most important."
Now see, we told them that under the waterfall method but they waved it away. Will that not happen under Agile now that they can see with their own eyes what that does to their original "gotta have"? I doubt it because we had something come up during Sprint #1 that absolutely must be done because it's a third party requirement. No one saw it coming and now we have to make room for it.
Dunno; I'm still too new at this. Just started the second week of the first sprint and I find myself doing more user support--which was allotted to me, only not so much--than the project work I had hoped to get done.
Several months ago I took over the project of a "Scrum" team. As I understand it they read the books, got trained up by a Scrum Master Trainer. Followed all the forms, got the cards, did the board with the sticky postits, had the daily meeting, tracked the burn rate, did the white boards and on and on and on. They had four developers, two of which were "team leads". They had a Scrum Master, involved owners, and several million dollars over two years.
They produced a total piece of crap that I completely replaced in 4 months. Their software was soooo bad that it would not run for more than 15 mins. It hung constantly, threw exceptions like they were going out of style and produced erroneous data. The interface looked like a ransom note and the code itself was six layers all passing the same data. They implemented a Service Architecture with many thousands of lines of completely unnecessary code. And did the stupidest things with data that I've only seen topped one other time in my entire career.
I on the other hand produced just enough documentation so that I could code to requirements (which I gathered myself), create a test plan, generate automated tests, produced daily builds that were constantly reviewed. Used model based code generation, thin interface layers, MVC, declarative coding and pushed as much processing into the database layer that I could muster.
It's been running in production now for 8 months and not one issue has been reported. The users love it.
That is agile.
Quote:
ag·ile
ˈajəl/Submit
adjective
1.
able to move quickly and easily.
"Ruth was as agile as a monkey"
synonyms: nimble, lithe, supple, limber, acrobatic, fleet-footed, light-footed, light on one's feet; More
antonyms: clumsy, stiff, slow, dull
able to think and understand quickly.
"his vague manner concealed an agile mind"
It might give you nothing. But at least it might give you part of a complete list of regression tests. You know, when they change one minor thing somewhere and everything else (which "should not be affected") breaks.
It might give you nothing. But at least it might give you part of a complete list of regression tests. You know, when they change one minor thing somewhere and everything else (which "should not be affected") breaks.
It could also (most likely) result in an overly redundant set of tests.
The thing I was supposed to have done by today won't be done. The user who originally asked for it probably won't even care that I didn't get it done because she found a workaround. But because it was in my sprint I worked on it.
There is failure on two fronts (aside from her ignored "never mind"):
The previously unused feature in a tool I'm otherwise familiar with didn't perform as advertised.
My team leader tells me that tasks I had completed in the last sprint weren't really complete and explained to me why. Long story short, I missed the big picture because I was focusing on the picayune.
And that's what I've learned: Agile is great for helping you focus on tasks but lousy if you're more than a code-cranker-outer. I feel like I've been wearing blinders for the past month.
Now if you'll excuse me, I'm off to brush up my resume.
A very long time ago this business consultant told me about a management method he called Navigation. It was simple. If you want to improve your odds of getting where you want to go you need to do three things:
1) figure out where you are.
2) figure out where you want to go.
3) plot a course from where you are to where you want to go.
All of the major project management techniques are just variations on this basic idea.
When you loose sight of the basics you get lost or worse yet get sidetracked on things that are not your goal. This is the fundamental problem with Scrum, RUP, Waterfall, XP, etc. Sticking to the basics is agile. The rest is decoration.
Today we're having a "Retrospective on First 2 Sprints" meeting, where we'll give our opinions on what's worked and what hasn't. How the reality matches up to what we expected going in.
Doing Agile
posts on the subject now ...
Linear Mode
