Hello World,

So are any of you agile? I'm currently working in an Agile Software Development environment and wanted to see if anyone else out there is doing this too? In the past, I have only used the Waterfall methodology, which is requirements first, develop, and any changes to the deliverable are considered change orders. Agile basically attempts to incorporate late additions by increasing collaboration with coders, project managers, and the customers. So far it's a lot of meetings and a lot of doing whatever the customers asks. Are there any fans of this development methodology out there?

http://www.youtube.com/watch?v=gDDO3ob-4ZY

3/3/2011 5:34:32 PM

Depends a lot on the industry, I work in Pharma and things have to be way more laid out a lot more than I imagine something more consumer oriented would be.

That said you have to force customers to make and hold to decisions, nothing will hurt a project faster than having a customer come up with something else or a change they want every five seconds and once you start doing it they won't stop. Then you're getting calls on your personal number at 5:30 in the morning from a different time zone.

3/3/2011 5:43:03 PM

We use agile with scrums, sprints, etc...

Some projects we are more strict about than others.

3/3/2011 7:53:25 PM

i hate agile and think it mostly leads to a ton of half-baked, non-standards compliant, shit. waterfall doesn't have to be slow. im all for releasing functionality in tiers.

3/3/2011 7:57:51 PM

We are agile, if not chaotic we are a new team in a well run development organization with a manager who's background is in research prototyping. We do NOT have as good of a processes as I'd like to see but we are moving towards a agile dev plan.

3/3/2011 8:04:32 PM

I've worked in both environments, and am by far, a fan of waterfall. I just hate diverting away from requirements, meeting with the customer months down the road, and finding out what you have developed isn't what they wanted. Only to have to go back and cover your ass in order to bake a half cooked loaf of bread with pretty sprinkles on it.

3/3/2011 8:10:52 PM

^ you and I obviously have a very strong preference for proper documentation because of our backgrounds


that video the OP posted isn't biased at all


http://www.youtube.com/watch?v=l1wKO3rID9g




[Edited on March 3, 2011 at 8:33 PM. Reason : it depends on the project. i don't think agile is always the answer.]

3/3/2011 8:27:18 PM

Our teams do agile...

I am not a huge fan, but I do appreciate the increase in collaboration. The whole time logging, sprint planning, scrum, backlog grooming, retrospective, etc gets old quick though.

3/3/2011 8:33:45 PM

^^ aha, yeah. I've just seen shit go down the tubes quick.
Hell, your customer wants a good product. I want to give my customers what they ask for. I would much rather integrate my customer in the process along the way...
No excuses. No bullshit. No lies.

3/3/2011 8:37:32 PM

For real. People act like Agile is the brand new hot shit because it involves COLLABORATION.



Integrate all the teams and collaborate from the start and you won't run into half the issues that teams do.


I mean, I'd much rather go talk to a dude up front and be like "yo, does this work? do you think it will make sense?" than to work in a fucking vacuum making decisions based off of assumptions and then have to deal with bitchy-ass change requests.

3/3/2011 8:42:53 PM

we use agile. i much prefer waterfall. i can't deal with all the meetings. nothing gets done. ugh.

3/3/2011 8:53:45 PM

we tell people we do agile but we are closer to waterfall than we like to admit i think

3/3/2011 10:04:15 PM

how many devs are working on each of these projects?

For instance we're more agile than waterfall, but there's only a handful of people. I can't imagine being agile with 10+; you'd never get work done

3/3/2011 11:30:45 PM

i'm a big fan of agile. it definitely doesn't work best in some industries, i can see pharma and engineering being poor matchups. you also have to have an appropriate team. if you have folks who just want to sit in their office and write their code, it's not gonna work. i've worked with the same team (4 devs, 1 PM/scrummaster) for 4 different companies and we work very well together so we've had a lot of success

one company we worked for, they had spent the previous 3 months coming up with a requirements document, and came up with a 20 something page document of mostly excel mockups. after 1 sprint we pretty much ditched it and just did our thing. after 1 more sprint we had a working, demoable prototype that the C-levels could play around with and by the end of the next sprint they had our team training the other two dev teams on how to do agile. When they released the product, they actually named it Agile (ok this part is actually SUPER lame of them trying to attach the brand of their financial advising platform to a development methodology concept but it does show the impact that a highly-performant team can have)

Quote :

"we use agile. i much prefer waterfall. i can't deal with all the meetings. nothing gets done. ugh"

what are you doing in meetings? unless you're a project manager meeting with domain experts and other stakeholders, i don't see why you're in meetings. We have a daily scrum meeting at 9:00 am that lasts 15-20 minutes, a retrospective/planning session every two weeks that lasts about 4 hours and 95% of the rest of the time I'm at my desk. If I need to get clarification on a feature, I turn around in my chair and ask the project manager and he finds out. Either that or I walk down the hall and ask the person myself.

at home, for personal projects, I go back and forth between traditional iteration-based development and kanban-based systems. i really like http://agilezen.com/

[Edited on March 4, 2011 at 12:15 AM. Reason : .]

3/4/2011 12:04:43 AM

We call our scrum a stand-up. Team of 5 devs and 1 PM.

3/4/2011 12:08:24 AM

Our entire product group (Team Foundation Server) moved to a fully Agile development AND planning process for the current product cycle.

Very common misconception being tossed around in here that Agile Software Development inherently means you are also doing Agile planning, envisioning and requirements management.

You can do Agile Development with non-Agile requirements, waterfall or otherwise. Also, Agile development != half-baked shitty software. Agile development WITHOUT a planning and management process does usually end up with half baked shitty software.

I can speak from the experiences I've had in interviewing (and in reports from my researcher and team members) from over 40 companies across the world who are in various points of transitioning to Agile and practicing Agile development and management. And in addition from my own experiences in a large organization (200+ people) with VERY strict formal requirements moving to a fully Agile lifecycle. These are some insights that, with a little luck, I may be talking about at several conferences this year

- It's absolutely, 100% the future of software development AND requirement management. You'd be amazed how quickly the industry is moving to iterative development practices (Agile SCRUM is just one, there are many, many other alternatives).

- If you perceive there being higher overhead in your day to day work with Agile vs. Waterfall, it's overwhelmingly likely that you aren't really using good Agile practices. It's VERY easy to twist Agile into some really crazy and unhealthy practices and processes, and it can be really difficult to transition at first (especially for former managers, leads and analysts).

- The actual velocity over a release cycle for healthy Agile teams (whether new, hybrid or fully agile) is always measurably higher (at least, in every single customer we've ever talked to). Note the "healthy" term there, because that's critically important.

- It's VERY hard for companies to adopt Agile Development and then integrate with traditional requirements processes. And, it's even more difficult to adapt to Agile management tactics because it totally redefines job roles, titles and responsibilities. This is still a very young area and lots of people are trying different approaches to bridge this gap.

- Agile is about collaboration, but not just between developers and management. It's also about the collaboration of stakeholders, customers and test in the iterative lifecycle.

3/4/2011 8:34:25 AM

In my situation, our customers are government agencies. What we have discovered as a group, minus management, is that our projects have compounded dependencies on the customer. The challenge in reaching "doneness" on a deliverable, when your customer is non-responsive, almost defeats the entire purpose of the collaboration in the first place. I understand that Agile's benefits completely depend upon the industry that you work in, and in my case, it seems like when the customer feedback is imperative to the iteration process, the philosophy of agile becomes obsolete.

We have also discovered, minus management, that our company has many cross-dependencies, not involving the customer. This makes our "sizing" of stories very difficult to predict. In turn, developers are padding their time to compensate for the uncertainty, while management encourages us to "fail forward" with our projections, in order to determine our "highest velocity." Perhaps the company is simply too small in size to accommodate this methodology to see it's advantages.

I have my concerns with this methodology within my industry. While I can see how this would be very effective in many industries, it seems that to truly be agile everyone must collaborate in order for this to be a success, and not just those within the company. Perhaps we are experiencing a poor implementation of Agile, and it is not the fault of the process, rather the way it was demonstrated to us. Just like any method, it has pros and cons, which must be weighed against the way the company does business, and with whom.

3/4/2011 11:05:48 AM

add to my topics

3/4/2011 12:04:54 PM

can you elaborate on what you mean by "cross-dependencies, not involving the customer"

3/4/2011 1:03:02 PM

Sure, by that I mean cross-team dependencies. One developer may have created a custom interface for a customer several years ago. That customer has requested and paid for an enhancement on the interface, but the original developer that created it, is already booked full of other stories. So rather than re-invent the wheel, and re-design it from scratch, or over-commit the original developer by assigning it to him, a different developer takes on the task. However, because of the nature of our development standards, the different developer would still require collaboration with the original developer, which will skew both of their original sizing estimates resulting in an undesirable retrospective. Theoretically, in the long-term, this can spread thorough product knowledge around the company, making everyone more self-sufficient, and knowledgeable in regards to all of the deliverables we are obligated too. However, it is perceived as "padding" the stories by the Agile folk, when in reality, it indicates work force resource issues and a culture of historical cross-dependencies within the company. This isn't unique to our company, but it may be more inherent to smaller-sized companies.

For those of you that are Agile, how do you handle cross-team and customer dependencies within your swimming lanes? If you don't use swimming lanes, do you use Calendar views instead, and what are the pros and cons of the Calendar view method?

[Edited on March 4, 2011 at 1:59 PM. Reason : -]

3/4/2011 1:57:21 PM

^The inter-team dependency problem has been a pretty big one in our adoption too. For us at least, it's been a reflection of two different root causes though.

The first is that it has been difficult to transition from "feature" based teams into "agile" teams. Even now, our development teams are still loosely organized by major feature areas although there has been a slow movement toward being scenario or epic based, rather than functionality based.

This had been a big problem at first, because our planning and management process is based on narrative scenarios, or flows through the product. But the teams were being organized in the pre-Agile way of being based around a core piece of functionality. This led to a TON of inter-team dependencies that really started to stack up.

Changing the teams' focus to be more scenario/epic based reduced the dependencies a bit, and perhaps more successful has been that teams have been communicating and learning from one another (which leads to the second problem/solution).

The second root cause has been specialization of knowledge. We have longstanding domain experts in different areas of the product (which is exactly like what you've described). There has been a LOT of sharing, brown-bag learning sessions and communication between teams to learn each other's areas and code.

This has been going on now for the past 9 months or so and it is beginning to pay dividends now. Teams are no longer being blocked to wait on a knowledge expert, and the entire organization is now becoming MUCH more adaptable and flexible. The developers largely love it, because they get to learn new things and share with each other, and there's much more freedom for the teams to pick the stories they want without having to worry about resourcing issues.

/words.

Your customer dependency problem is, unfortunately one you can't do much about other than in contractual agreements before the project starts. If you have an unresponsive customer, then Agile becomes really difficult to do well.

I think your worries about "padding" of user stories is actually a totally appropriate and good thing. Estimating user stories gets better and more accurate as the unknowns go down (aka as the team learns their domain better). This doesn't happen in a couple of sprints, and it's a VERY well established practice for Agile teams to only estimate stories for 40-60% of the total time available in each sprint, to allow for spikes, bugs and learning as well as unexpected resource changes (sickness, vacation, holidays etc).

Other than the customer issue, it actually sounds you are on the right track and just going through the pretty normal growing pains of Agile. The important thing isn't to solve all of these problems immediately, but to come up with long term strategies to minimize and recognize them before they become a problem in the future. I think you've got the right long term outlook in terms of benefits

In terms of handling dependencies in swim lanes (aka task boards), there's a dozen different ways I've seen companies do it, I'd be happy to follow up with you via PM with more specifics that may be useful in your situation.

3/5/2011 12:12:19 PM

We do State Government Development method: each person works independently on their own randomly assigned projects, there is no communications between developers unless its about what was on TV last night or what they just saw on the internet, there are to be no design specs and clients can change their requirements hourly if they so desire, project management consists of "are you done yet?" responded to by "no, probably another month or two" until the client no longer needs the project or they call their buddy/cousin that's a state representative or in the governors office and we have to bang out the final bits of code in a week, project manager = time sheet collector and handler of gossip related tiffs... you get the picture.

3/5/2011 12:29:14 PM

^ sounds brilliant.

3/5/2011 2:13:02 PM

hahaha

3/5/2011 7:39:24 PM

^^^

lol

3/6/2011 12:47:53 PM

^4 sounds exactly like my group! We just kinda do our own thing and get shit done. Didn't realize there was a technical name for that methodology.

3/6/2011 6:06:52 PM

^5 ditto. everything you said is spot on, except I actually like my manager.

3/6/2011 6:40:18 PM

aha

3/6/2011 7:33:09 PM

lol, that's the way we worked before agile. The good old days.

3/7/2011 8:16:52 AM

I guess I'll post this here:

http://braindump.dk/tech/category/driven-development/

And add a few comments:

Waterfall - The project originally has a 1.5 year time estimate. The PMs go back and forth with the customer and the requirements documents finally get signed off after a little over a year. Suddenly there's only about 4 months to code the whole project (to meet that original deadline) so a massive team is thrown together. PMs threaten motivate team members because it's the coders fault that they are so far behind.

Get an impressive amount of work done with your team - almost getting back on schedule, then yank everyone off the project except for a skeleton crew when the project is about 80% complete. The remaining 20% of the project was all the really hard crap that no one wanted to get stuck with, so the remaining 20% takes the two people that are left on the project over a year to complete.

Agile - Lots of meetings, no documentation. You end up giving a lot of free work away because the customer will eventually game the system. There's no documentation, so they'll come back a year after a unit is completed and say things like "In that meeting last year I remember us saying that it would do this instead of that."

In the beginning the "I remembers" are reasonable and often truly represent what the customer asked for. At the very end of the project the "I remembers" are completely outrageous, where you know that the customer is fully aware that they never said anything close to what they are now asking for in those original meetings. It doesn't matter though, the customer is now trained to get free change requests. Don't bother looking for that e-mail that proves what was originally decided upon, it won't make a difference.

The customer often plays this game because they are not ready on their end, and they want to save face with their boss. They will come up with reasons why your stuff isn't up to par to shift blame to you. "Well the text on screen #509 says field reporting system instead of field reporting systems, so we can't even begin to think about system integration or customer QA. It's their fault we're behind."


[Edited on March 7, 2011 at 9:22 AM. Reason : -]

3/7/2011 9:17:42 AM

Quote :

"Agile - Lots of meetings, no documentation."

That's like saying

Driving - Lots of speeding tickets, no instructions.

Sure, if you just buy and car and drive the shit out of it, you're going to have all kinds of problems. Agile SCRUM isn't a "pick the practices from the barrel" strategy. You can't just ignore entire parts of the software development lifecycle and not expect consequences.

3/7/2011 10:11:25 AM

^I'm not saying that's what agile is, I'm just saying that's what my experience has been when people tried to put it into practice.

You're right, you can't just ignore parts of the software development life cycle, but those sorts of things will inevitably happen when people try to put it in practice and iron out a system that works. Again, not to say any development method wouldn't suck when people screw it up, just relating one of my experiences... and yeah, agile - now we don't have to document - was definitely one of them.

[Edited on March 7, 2011 at 10:36 AM. Reason : -]

3/7/2011 10:16:00 AM

Agile is the best and the most popular one, right?

5/3/2014 4:08:41 PM

waterfalls are pretty agile amirite

5/3/2014 9:03:51 PM

Agile Is Dead (Long Live Agility)

http://pragdave.me/blog/2014/03/04/time-to-kill-agile/

5/4/2014 10:21:33 PM

http://programming-motherfucker.com/

5/5/2014 1:57:02 PM

What the hell is that??

5/5/2014 2:20:38 PM

Agile in software development? Absolutely. Agile in the rest of the organization? Them bitches be crazy.

I've gotten the chance recently to run some talent acquisition projects for more than one company around the country where the entire organization has embraced Agile methodology from the top down, not just the development teams.

The development teams were all cross-functional and co-located, and those guys loved every aspect of Agile. And it made sense. Plus having the managers above you using the same methodology you do in your day-to-day makes some things easier.

But having everyone in the organization running their day through Agile methodology was a headache. Everything is not better through an Agile lens, and there was a lot of unnecessary work just because "Agile".

5/6/2014 6:19:56 AM

^It is, if the principles are embraced. I've many attempts at "Agile" at an organizational level. I've seen a few that work amazingly well when executive management actually operates with Agile/Lean principles.

Most organizations however just believe that by changing their review schedules to be every 3 weeks, that makes them Agile. Or that letting "customer feedback" drive decision making makes them Agile. Or that not making any decisions at all and constantly starting over is Agile.

Usually a combination of those three.

But I have seen it work, and when it does, it's pretty fucking glorious.

Unfortunately, a healthy Agile environment is easily corrupted by leadership with all too common personality defects: the Napoleon complexes, the micro-manager control freaks, the narcissists, the ego junkies, etc. It takes a management chain that actually believes in the process and trusts their subordinates to make good, informed decisions. Which is pretty rare to find it seems.

5/6/2014 10:13:35 AM

pure Agile could work for us, but the problem is nobody in our organization wants to adopt it. Our scrum masters have no discipline, and when a "stand-up" turns into an hour-long bitch fest about why the builds are broken or why some other feature team is blocking them, nothing gets done and most folks feel heavily burdened by the constant meetings.

We have PO's on our scrums but they are never present in stand-ups, and when they're there they offer nothing. and when a sprint comes to an end and we discuss what US's got done and discuss what we could demo, it turns out that shit never got accepted because there was no fucking acceptance criteria in the US. i would so much rather work for a start-up that did Agile properly if the process was actually followed than at my fortune 500 where adopting new things (like transitioning from clearcase -> git, for example) doesn't take years.

5/7/2014 11:13:50 PM

^see if you can make a case to bring in an outside trainer/consultant to teach Agile scrum to the team as a whole. They do intensive training for several days and usually follow the team for a day or two.

This made a huge difference for several teams I work and worked with, allowed the team to learn the difference between the intent of the principles and their misunderstandings

5/8/2014 11:58:36 AM

human factors > your bull shit development methods

5/8/2014 8:31:12 PM

hah, sounds like shoot just heard another buzzword and doesn't know what the hell it is

5/9/2014 12:28:57 AM

Been at 2 different (big) companies where teams tried to do scrum and it failed. Turned out to be a way for product managers to micromanage engineers without giving engineers any control of the product. So, the direct line between engineering and customers did not exist, which is the only thing that makes the tedious scrum artifacts worth it.

Also, if you actually have talented engineers, they'll figure out how to work efficiently. Any canonical development methodology is unnecessary.

[Edited on May 9, 2014 at 12:57 AM. Reason : .]

5/9/2014 12:36:19 AM

I think Agile is better simply because it is more adaptable and flexible than Waterfall is. That being said, I think a lot of companies overdo it on the collaboration.

5/9/2014 3:04:17 AM

^^ This is by far the most common failure mode I've seen too. Managers look at Agile scrum as a new way to break down work and manage risk, while getting even more granular oversight into team activity.

That's not scrum. What you were doing wasn't agile and wasn't scrum. And in every case I've seen, one or two days of an on-site trainer will donkey punch those managers into shape.

Managers in scrum basically do three activities: engage with customers, groom the backlog, and keep developers unblocked. They *may* be scrum master, though that's usually a bad idea at first. They may run sprint planning, though that's usually also a bad idea at first.

5/9/2014 1:45:24 PM

We've all done the training

5/9/2014 3:11:35 PM

Scrum was designed to be hard to implement so that they can make a lot of money selling training.

5/9/2014 4:20:44 PM

^no its not. The hard part is getting people to change their mindset and way of operating. Going through classroom/seminar training isn't the same thing as having a consultant on-site, in person helping to redirect the bad implementation.

Either that, or you got a really shitty trainer. There is a lot of variance in the quality of "certified scrummasters". I know the first team I worked with that went through the shift to Agile spent several months looking for the right trainer for them.

But it also helped that the senior leadership spent those months learning deeply about agile, to understand the value, principles and pitfalls themselves.

5/9/2014 10:57:51 PM

In my limited understanding of both..

There is a time and place for each, Waterfall style works best with clear requirements in a mature organization.

I.E. you don't need Agile processes when your work is related to building a airplane control system that will be used, virtually unchanged for 30 years. It's clear and defined, you don't want rapidly developing requirements because you have 0 room for error.

If your building a Web 2.0 site, or some product that must adapt to changing needs, it makes good sense, especially when your not a overly mature organization.

I think some of this focus on Agile stuff is driven by the web and the need to get the next biggest thing, agile enables that. Its great for when you want to add a new way to "Poke" people on Facebook and compete with other companies on a fast paced 6 moth cycle, where the next big "Feature" could make or break you.

It's not however what you want when your dealing with Operating Systems, Business Software, Flight Control Systems, or Power Plant control systems.

I sometimes feel that agile enables cloud software. Which will be a challenge for certain businesses. People working in Adobe CS don't want to find out that their UI has changed every 6 months. Nor do business software users want Microsoft 365 to "Improve" the experience by hiding buttons and re-arranging the UI while stripping colors out.

5/10/2014 1:24:45 AM