I still remember the day I got the phone call from the recruiter. I had been working odd jobs, most of them not related to web development, and happened to have my resume listed online. The company had found my resume and wanted to consider me for a position. After getting through a fairly detailed interview process, they offered me a job as part of a brand-new team they were building. I was the first person hired for the project, quickly followed by several others. Within six months, I'd been promoted to supervisor and had a team of my own. We were the “golden child” of the department and got nearly everything we asked for. Things couldn't have been better!
At this point, I began seeing issues with the company's development process. As a supervisor, I essentially became a glorified switchboard operator. Because my team wasn’t allowed to talk to anyone outside the department, I began funneling information from other departments to my team members, coordinating meeting schedules, planning releases, and ensuring that the production environment was up and running without issues. I routinely had to work in the evening, and weekends became a guessing game to see if I could schedule anything other than getting the groceries. Over time, the expectations of my management team grew, and my team members also started being required to pull long nights and the occasional weekend. Try as I might, there was little I could do to shield them from the extra work and stress that had been a part of my life for a few years.
Then came the day when it all came crashing down. The vice president I reported through called me into his office and told me they were going to reorganize and that I was no longer employed by the company. Talk about a smack in the face! I'd been giving the company my all, causing problems in my marriage and friendships as a result, and I was no longer necessary?
Thankfully, the several years of experience I'd gained made me incredibly marketable in the area. I found another job in a surprisingly short period of time. This time, I am "only" a developer, a move that allows me to relax and not have nearly as much stress and responsibility as before. But the more I learned about my new employer, the more I realized that the supervisors here are not under nearly as much stress as I was at my previous job.
The developers are given the ability to speak up and be a part of the process. No matter how much experience you have (either in the field or in the company), your opinions and ideas are heard and considered. Each team member is seen as a necessary part of the puzzle and has the opportunity to make a difference. After the micromanagement from multiple levels of bureaucracy I'd experienced previously, this was an incredible bonus!
There is a process to allow the developers to give estimates about how long projects will take. Then, those estimates are taken into account when planning releases, so developers are not required to work more than the forty hours in a typical workweek. Because those are estimates, changes are expected, but they are communicated immediately once the developer gets into the work and has additional details. This process is very transparent and happens as necessary, instead of waiting until the end of the release cycle.
Not only is the environment more democratic, it also practices paired programming. At first, this was something that terrified me. I was used to a large cubical all to myself, and now I was working in an environment of tables, sharing a computer with another developer for forty hours a week. As a person who values his personal space, I now have roughly six people working in the space that my cubical used to occupy! However, the paired programming model has become something I fully believe in. Having another person looking at your code, constantly reviewing what you're creating, is a powerful motivator to be the best you can be. It also allows you to learn a lot in a very short period of time while watching the other half of your pair write code. Sure, there’s a little less space than I had before, but I also know my coworkers much better now, and I’ve only worked with them for a short time.
One of the issues I’d experienced in my previous job was a lack of communication with the business side. Issues encountered during development were major roadblocks that would throw off the entire process and bring the success of the release as a whole into question. It would take major meetings with lots of people to make sure that everyone understood what was going on, what the problem was, and what steps needed to be taken to develop a solution.
At my current company, there is a specific person identified on the business side who is involved throughout the process. This person is included in crafting the project definitions for each project throughout its lifecycle. She is available throughout the sprint for any questions or issues that arise, and she has direct contact with the developers if necessary to solve those issues. This eliminates the need for massive meetings, which were rarely productive, and ensures that the developers have the power to solve issues using all available resources instead of being forced to work through a rigid hierarchy and wait indeterminate amounts of time for an answer.
Another thing I have noticed in my new company is the level of communication between developers. As our ScrumMaster says, “If you have a question, just ask the room!” It’s taking time to get used to speaking up and asking a question, but it’s a valuable option.
At my old job, we were often asked to email (not even IM) so that you didn’t interrupt the person you were talking to unless the issue was critically important. At my new company, we’re encouraged to talk to each other. Conversations are a critical part of our process, and face-to-face talking is by far the preferred method of communication. This allows immediate resolution to issues, more open and transparent work throughout the team, and a level of collaboration that I’d only dreamed about before.
I now know that my first job used the waterfall development approach and my current job is using the agile development approach. While I was initially hesitant to make the switch, I gave it a chance, and I'm not looking back. Agile presents a framework that allows the development team to self-manage and self-organize, two things that become very powerful tools for success. In addition, deeper personal connections are formed, making your time at the office something you look forward to instead of dread. Each day at the office is an opportunity to learn something new, to try a different technique, and to move our project forward.
I’ve got plenty to learn, and every agile implementation is slightly different, but as someone who’s seen “both sides,” I would heartily recommend this approach to everyone who asks!
