Heather McLean

Successful software projects require participation and commitment from both the stakeholders and the development team. All too often, business owners like to brainstorm a list of requirements, which is typically an unprioritized jumble of “must-haves” and “nice-to-haves” with no direction, then throw those over the wall to the IT department to implement in a vacuum. Without ongoing feedback to determine priorities and success, any team dealing with this situation is bound to fail. Sadly, most teams accept this state without argument, since that’s “just how things are” in the IT world.

True success requires an ongoing conversation between business and IT at the very least. In an ideal scenario, we can break down the traditional barriers between business and IT that have been erected in most organizations and quash the “us versus them” attitude. This typically means having a full-time product owner on the team who can provide direction and timely decisions regarding the product. It’s actually quite disheartening to see how many teams try to plow through a project without this crucial guidance. Is it any wonder that the customers are often disappointed with the end result?

What demoralizes the team even more at this point is that they are often blamed for not fulfilling or understanding the requirements they were given, and the stakeholders are seen as inculpable for the failure since they are certain that they provided all that was needed. This is simply not true; no matter how good your requirements, design documents, and project plans are, nothing is a substitute for ongoing, active participation with the people who are actually delivering the software.

I believe that most of this stems from the misguided notion of running IT as a business—in other words, an internal vendor completely separate from the rest of the organization. This furthers the disconnect between the stakeholders and the product team and reinforces the artificial barriers I mentioned earlier. Also, the notion of “chargebacks” pushes the stakeholders to treat IT as they would an external vendor: with little trust and without direct participation. To fix this, IT must be integrated with the rest of the business in such a way as to be part of the team rather than a separate entity unto itself. Likewise, they must be given a healthy budget to do both maintenance and growth, just as if they were any other division of the company, rather than relying on chargebacks to fuel projects.

I was recently re-reading Martin Fowler’s article The New Methodology when I came across a passage that stuck with me:

One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren’t so important, only the roles are important. That way if you plan a project it doesn’t matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.

But this raises a key question: are the people involved in software development replaceable parts? One of the key features of agile methods is that they reject this assumption.

One of my biggest pet peeves is when managers and planners refer to people as “resources.” I get this visual of a bunch of managers sitting around a table and trading little chits that represent people until everyone is happy with what they have, but all the chits are the same… just commodities to be pushed around from project to project.

When you treat people as interchangeable cogs in a machine, you miss several important factors about your team members:

• People are not equivalent pieces. I refer you of course to the ever-popular book The Mythical Man-Month by Frederick Brooks. If I have estimated¹ that two people can do the work in six months, increasing that to four people does not mean that we will get it done in three months. Team members all have differing levels of expertise and productivity, differing skills and motivations; you must know how to leverage these individual talents rather than lumping them together as a whole.
• People bring the greatest benefits and the biggest hindrances to the project. When you reduce them to a column on a spreadsheet, you are naïvely discounting their individual personalities and quirks. People can have breakthroughs that cut development time in half. They can also have a family emergency and lose you a week of production.²
• People are perceptive. They know when they’re being treated as faceless automatons rather than real human beings, and they will resent you for it. Don’t ever believe that your team members aren’t keenly aware of how you talk about them behind closed doors.
• People have preferences and motivations. Assigning people to tasks that they may be good at but hate is counter-intuitive. Yes, Bob may be a database whiz, but if he hates the reporting engine, assigning him to fixing the reports isn’t going to be the best utilization. Assign people to tasks that they enjoy, even if it’s not their strong suit; they’ll be more productive and learn a broader range of skills. Conversely, don’t let people pigeon hole themselves—ask them to branch out every once in a while and leave their comfort zones.
• People have lives beyond work. Don’t plan for people to have 100% attendance. Don’t even plan for them to work 40 hours per week. As I mentioned above, people are perceptive, and if they feel you are treating their personal lives as secondary to work, they will resent you for it, and morale and productivity will plummet.

Just wanted to point out a new addition to my blogroll: Viva la Scrumvolucion!!

This is the brand new blog of a great colleague of mine, Harry Long, one of the best Scrum Masters and Project Managers I’ve ever worked with. The blog is presented in both Spanish and English, so any of you out there that prefer Spanish as a primary language will be pleased to see agile discussion in your native tongue.

“Waste”—it’s an ominous word by itself, and in the world of Lean principles, it’s the one thing you’re striving to eliminate. Waste can be defined as that which adds no value to a project; i.e., those things that you are spending time and money doing, but they don’t move the project forward. Software projects are often full of waste, and in such an imprecise discipline, it can be difficult to identify the sources of waste. In fact, a lot of times we end up running in circles, attempting to clean up the symptoms rather than the causes.

In my experience, the one largest source of waste that can be eliminated or reduced to add immediate benefit to a project is rework¹. Rework falls into two major categories:

• Technical debt
• Defects

Read the rest of this entry »

Dave Rooney made an insightful post today regarding what happens in an agile team under pressure. Essentially they revert to their training, or to make it more simple, they revert to whatever their naturally formed programming habits are.

How does [an emergency] apply to software development? Well, consider the poor overworked software developer. They’ve had this bloody Scrum process thrust upon them meaning they have to deliver more, deliver it faster … Near the end of the sprint, this poor developer is running out of time and still has work to complete – they are facing an emergency! So what do they do? They revert to their original training.

What was that training? … They hacked something together that met the requirements for the assignment, and could afford to make it throwaway. Automated tests? BAH!! Simplest thing that could possibly work? … In the end, the attitude is to get something – anything – done in order to get the marks.

This was espoused in a previous workplace of mine as the concept of “get ‘er done.” What upper management was trying to address was an apparent lack of progress and too much time wasted on best practices. What this generated was an urgency of get as much done as fast as possible, and the result is catastrophic. People burn out, product quality takes a nose dive, and in the end, you’re in a worse place than when you started. “Get ‘er done” is almost as ineffective as “get nothing done,” simply because in the end the result you get is so poor that you don’t want it anyways.

This is such a flawed mentality to begin with that it’s difficult to address it; you pretty much have to change the attitude from the top down. Management must be understanding of the time it takes to produce quality over quantity, while developers must be willing to eliminate wasteful activities (that they may not agree are wasteful), and the Product Owners and Scrum Masters must assist the teams with committing to a reasonable amount of workload. This is partially a training issue and partially a culture issue. Training can be used to instruct change, but the participants must be willing to enact change.

Our previous set of status meetings failed to be productive. They lasted at least an hour every day, often more than that. They were unfocused, and often crossed so many topics that no one really remembered what happened after they left the room. Eventually, they just kind of petered out… no one really wanted to attend them anymore, as they were obviously unproductive. The period that followed was almost as bad–no daily status, but at least people had more time to do actual work. Tasks were slipping through the cracks and overall communication declined.

So I was happy to step in with an alternative solution: a Scrum-like daily status meeting. I don’t make people stand-up, and we’re time-boxed to 30 minutes instead of 15, but otherwise the principles are the same. At each meeting the attendees are required to come prepared to answer the usual triumvirate of questions:

• What did you accomplish yesterday?
• What are your goals for today?
• What issues are affecting your ability to meet those goals?

I’m pleased to say that even after only one week, the system has proven effective. People don’t mind attending since it’s short and focused. We stick to the agenda above; we’re not quite used to the format yet, so some side discussions occur in the middle of the meeting, but we’re getting better. Now everyone knows what everyone else is doing, and communication is improving. We’re catching issues much faster since the team is aware of what is going on before it happens.

I won’t claim daily status is a panacea, but it’s working for us with remarkable results.

Shameless plug for the new Fort Worth chapter of the APLN. It will be 6:30 – 8:30 p.m. on April 16, 2009. The speaker will be Ash Tengshe from Capital One Auto Finanace. Attendance is free. If you’d like more details, please contact Charles Seaman at fortworthapln@gmail.com.

A while back, Mike Cohn posted a concise explanation of how story points relate to hours. It’s a common phenomenon; folks who are used to traditional project management really want those points to equate directly into, “how long will this take?” The important thing to remember is that story points are a measure of capacity and effort, not time. The next thing to remember, and this really messes with teams new to agile methodologies, is that story points are mostly meaningless until you have accumulated historical data. Without some data on trends, a story point really is a guess; what does 1 point mean versus 8 points when this is your very first iteration? You have to go on gut feelings, and there will be resistance to that kind of “guesstimation”—which is pretty sad when you realize that guessing hours is not much better than guessing points.

At least with the points, you’re admitting that it’s an estimate. Hours tend to lull people into a false sense of security, assuring them that this is the timetable, and if you deviate from the established time line, then it’s the implementers’ faults, not the estimators’. Which brings me to another important part: story points are estimated by the team, not by a single project manager dictating from on high. This puts the onus on the team to estimate better with each sprint (which they will, given the freedom to do so), instead of being forced into a death march to meet arbitrary time limits.

Estimating story points is an ongoing learning experience. You start with none and build from there; once you’ve had three or four iterations under your belt, you’ll notice the team getting more accurate. All one point stories will start to look similar and take similar amounts of time, and once you have that in your arsenal, estimating with the story points both generates a realistic timeline and gives your team some breathing room.

So I’ve gotten really used to the idea of thinking in terms of individual stories/tasks when I work, and I like the visual cue of a task board. I haven’t been able to convince everyone that this is the best idea yet, so I’m leading by example. Here’s a shot of my “personal task board” that I have in my workspace.

Personal Taskboard

You can see several columns from right to left: NR (not ready/undefined), Rdy (ready to implement), WiP (work currently in progress), and Done. The tasks are written on individual sticky notes with a description, the ID number from our defect tracking system (if any), and the product release it is assigned to (if any). They’re assorted roughly in priority order with higher priority items towards the top of the board.

I wanted to take a minute to pass on a very insightful article by Tobias Mayer:

Oppression, Revolution and the Future of Scrum

I won’t add any commentary this time, just go read it for yourself.

As an aside, I realize that this is a pretty weak post in light of my long stretches of silence. My current project has me pretty busy, but hopefully I will have some more discussions on agile and whatnot in the near future.