Over the years, I have worked for several companies where software development was at the core of their product offerings. As a Software Support Engineer, I’ve worked closely with the development team, and witnessed project management first hand. Some of the teams were small, only a few individuals with one level of management. These teams tended to work well, even without using any formal project management ideology. These teams were more like families than co-workers. Their relationships extended beyond the office walls, and none were afraid to speak their mind. Each was willing to speak up with what they had to offer, and ready to take on the tasks assigned to them. The methodology of this smaller team was “whatever it takes to get the job done,” and the company prospered. There was a limit to this cooperation, however, and it had to do with size. As the company grew, so did the projects, and the naturally scattered free-for-all methodology that had been so successful in the past, began to create bottlenecks in development velocity.
This leads me to a particular example that outlines the tragedy of cowboy-development, when it doesn’t turn out the results expected. A pair of brilliant developers were assigned the task of converting a Windows based application to a web based application using the latest ASP.NET architecture in the spirit of creating a platform independent contact management product. They were given their parameters and sent off to complete the project on their own. The project manager at the time was the CEO himself, and he thought he was clear on what he expected from the project. The developers also thought he was clear on what was expected. But at the end of several months worth of development, it became apparent that those expectations had not been communicated as clearly as they could have been.
So what happened here? The developers weren’t lazy. They worked very hard, for hundreds of hours to produce the product they presented. The developers weren’t stupid. On the contrary, they were very competent, and came up with novel solutions to the problems they encountered. The problem was that they were working on the wrong problems, for the wrong product. What was worse, since the architecture of the desired product was so different, the product had to be scrapped, and the project ultimately cancelled. This created tension from top-level management, and lowered morale for the developers involved. They felt they had done an excellent job, and were excited to show off the product that they had completed, only to be dismissed angrily and have their jobs hang over their heads. No balloon sags more when deflated than the one that was at first stretched to its limits with air.
The question shouldn’t be who was to blame, but how better project management could have prevented this catastrophe? An Agile development approach, such as Scrum, would have broken the project up into smaller tasks, and defined each feature accordingly with the appropriate prioritization. Certainly, for a small team such as this, several hats would have to be worn, but the Product Owner, the CEO in this case, would have been forced to clearly define each feature and rate its importance, and a tool, such as a product backlog, would have been present to remind each developer what tasks needed to be completed, and would have provided the CEO with a quick view on the progress of each feature. Dividing the features into week-long sprints with weekly presentations would have allowed the CEO to catch where the developers were going astray, and correct their understanding of the expected features. Much like walking a 100 miles 10 degrees off course will put you 18 miles away from your destination, even a few degrees of misunderstanding can lead to a tremendous gap in the completed product. Correcting these early can make or break a big project.
There are plenty of “I”s in TEAM?
One of the best parts of Agile Development, especially SCRUM, is that each individual brings something to the table, rather than simply being divvied out tasks and given a deadline. When an individual chooses the task they are going to perform, whether because they’ve done it and it’s easy for them, or they’ve never done it and they are embracing a new challenge (and in this way the process self-corrects for different personality types), they have chosen their task and they immediately take responsibility for it. This is important because people tend to work better when they have taken responsibility for something. Those who take responsibility for a task tend to feel more satisfied when a task is complete, and take more pride in their work. An assigned task on the other hand, can be perceived as a task best done quickly and kicked out of the “to do” pile. Assigned tasks are those that we have to do, not that we want to do.
At a higher level, by having the team self-organize, each member feels that much more responsible for the project at hand, and can feel that they are creating value for their teammates by doing their part to complete the project successfully. They will take more pride in their work, because they don’t want to be the one who generated an error that caused the project to suffer.
The role of Scrum Master emphasizes the importance of the Development Team. By listening to their needs and being in their corner to get the tools and resources needed for them to be successful, the Scrum Master shows that she is in their corner and that they don’t have to stress over problems that are outside their control. The project succeeds when the Development Team delivers, and so there shouldn’t be anything that gets in the way of the Development Team doing its job.
I can see how this system can apply to more than just software development, including any activity that involves small teams. Agile itself, has very little to do with software, and more to do with getting people to take responsibility and an active role in any given project. It allows people to create value, and experience the fulfillment of not only bringing a product to fruition, but also helping others do the same. By disrupting the typical leadership paradigm so central to common business mentality, it puts each individual in charge of themselves, rather than just a cog in some grand leader’s plan. As far as Scrum is applied, it also breaks up the project into tenable timeboxes that provide more frequent success points, rather than a long road on which to trudge.
This actually reminds me of the psychology behind gambling. Winning releases endorphins that encourage the behavior that led to this success, and, oddly enough, we are more apt to repeat the behavior to get back that endorphin high if we only win 25% of the time (which is probably why I don’t gamble because I never win). Even if several sprints end on a low note, as long as there are occasional successes, the team will remain motivated. If the project is handled as a whole, there is little motivation other than a far off goal, and if the project fails, morale suffers. So, breaking up the wins and losses provides better morale even if about 75% of the sprints don’t end up successful!
Meetings, meetings, and more meetings.
As I moved into a larger company, I discovered a strong level of animosity between the software engineers and technicians, and management. This company was an extreme case, chock full of managers. And when managers can’t find anything to do to stay busy, they create meetings to suck up their time and make themselves seem productive. At this company, there were meetings, and then there were meetings about scheduling other meetings, and nobody was safe. If there was even an inkling that someone might need to be asked a question at a meeting about something, that person was instantly scheduled to become part of the meeting. The meeting might take an hour, and the developer might never say a word, but it was crucial that they attend. This turned meetings into resource black-holes, where large percentages of the company’s developers were in meetings more than they were developing. These meetings often accomplished nothing, and clearly displayed the weaknesses in the management structure of the company, but, since the manager’s were the interface between the development teams and the people who cared how these resources were being used, the managers didn’t often complain about how they were handling themselves, and very few took responsibility for the actual progress of any projects. Those that did soon resigned out of frustration. Needless to say, this company doesn’t exist anymore.
So what went wrong here? Isn’t it important for management to know what is going on? Yes, of course it is, but somebody has to manage the meetings. Meetings should provide the framework for a project, occurring when needed, and timeboxed to prevent any overrun and member complacency. Meetings should benefit the Development Team as much as the managers and should involve direct input from each participant. Meetings where managers just talk and talk about teamwork and production ad nauseum are simply lectures on inanity and will stifle the brain of any thinking human being. Team members should look forward to meetings because they get to share what they have done, what they are going to do and get information critical to their ability to get that work done. If the Development Team doesn’t think a meeting is necessary to meet their goals, then that meeting probably shouldn’t happen. There is no worse waste of time than gathering twenty people onto a conference bridge, do introductions, ask if there is anything to cover, and then dismiss the meeting when there is nothing to be said. This will likely take 20 minutes out of each person’s day, which is almost 7 hours of lost production! If meetings are happening in this way, then someone isn’t planning the meetings very well.