IT Type People...Agile Development

Was the Agile process designed by a bunch of extroverts who were annoyed by all the quiet people working away efficiently in the office? We recently started this, and as a very introverted person, the daily standup meetings, end of sprint reviews, backlog grooming, demos, and other various meetings are driving me nuts.

Our team is still working in our own workspaces right now, and I'm not sure I can survive without going nuts when they shuffle the office around so we are all working in one big open area together. It took me 8.5 years to get an "office" at this place, and I'm about to lose it.

Any strategies for dealing with this?

Just a rant from a (former) QA guy who's getting way too tired of hearing other people's voices when I'm trying to get my work done.

I'm generally convinced that IT has been over complicated for IT sake. More and more its being infiltrated by college grads who studied a lot of business and not a lot of actual technology. So rather than admit they don't know what the hell is going on they find ways to "improve" it.

Most of my work is done in implementing ITIL methodologies and while I think the concepts are pretty good they could be summed up in a simple white paper instead of the 6 volumes of nonsense they currently comprise.

When I first started studying ITIL I realized it was just what good IT people had been doing all along someone just decided to document it and sell it. Many things in IT are that way now.

I keep rattling around in my head writing a book called Simplif-IT about getting back to the basics of IT and removing the unnecessary complexity, the problem is it would be about 10 pages and no one would take it seriously. If you remove the people from IT who aren't actually hands on responsible for producing, implementing or maintaining most IT departments would be cut by 1/2 to 2/3s

Agile computing was developed by companies who don't like to pay teams of seasoned professional engineers to do a thorough, well planned job the first time or some book-writing whore who speaks at trade shows.

It allows a sales driven company to change requirements in the middle of a production release at the whims of the customer so the sales team can say "Great, we can do that" right up until launch and then scramble everyone for nights and weekends to demonstrate their "agility". This is mostly ok for the E36 M3ty kinds of software that most businesses live and breathe on because for the most part they are all simple, straightforward things no matter how many times they try to convince you they are tough problems.

You will see Agile wherever people need a cool buzzword to keep a bunch of 20-somethings working themselves to death for ever-elusive "options" and free coffee/lunch but you don't see a lot of it in surgical robotics or things that produce tangible goods except where VC money has made a bad marriage.

I berkeleying hate this business.

JThw8 wrote: If you remove the people from IT who aren't actually hands on responsible for producing, implementing or maintaining most IT departments would be cut by 1/2 to 2/3s

Uh oh, I just switched from QA to being a business analyst. I might be one of those redundant people

Agile's biggest benefit is you figure out quickly if your work is adding benefit to the business. If it's not, you've blown a month of time as opposed to a year (or more). And in IT, time represents a lot of money.

Agile shouldn't hurt your ability to do heads-down work though, because the idea is that you have manageable chunks of work that can be completed in the next day. If it can't due to distractions, then there's something wrong in how they've implemented it. A lot of people claim that they're using "Agile", but many bastardize it to the point where it doesn't work well.

Noise canceling headphones should help when you move to an open space We went from a high-walled cube/office farm to an open environment a few years ago, and I didn't mind the change. I'm an extrovert, though, so that could be part of it. At the end of the day, though, everyone has tasks to get done by the next day and they're held accountable for them, so that should minimize the unnecessary socializing.

eastsidemav wrote:

JThw8 wrote: If you remove the people from IT who aren't actually hands on responsible for producing, implementing or maintaining most IT departments would be cut by 1/2 to 2/3s

Uh oh, I just switched from QA to being a business analyst. I might be one of those redundant people

A good business analyst is invaluable to me as a software developer (what I do when I'm not being a redundant ITIL process engineer) A business analyst produces a requirements document, so you do produce. Sure the software developer could meet with the customer and produce his own requirements document, but I'll be the first to admit we start to think code and functions in our head and don't really hear what the client wants.

BAs are really important because they bridge the communication gap between the business and IT. With the advent of outsourcing, that skill has become even more critical, so there will always be a market for a good Business Analyst.

There are things I like a lot about agile process. In particular, the emphasis on iteration is hugely important. Spending six months or a year on a site design then rolling it all out one day, for example, is stupid and wasteful.

But yeah, there's an awful lot about it that seems like process for process' sake.

We've been using agile for a couple of years now, and there are things I like about it and things I don't.

Likes
- When the product owner changes his mind 57 different times, you've only wasted a small amount of time on it. That is, you haven't worked for 6 months (or whatever) on something only to find out that it won't work for the customer's needs.
- It gives developers small manageable goals that can be accomplished within a few days.

Dislikes
- It seems to sometimes make features at the front-and-center of things, sometimes at the expense of good engineering. This is especially true if the clunky thing kinda works, and changing things to be better requires a bit of effort.
- The product owner calling the shots can overlook the legitimate needs of non-customers, eg support, IT, etc.
- A strict adherence sometimes doesn't make sense, boxing you in pretty badly.
- Customers will ask for 5000 different features that maybe 1 person will use it once, ever. You really need a good product owner to separate the wheat from the chaff.

I'd love to work on a project to overhaul some of the mainstay tables on our database to improve speed and data quality, but finding management support to actually spend time on it is difficult.

Sounds a lot like Six Sigma management.

scardeal hits on a good point I forgot about: agile (in my experience at least) is really, really bad at dealing with technical debt. No matter how bad something may be, no matter how much fixing it would improve things in general, it's incredibly hard to get any traction to fix it so long as it kinda sorta more or less works.

JThw8 wrote: I'm generally convinced that IT has been over complicated for IT sake. More and more its being infiltrated by college grads who studied a lot of business and not a lot of actual technology. So rather than admit they don't know what the hell is going on they find ways to "improve" it. Most of my work is done in implementing ITIL methodologies and while I think the concepts are pretty good they could be summed up in a simple white paper instead of the 6 volumes of nonsense they currently comprise. When I first started studying ITIL I realized it was just what good IT people had been doing all along someone just decided to document it and sell it. Many things in IT are that way now. I keep rattling around in my head writing a book called Simplif-IT about getting back to the basics of IT and removing the unnecessary complexity, the problem is it would be about 10 pages and no one would take it seriously. If you remove the people from IT who aren't actually hands on responsible for producing, implementing or maintaining most IT departments would be cut by 1/2 to 2/3s

QFT . . .

Don't get me started about mgmt ending a backlog meeting with:

Crazy Mgmt Person said: As long as we follow the process and meet the SLA, we will do fine . . .

You know it's the bad process(es), meeting SLAs by all costs and poor workmanship that got us to this point. For every 2 hours spent on "resolution", we spent 10hrs of administrative work doing the same stuff over and over, rather than fixing it correctly the first time.

Giant Purple Snorklewacker wrote: Agile computing was developed by companies who don't like to pay teams of seasoned professional engineers to do a thorough, well planned job the first time or some book-writing whore who speaks at trade shows.

I actually disagree with this part - the "thorough, well-planned job" part in software is notoriously hard to accomplish in the more waterfall-type developments unless you spend a massive amount of time beforehand speccing out everything into very small detail and then never deviate from it. You can do that if you're building a Mars Rover, but for commercial software where you tend to deal with vague specs and everything having to be done yesterday, it's simply not working very well. The longer your product release cycle tends to be, the worse this gets.

While I'm neither an agile guru nor did I get the religion, the emphasis on doing a little less and doing it sooner in a well-defined fashion can at least improve the planning process. Plus, the focus on having essentially releaseable software at pretty much any point in time during the development cycle helps guard against the "we've got 9 out of 10 features done but we can't release what we have because feature 10 isn't done and will take another six months to implement" type problems that tend to lead to death march type situations.

I'm a "part-time" manager (in other words, I also tend to code) for a development team of 20 and we're moving to a more agile process with shorter release cycles specifically to avoid the above scenario, which has bitten us several times recently. The important part about Agile is that you a) pick the parts that make sense for you and b) also make sure that you don't end up just picking the pretend Agile parts so you end up with a not-so-Agile-but-buzzword-compliant waterfall.

Tim Baxter wrote: agile (in my experience at least) is really, really bad at dealing with technical debt. No matter how bad something may be, no matter how much fixing it would improve things in general, it's incredibly hard to get any traction to fix it so long as it kinda sorta more or less works.

That is because Agile always seems to be implemented by shortsighted, target fixated management. There is nothing wrong with short cycles and feature driven efforts when appropriate... but that is the sticky bit. When a company takes on a methodology rather than it organically being applied because it makes sense... you get a bag of awful. Imagine engineering a car by implementing the user interface and filling in all the sub-systems to support them as they are needed. That is the sort of E36 M3 you get when you force inappropriate methodology on an engineering team. You get an infrastructure and maintenance nightmare that guys like me get paid to fix after the fact when those fake SLA numbers someone made up during a sales meeting turn out to be wrong and you can't finish your nightly batch window in 200hrs because the underlying duct tape and bailing wire is so poorly implemented.

So... for my sake by all means encourage it's widespread use everywhere for everything! It pays for my race car.

eastsidemav wrote: Was the Agile process designed by a bunch of extroverts who were annoyed by all the quiet people working away efficiently in the office? We recently started this, and as a very introverted person, the daily standup meetings, end of sprint reviews, backlog grooming, demos, and other various meetings are driving me nuts.

TBH, you should have potentially more but much shorter meetings, with the important ones for you as a developer being the daily standup, end of sprint reviews and the estimation/planning poker sessions. The estimation doesn't work very well without the end of sprint review (no feedback cycle). The backlog management shouldn't really be your concern (that should be done by your team lead and the product owners) and the demos are once every sprint so that shouldn't take too much time either.

Top tip - use egg timers for the standup and the estimation meeting so they don't turn into "who talks longest" meetings.

eastsidemav wrote: Our team is still working in our own workspaces right now, and I'm not sure I can survive without going nuts when they shuffle the office around so we are all working in one big open area together. It took me 8.5 years to get an "office" at this place, and I'm about to lose it.

That's not necessarily got much to do with Agile IMHO. We do agile-ish and have our own separat offices. We can all walk and it doesn't take much to go see someone else on the team.

The short cycles make some sense to me, but like some of you said, streamlining/improving existing code seems like it goes by the wayside.

Meetingwise, I actually only meet officially with my boss (product owner) every two weeks, which has been working fine, but we have one or two team members who like to talk a lot, and seem to like lots of exposition, and also need lots of detail, and they tend to dominate all the non-standup meetings, and some of the standups. And as the BA, I'm the guy they come to outside of meetings. Sad thing is we've been acquired by someone recently (which is why we went Agile), so we are all getting up to speed on products at the same time. Most of the time, if I have any answers, its because I just went and played around in the software a few hours before they came to me with questions.

Put (or suggest to) those talkers on a timer.

I just did that along with sticking to a published agenda(2-3 days before the meeting) for Six Sigma project team . . . It works wonders.

I think it is customers and project owners that are bad at dealing with technical debt more than an agile process. Part of every agile project should be regularly scheduling refactoring sprints to deal with the messy code or hard to work with parts, or painful deploys or whatever. The hard part is getting your customer to see reason. Where I am, our customers would always agree that refactoring makes sense and dealing with technical debt is important, but they would never prioritize it. We dealt with it, after a lot of negotiating, by agreeing to do a quarterly all-hands 2 week refactor sprint. Of course, we're only agile-ish, not full blown Scrum or XP or anything, so we don't have a real ideology to stick to.

The meetings aren't too bad either. 10 min teleconference every morning and a "are we on target for the next release" every 2 or 3 weeks weeks. Agendas and time limits really help. The meeting without agendas always go off the rails.

monknomo wrote: I think it is customers and project owners that are bad at dealing with technical debt more than an agile process. Part of every agile project should be regularly scheduling refactoring sprints to deal with the messy code or hard to work with parts, or painful deploys or whatever.

This. Agile vs other methodology really isn't a panacea, you're not suddenly going to address technical debt with Agile if you haven't before. Make sure to plan for it and it should happen.

I thought IT was a pronoun.