Project management

Using Agile, scaling back helps software projects in recession

“You are about to embark on a dynamic quality endeavor. It is time to throttle down on your already oversized and over-budget test and development teams.” That was the opening salvo of Michael Mah’s (QSM Associates) SQE Agile Development Practices Conference session, Rightsizing your project in a down economy.

Project teams are just too large, Mah said. Sure, the poor economy has prompted downsizing in this industry; but that could be a blessing in disguise. After all, there have been many years of impractical spending, mismatched teams and dysfunctional workplace goals in software projects.

For too long, Mah said, executives and managers have emphasized speed over quality, judging success by whether teams turn out code lines on time, rather than on delivering in a reasonable time frame quality code that’s free of obvious functional flaws. He’s seen promotions being given to project leaders who met deadlines without ensuring quality. The results? We are paying the ultimate price in lost jobs and market share, he said.

“Now that I have pointed out where the trouble began, let me now explain where the trouble continues,” said Mah. Today, he sees many companies using the recession as an excuse for adopting seriously questionable practices, like trying to cut steps to recovery by cutting down on employees. In the short term, this does free up some cash; but once a company has rebounded or is recovering, new team members will have to be hired. Of course, it takes precious time and money to train new employees and pay for newbie mistakes.

On the other end of the spectrum, there are the overly-cocky executives who have spent more wisely over the years, they see this time where other companies are cutting back and pinching pennies as time to throw money and software at problems. This rarely works, and usually sends these companies into the downward spiral.

In a time of recession, throwing enormous manpower and software at problems will rarely resolve issues. It is more appropriate and intelligent to scale back, says Mah.

To scale back, project leaders should build strong relationships with a small core group of commited employees. Research your service and tool providers more thoroughly, gather references and check them.

“How many of you have some fear about loosing your job?” Mah asked the audience, and nearly all of them held up their hands. “And how does that make you feel? Bad, right?” Company and project leaders are responsible for alleviating fear, not creating it. Fearful teams don’t work productively. Often fear is responded upon with aggression.

The most effective way in managing concerned workers in a recession is by showing “concerned optimism,” Mah said. Explain the situation, but encourage the team. Leaders’ optimism and relationship helps team members feel confident in their abilities and have more belief that they are capable of working on innovative projects. A motivated and innovation-welcoming team is critical to success and growth. Optimism makes for more tolerable working environments and more creative problem solving.

“I remember a good many times I would work through 70+ overtime work weeks; partly because work needed to be done, but also because there was always a chance that the company president would see me there,” said Mah. “On the occasions when he did, he would always compliment me with a thumbs up and a ‘good job.’ That was all the praise I needed.”

More coverage from Agile Development Practices:
Early adopters, Agile philanthropy key points in ADP keynote

Agile philanthropy, one man’s ambition for a brighter future

How software testers can get deliverables without nagging

How can software testers get development team members’ firm commitments for deliverables? That question came up while I recently hosted a panel on time management at a local software testing group meeting. As testers, we rely on a lot of people: developers for code; system administrators for environments; business managers for data and oracles and so on. A big part of testers’ day-to-day life can be spent waiting on getting what we need to start test execution.

“Sometimes I feel like I’m nagging other people to get things done,” said one tester in the audience. “Do you have any techniques to help get commitments out of people to help make this process less painful?”

Panel member Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, provided some ways to move from nagging and silence to empowerment.

“I think that all of us have the experience of nagging, and we all know that nagging does not work. It doesn’t work to be nagged; you don’t have any desire to do the task. In fact, if you’re nagged you’re less likely to do something. If somebody calls me three times in the course of a day and asks me to do a project, I’m not going to do it for them. Because I know they’re going to keep reminding me until the deadline comes up. They just created an expectation that I don’t have to remember any more. They’re now my human to-do list. So nagging is the worst thing you can do to get something done.”

Take away nagging, though and what persuasion option do you have?

“The opposite seems like silence,” said Slaughter. “Just hopping that it happens doesn’t really work either because you really haven’t communicated what it is you need. So, I think the most helpful strategy is to try to empower the person you’re work with. And to say, ‘Hey, if you can do this really great thing that I can’t do, that would be fantastic because then I can do my job, and make you look even better.’ So if you can find a way to empower them, they’re more likely to want to get the task done for you.”

Slaughter, wanted to be clear about the difference between empowering and enabling somebody, noting that:

“If you empower someone then you’re imbuing them with the authority and the responsibility to provide you with their work that you need to do your job. And that authority and responsibility translates into satisfaction, satisfaction translates into productivity, productivity translates into a sense of ‘I can know what I do.’ If you enable them, then what you’re doing is you’re allowing them to not complete their job. Empowering is more about ensuring they have tool and resources, ensuring they have information, ensuring you understand their challenges. Whereas enabling means I’m you actually say, ‘You know what, I’m going to come and do some work for you, or come and make your life easier directly by doing the things you’re suppose to do, so I can get the things I want.’ And if you do that, the danger is that you try to take work away from them. And you give yourself more work to do. And you establish a culture in which you doing people’s jobs for them.”

Francine Carter, founder of Action Coaching & Training, extended what Slaughter said, to include getting buy-in. “If they know why you need what you need,” said Carter, “and how it will move everything else along, then you’re going to have much more buy-in.” Buy-in, she said, isn’t always as simple as saying, “I need this because….”

Carter also pointed out that you need to consider where the other person is coming from.

“You never know what they’re thinking. They may be hesitating in getting it done because they’re afraid of doing it [or] they’ve never done it before. You don’t know what their story is, either. So the more that you can go at them and try to understand where they’re coming from and why they’re not doing it, [the more you can] maybe help them and empower them along. Think about where that other person’s story is. What are they thinking? Why are they hesitating and procrastinating on this?”

Brian Ball, a software engineer with Software Engineering Professionals, gave some advice on getting commitment:

“You want to put them on the hook for what it is that you’re trying to get them to commit to, and the easiest way to do that is to let them hook themselves. If you say, ‘Hey I need this as soon as possible.’ that’s one thing; but if you turn around and say, ‘So, I need this. Here’s why. When can you have that by?’ then they’re creating a commitment to you. And if they say, ‘I have no idea.’ then say, ‘I need to know, so I can plan my schedule.’”

“The other thing is that, if it is the case that they do start blowing you off, then you at least have something to go talk to somebody about. Say, ‘They said they were going to do this and have not given me a reason, and refuse to give me a reason, as to why it hasn’t happened.’ And I hate to bring out the big guns and bring somebody else involved into it, but usually it helps just to say I got them to commit to something.”

Ball also pointed out the other side of asking people to do something for you, which is thanking them. “Conversely, when they finally do actually get done what it is you ask for them, sit there and go ‘Sweet! That’s awesome!’!!” said Ball. “Pronounce it with three exclamation points even if you don’t feel like it, because you’re trying to make them feel good about what it is they did for you.”

Chris Wingate, a principal software engineer for Liberty Mutual, provided some of the easiest advice about managing commitments. In short, get the project manager to do it for you.

“Most of my performance test engagements [are situations where] you’re always waiting on somebody,” Wingate said. “Or, you’re trying to get another resource to get more information, or do more monitoring or track down this issue or that issue. The most effective thing I’ve found to get the team focused and moving forward on things is a 30-minute meeting twice a week. The project manager is there, the developer, the lead developer is there, the architect is there, the lead tester is there, so everybody knows what’s going on, everybody knows what the delays are. Let the project manager do that work for you.”

You can find the complete audio for the panel members response to this question on the Indianapolis Workshops for Software Testers website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.

How software project managers can react to recessionary trends

Project management (PM) consultant Michelle LaBrosse shared some quick tips for PM strategies in recessionary times with me recently. These ideas gelled during an interview with Carey Earle, president of Green Apple Marketing, on her syndicated radio program, Your World, Your Way.

“We talked about great ways to use these trends as a great launch pad for new ideas, solutions and direction in the workplace,” said LaBrosse, founder of Cheetah Learning, a PM consultancy, and aPM issues blogger.

Many projects are on an “economic slim-fast” diet, LaBrosse said. Not surprisingly, she’s seeing may project managers focus on practices that save their teams’ time, cut spending and improve quality and time to market. Also, businesses are trending toward novel perks in these days when raises are rare and budgets tight. She’s seen good results when project managers reward teams in inexpensive and creative ways, such as making a premium parking spot available to a top achiever each month.

The secrecy and lack of honest documentation of the early 2000s has caused an about face, in a trend that LaBrosse and Earle call The Full Monty. “Technology brings us a whole new level of honesty whether we like it or not, but underneath the technology is a new human desire for trust and transparency like never before,” LaBrosse said. “Think: Is your documentation in good shape? Are you leaving a trail that you’re proud of? How can you be more transparent in your business?”

Finally, LaBrosse advises project managers to start noticing trends on their own. “The art and science of noticing the dramatic or subtle changes taking place will help you and your team continue to seek out future opportunities and successes,” LaBrosse said.

Agile expert advises on agile transition snags, PMO problems

Recently, I spoke with Alex Adamopoulos, CEO and founder of emergn about his company’s new agile development transition consultancy program, AgilePMO. In these remarks from our interview, Adamopoulos offers advice on agile development process adoption and his views on agile.

Emergn, is a new company, but Adamopoulos’ experience in the software service field is extensive. He is a 20-year veteran and an active blogger.

What is your agile philosophy?

Adamopoulos: A transformation program. If I think about the guiding principles of an agile engagement, they’re the same fundamental principles of a well-run global company.

What are some common problems within PMOs (Project Management Offices)?

Adamopoulos: Even when I was embedded in the outsourcing community, I thought that large enterprises had a methodical process for why they’d select a vendor, manage a project, etc. I discovered that not only did a lot of them not have them, but the ones that do have them are typically by line of business.

Could you offer a hypothetical example of a company with a PMO problem?

Adamopoulos: A good example would be a top bank, in the top three. Their investment banking side, which drives more than half of the revenue, has a PMO, and that PMO is only operated by three people. It’s fragmented across two geographies. Then, if you go to asset management side, you discover that they have one-person shops or half-person shops. That is common for eight out of 10 of our clients.

Usually, they have no metrics or measurements in place. The metrics that exist are rudimentary project metrics that do not even translate into economic numbers or business value that a CIO can sit with his boss and say, “Here’s why we are making these decisions and how they are affecting our company.”

So, it would make sense for them to explore a way to drive it more efficiently. Right?

Adamopoulos: Clearly the largest problem we see is that there is no single project or program governance in place. There is no methodology for how programs should be governed. There is a lot of waste. We see morale being affected.

What are common snags that occur in transitions to agile?

Adamopoulos: Typically, it becomes a land grab. it is very difficult for some organizations to change their existing behavior and their business psychology. Asking them to collaborate and communicate, and be more dependent upon the business in several areas [is a big deal].

The biggest risk is the psychological impact that agile can have on an organization. Right or wrong, many have already settled into their comfort zones. Agile is a very disruptive methodology, not just at the software level but at the cultural level as well. The larger risks are people asking, “How are you going to impact my job, and why? What does it mean to me in terms of the responsibilities I might have?” There needs to be a lot of coaching in the transitioning people out of their current working mindsets and into something new.

Who are emergn’s target customers?

Adamopoulos: Today, the traditional customer for us is in the application development areas of IT; but we are starting to branch out with the AgilePMO product. Our primary target is the enterprise client, meaning the tier-one enterprise, the $1 billion-plus players. That is where the majority where our business is today. Is it likely that we’ll do things below that? Probably, but it would have to be very specific, because agile enablement reshapes a company’s sourcing strategy. Those are pretty important programs, ones that aren’t taken lightly, and we’ve found that the larger companies are more ready to do those than the smaller players.

The economy has been a help for us as opposed to a hurt; the whole drive of saving money, reorganizing, efficiency has supported our model. So, organizations that have very fragmented sourcing programs are the primary focus for us.

How long do you customers need emergn’s consulting services?

Adamopoulos: I am pretty sensitive to the consulting side. I have been a customer. I don’t believe in having people from the B-team or sit there for one, two years and billing against my company.

Maybe I sound old-fashioned, but we definitely want to drive value. For some companies that may take one year or even half. We are currently doing one large scale agile transfer program for one of the UK’s largest utilities that is a 24-month roadmap, but that is something we defined up front.

British Airways is a great example. We did an entire agile transformation for them. Since they are an airline, they have a gazillion projects going on. We have begun applying a number of initial successes into some points of business. How long they’ll take? I don’t know, but in their case they want to see their entire organization become as agile as possible.

Why software projects fail and more will fail in 2009

Why do software projects fail? There are many reasons –- and they’re spelled out below –- and 2009 may bring more failures than usual as budget cuts spur project managers to make cuts in the wrong places. So said software quality consultants Lawrence Oliva and Karen Johnson when I talked to them about 2009’s software quality landscape.

Human error causes most software project failures, said Oliva — senior consultant/program manager with CH2M HILL, an Englewood, Colo.-based engineering and program management firm — so most are avoidable. Here is his list of the mistakes he sees most often and his comments:

1. Unclear requirements: “Most people don’t know what to build because they’ve never defined it. When they build the software, it fails because it doesn’t meet people’s needs.”

2. Overly optimistic and/or unrealistic schedules. “People rush or skip things if the schedule isn’t realistic. Also, companies are panicking due to the economy. They’re compressing projects and schedules.”

3. Lack of user input: This links back to requirements mistake #1. “Developers don’t talk to people who are going to use the software.”

4. Lack of executive sponsorship and support: “When management doesn’t support and protect the project, it can often be undermined by internal politics and budget cuts.”

5. Turnover and layoffs: “Projects often fail when key people leave the project early in its lifetime.” Companies’ modern habit of laying off senior and, thus, higher-paid workers -– such as senior developers –- in favor of less experienced, lower-paid workers puzzles Oliva and me. “It doesn’t make sense, because the more experienced people take a humongous amount stability, experience with them that usually isn’t available any other place,” he said. “That hurts a project and hurts a company.”

I agreed, noting that the time lost due to less experienced workers’ mistakes and learning curve probably negates the savings in salaries paid. Oliva and I discussed that companies could do total-cost-of-layoff analyses; but Oliva said companies probably wouldn’t take the time to do that. “In a poor economy, companies often make hasty and project-wrecking decisions,” Oliva said. 

Besides layoffs, the recession is leading to other foolhardy cutbacks. It seems obvious that skipping testing is a path to software project failures, but software testing consultant Karen Johnson is seeing companies do just that. Johnson told me that companies are cutting down on or even skipping software testing altogether as a recessionary cost-saving method. If this trend continues, look for more embarrassing outages caused by admitted software failures or for “undisclosed reasons.”

While researching software failures, I read a Code Diesel post on software failures by developer Sameer Bora. To Oliva’s reasons why projects fail, Bora adds these common mistakes: sloppy development practices and poor reporting. Bora also created a handy chart on why software projects fail. Printed out or used as a screensaver, even, it could provide a visual reminder of project pitfalls.

Now it’s your turn: Do these reasons for failure ring a bell? Can you think of others? Let me know by commenting below or writing to me at  Trackback URL