Tag: agile

Open Offices Aren’t Always the Solution

What’s with the latest craze in the office organization of the service industry? Are we really going back to huge, open spaces with no sense of privacy at all? With companies like Facebook, Google, and even smaller companies like Valve praising the open office concept, it sure seems like it will be here to stay for awhile. That’s unfortunate, because open offices suck!

The Concept

Look, I get it. Someone saw the cube farms and said, “Why are all these people locking themselves away? We need to be more collaborative! Our products are failing because no one is talking to each other. Tear down these walls!” Down came the walls. Soon enough the facility planners were shuffling desks together, removing all partitions, knocking down walls and replacing them with fishbowl style glass walls, and preaching Agile processes. All the while the seasoned veterans are running for the doors as quick as possible.

The Good

There really isn’t a whole lot that I like about open offices (as an introvert), so this might be a biased section. However, I will say that open offices do encourage you to talk to people near you that you normally wouldn’t. This can be a good thing in the sense that you get to know your coworkers. But when a project needs to be worked on diligently, the open office spaces seem to encourage people to just chit chat about random stuff all day. Joking, yelling, talking loudly, and throwing stuff around is just a little bit of what can be experienced in an open office. See, I wasn’t really a good candidate to praise whatever virtues open offices may have.

Is this my desk? Cool. Wait, why is the guy across from me turning on his radio. Oh wonderful, I guess I’ll learn to like Insane Clown Posse.

The Bad

The walls weren’t the only thing to fall. Efficiency, privacy, and and overall sense of quiet-time came crashing to a halt. Where you once had the opportunity to sit, relax, and think on a problem without much interruptions, you’re now constantly bombarded from all senses. Annoying coworkers throwing a beach ball around? Yea, it’s in your line of sight. People blasting music because it’s “collaborative?” Sorry, you just have to put up with LET THE BODIES HIT THE FLOOR until 5 PM. Deal with it. Forget about concentrating on anything useful when this kind of behavior is tolerated or even encouraged by the management.

All Things In Moderation

To be honest, I’m sure there are varying levels of the open office concept. Some offices have no partitions, low partitions, half partitions, or see-through partitions. Others may have only glass walls, some glass walls, or no walls. I’ve worked in the most extreme concept of open offices in which the entire office is one large space with no separation between desks and only glass walls between other rooms.

There were literally no opaque walls in my office at the time of working there.… Read more

Agile Development isn’t a Silver Bullet

Buzzwords are the worst. The absolute worst. They seem to be something that some higher up read about and decided to preach to his or her employees. Inevitably the buzzwords will end up on job requirements (even if the job has nothing to do with that buzzword) or talked about endlessly during job proposals and interviews. Honestly, it’s a huge red flag if someone repeats a certain methodology, process, or philosophy without justifying the context. “Agile” is just one such buzzword that seems to be really misunderstood and misapplied.

When Agile Becomes a Burden

What is this “Agile” thing? Supposedly its a software development methodology designed to react to a faster paced and rapidly changing form of software construction. Perhaps your requirements are in flux, or your customers don’t really know what they want until they see something in development, or you’re just really interested in that “scrum” word you keep hearing about on various tech blogs. Regardless, you really want in on that sweet, sweet Agile action.

You hire some scrum masters, software engineers (remote is OK), QA engineers, technical writers, and business analysts. You setup a scrum board. You preach the tales of development sprints, user stories, and research spikes. You do all the things that you learned during your 2-day Agile bootcamp in Silicon Valley. Oh man, you’re on a roll you think to yourself. There’s no way a project can fail if I know of all the problems in our daily standups!

Over time, some cracks start to appear in your process. Why are we revisiting a piece of code from three sprints ago? What do you mean you didn’t put in proper error handling and documentation? You had to meet your sprint deadline (which includes development + deployments + QA + code review + documentation + user acceptance). There’s no time for “clean code” and algorithms that “make sense.” Just get that stuff checked in and commit to your next sprint, damn it!

Maybe it’s a cultural thing. Maybe it isn’t the Agile process at fault here. Maybe you’re just misusing it.

Knowing Your Gaps

Agile is a process with many faces. There are a ton of variations, all or none of which may apply to whatever project you have on hand. The lesson here is that you shouldn’t mass apply any one Agile methodology to your project without careful consideration of what the project is, what the project’s goals are, and how the people on the project like to work. Take some time to analyze these facets and build a process around your projects, cultures, and environments.

Just because some other organization saw a billion percent increased revenue after adopting the most recent buzzwords doesn’t mean that the exact same process will yield the exact same results for you.

Look inward before you put that buzzword on your job requirements.… Read more