Why I Fell in Love With Agile

March 25, 2009 By 2 Comments

I’ve been working at Integrum for nearly 5 months now. When I started, agile was a concept that I had read about, but never experienced in practice. I took bits and pieces of advice from books like Extreme Programming Explained and Practices of an Agile Developer but I had never really lived day-in day-out as a developer in an agile workplace. However, now that I’ve experienced the project boards, burn down charts, velocities and story workshops, I cannot imagine going back to the slam-your-head-against-the-wall waterfall approach from which I came.

What I Love

Project Boards – Nearly real-time visual feedback on the status of your project. Everyone on the team can assess your project at a glance and you can avoid long status meetings with middle management. Greatly increases accountability.

Stand-up Meetings – Quick, informative useful meetings that don’t waste people’s time. Social group pressure keeps people who like the sound of their own voice from talking for 30 minutes.

Daily Client Interaction – No need for ego-maniac project managers. Developers discuss issues with clients each day so that they can deliver the best software with the most value as quickly as possible. Challenges or roadblocks can be brought up almost immediately helping to prevent wasted time on either side of the equation.

User Stories – “Replacements for a conversation” as I always hear around the office. Replaces the need to confusing spec documents and misguided feature requests. These provide a way to ensure that neither the client’s money or developer’s time are being wasted.

Acceptance Criteria – It’s not easy getting quality acceptance criteria from your clients, but man is it worth it. Helps to make sure that what’s “done is done” and there are no disputes towards the end of the project about what is or is not completed.

Short Iterations – Allows the developer to focus on a set of the most important tasks for a short period of time. The client receives frequent demonstrations of the completed work and changes in course can be made very quickly. What was important 4 months ago during the original planning session might not be important this week.

Waterfall Development: DO NOT WANT!

Looking back on my last job where waterfall development was the norm, I can’t imagine how I got anything done. When I really think about it, I wonder how much software I wrote that was “right” the first time around.

Just as a quick list, here are some of the things I’ve grown to hate:

  • Project manager dominated client interaction
  • Long useless meetings
  • Finger pointing and blaming and lack of accountability
  • Waiting a few weeks to find out that your implementation is incorrect
  • No way to tell what was actually “done”
  • Wasteful spec documents

This Won’t Work For My Business

There are probably a lot of development shops that are humming along using long standing processes based on a waterfall model. A lot of people probably think that they don’t need to change because “if it ain’t broke, don’t fix it”. If you’re not doing agile your shit is broke!

A lot of managers probably think that this system won’t work with their employees. I can see this being the case if any of the following apply:

  • You don’t trust your employees
  • Your employees are morons (or you think they are)
  • You think you need to operate like the status quo
  • You can’t give up your control on the process
  • Your clients suck

Agile Works at Integrum

Derek Neighbors has taken the time to produce a couple of videos outlining how agile is put into action at Integrum:

Whatever the reason, agile works, like actually works, at Integrum. Is it the culture? The people? The atmosphere? The expectations? The clients? I can’t quite put my finger on it, but I can guarantee it’s not coincidental.

Filed Under: Ideas, Riffs Tagged With: , ,

It’s Really All About the People

February 28, 2009 By 1 Comment

Last week at Integrum, as part of our ongoing effort to be the best, we had a retrospective/company-wide expectation meeting. We discussed our current processes, and outlined some new things we wanted to do going forward that would help improve everything we do. Even though we talked a lot about project boards and velocities, when it comes down to it, it’s really all about the people.

How to Earn a Gold Card

When I was in elementary school they had an ongoing school-wide program where students could earn “Gold Cards” and be recognized in the monthly assemblies. To earn a Gold Card, one had to be doing something benefiting others, without being asked. It could be something as simple as going out of your way to pickup some trash.

To be sure, a lot of students went around doing very insignificant, but still beneficial, activities all day in hopes of being seen by a teacher. The real takeaway however was the idea that the best type of deed is done where no one is watching. This is a difficult concept for a 4th grader, but the life lesson is outstanding.

Focus on the People

We talk a lot at Integrum about our process, our engineering principles, our goals, plans and expectations. But for every project board, velocity graph, client stand-up and piece of acceptance criteria, there is an underlying foundation of high quality people working together to achieve a common goal. Finding trustworthy, forgiving, understanding, motivating, helpful, challenging and comforting people to work with removes so many of the problems that these project management tools aim to solve.

When people live their lives being accountable to themselves and those around them, when they strive to do what’s right, even when it’s hard, and when they go above and beyond without the expectation of being praised, they can achieve great things.

Filed Under: Ideas Tagged With: , , ,

Dead on Arrival Deadlines

May 23, 2008 By Leave a Comment

If you’ve done even a small amount of project management for a web development project you have probably been responsible for and have issued a number of deadlines. Deadlines make sense, they feel right, there’s just something about them that says “productivity”. You can make a deadline for some aspect of your project and it feels like you did something, you set a goal, you drew a line in the sand; I’m going to need to take a break after taking about it. Unfortunately, deadlines are as easy to ignore as they are to make, they are usually one directional in nature and they are a poor measure of productivity, accomplishment and satisfaction.

Purpose of Deadlines

Deadlines usually serve as a method in which to shift responsibility from one person to another. As a stakeholder in a project I can shift my responsibility of launching my project on such and such date to my hired development team. As a manager I can shift my responsibility of getting the project completed and delivered to the customer to my development team. As a developer I can find ways to shift my responsibility of completing the deadline back to the manager or client in the form of “I need…”. No one ever wants to own a deadline, they just want someone else to accept the responsibility for it’s failure and receive the accolades when it’s successful.

Responsibility Shift

During the deadline assignment process, do you find yourself using a lot of four letter words ? Every deadline is usually “easy” and “can’t” be that bad. You usually hear these type of phrases at the “responsibility shift” point in the deadline life cycle. When the project manager is shifting the responsibility to the developer they’ve got their rose colored glasses on and their attitude seems to be one of hope, relaxation, ponies, rainbows and lollipops.

  • Well that shouldn’t be too hard
  • There isn’t too much complexity here
  • I can’t imagine this is too difficult
  • That won’t take long

Not Really Deadline Deadlines

My favorite type of deadlines are the ones that nobody pays attention to from the get go. You’d think that everyone in a professional environment would be wise enough not to bother with making and pretending to adhere to deadlines that all parties agree are impossible to meet. However, this seems to be one of the favorite uses of deadlines, all going back to the feel good nature of saying you’ll get something done at a certain point in time.

Imagine this scenario:

Your client wants something done in a week that would normally take two weeks, you agree but charge them more money due to the “rush” nature of this particular job. Your development team warns that it is unlikely that you will be done on schedule, however you proceed anyway. Two days go by and now the client is relaxing their own requirements. They thought they were ready for the responsibility shift, but they were missing some content and didn’t quite have the final design in place. Now responsibility has shifted back to them and they’re forced to meet their own unrealistic deadline. Of course, they know this isn’t possible so they relax the deadline and get back to you a few days later. At this point you’re not taking the deadline seriously, so it gets pushed back a bit more.

Had a realistic deadline been put in place from the start, one that gave everyone time to get their ducks in a row, the project would have been completed in the same amount of time, the developers would not have been overworked, the client wouldn’t have had to scramble to get the content together and end product wouldn’t have been so rushed.

Improving Deadlines

  • Consult the people who are doing the work required to make the deadline attainable (usually the developers)
  • Make sure you’re not taking ownership of something you don’t have a good amount of control over
  • Don’t use the four letter words describe above
  • Speak up when you hear a deadline that’s probably going to fail
  • Fight the urge to appease people by agreeing to deadlines that can’t be met
Filed Under: Development, Riffs Tagged With: , ,