challenges and benefits of Agile Methodology in project management

Post by Sajeev Menon:

challenges and benefits of Agile Methodology in project management

challenges and benefits of Agile Methodology in project management


Can Agile Teams Get Burned Out?

Burnout” Indicators
I want to share thoughts around burnout indicators. At the same time, I want to remain cautious in giving you a definitive list, as everything should be interpreted in the context of your culture and team dynamics. But knowing things to look for can be helpful in catching early stage burnout before it becomes systemic. Here are a few signs of burnout:

  1. Excessive overtime becoming the norm with long-term duration
  2. Rising mistakes: bugs, poor design choices and hurried implementations
  3. Rising temperatures, increasing levels of team stress and conflict
  4. Lack of humor/fun, team is too focused and lost any playfulness
  5. Lack of refactoring or quality investments
  6. Excessive negotiation (or avoidance) of your definition of “done”, rushing at the ends of sprints
  7. Excessive time off, high levels of team stress seeping into home
  8. Not taking time off, not taking vacations (or cancelling them)
  9. Increased paranoia: “they” are after us, we have no choice but to work this way
  10. Lack of transparency, honesty, openness and continuous improvement

Of course you don’t want to over-react. Hard work, dedication and engagement are hallmarks of healthy agile teams, and there is certainly “normal and healthy” stress within teams. But here I’m looking beyond healthy reactions, and I think you’ll be able to tell the difference.

Four Ideas for “Refreshments”
So if you are suffering from burnout, what are some helpful techniques to refresh and recharge your teams? This is simply a starter list of ideas for you to try or use to brainstorm your own refreshments:

1. Ask them. My first response would be to ask your teams. Ask how they’re feeling and whether they need a break of some sort. Also, set the stage so that it’s “okay” for the team to ask for a break without feeling wasteful, unprofessional or guilty. Gather their responses and sort through what options you might have to support their ideas. There’s nothing better than showing you care, are listening and are willing to take action on the team’s behalf. Then, based on feedback, give them a break.

2. Pair more. Pairing can often defuse the pressure on each individual team member. By definition, the pair is sharing workload challenges and more used to asking for help from others. They become more focused on the work and delivering high-quality features rather than the false focus of keeping team members at 100% efficiency. I’m talking about comfortable, non-forced pairing here, as it makes sense within the teams’ sprint goals and overall backlog.

Another byproduct of pairing is reducing single points of knowledge or skill within the team. This allows for more flexibility in the team’s ability to meet the business’ demands and reduces individual stress for key team members.

3. Plan for a break. I’m fond of injecting “breaks” within my organizational release tempo. I usually like planning for a “break” during the interval between release trains. Yes, I actually will pad time between releases, normally a week or so. Part of the week is for supporting the release. Part is for planning the next release. And a significant part is decompressing and personal time for the teams. Normally, I’ll leave it in each team’s hands to figure out how they’ll make the transition from one release to the next. But they need to factor in some break time for recharging their batteries.

4. Allow the team to work on their interests. Technical teams are often driven incredibly hard to deliver what the customer needs. I sometimes refer to this as feature-it is, or 100% Feature Syndrome. It’s not necessarily bad if done infrequently. But in excess, the team may be unable to complete things that they feel are equally important–for example, extending infrastructure, fixing bugs or fine-tuning some environmental tooling. I think excellent product owners learn how to feed their teams a balance of work–some of which is interesting to them. Allowing the team to occasionally work or immerse on what they want or what they think is important can often help recharge their batteries.

Wrapping Up
There is far too much burnout within agile teams today, and it’s leading to shoddy work and poor results. I’m not implying that agile teams should take it easy or not work hard. I actually think that “agile done well” is a very intense working pattern. Excellent agile teams can even burn out while working consistent 40-hour weeks, so the hours aren’t the only determinant.

I’ve mentioned the term “slack” several times in this article. I use it with Tom DeMarco in mind, and his exploration of slack in the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. The book does a great job of making the argument for allowing for and encouraging “white space” in your organization and team’s time.

What I hope I’ve inspired you to do is be aware of burnout within your agile teams. Look for the indicators and ask your teams about it. Show a willingness to slow down to go faster and to take the occasional break. Sure, you’ll need to trust that your team won’t take advantage of it. But why wouldn’t you trust those wonderful folks you’ve hired, anyway?

The Truth About Projects

Good afternoon and welcome to the podcast! You are listening to the No. 1 (because it’s the only one, really) project management talk show: The Truth About Projects! Hit us with your questions and concerns and we’ll give you solid advice. As we do each week at this time, we are here to take your calls on all things project management. No matter what situation you find yourself in…we are here for you. Let’s not waste any more time and get right to the phones. We are off to Oakdale, Maryland and Marie. Hi Marie, you’re on the The Truth About Projects!

Caller: “Hi Phil, first time caller.”

Welcome, how can we help you?

Caller: “Well, I have a project that has been going on for quite a few months. We originally retained a company to lead up a due diligence effort on a complex technology selection project we had. They came back with some recommendations, but the short list of companies that could do the work for us was limited to companies that seem to be friends of the consulting company. Should I be worried?”

So let’s just be clear on a few things, Marie. The PM on your project is a consultant and is not from your company, correct?

Caller: “That’s right, he’s from a consulting firm that was highly recommended to us.”

By whom?

Caller: “By my boss, actually.”

Okay. And what type of project are you dealing with? What type of technology?

Caller: “We’re trying to select an ERP system.”

All right, a couple of points here, Marie. First, how did you come to know that the firms recommended by your PM were acquaintances of the PM? Did he let you know ahead of time that he was looking to do this?

Caller: “I found out when I sat in on one of the presentations and it was clear when the PM walked in that he had worked with one of the individuals before.”

The Danger for PMOs in an Automated WorldEdit

In the last few years, the rate of growth in project management-related software has been incredible. Little more than a decade ago, enterprise project management software was a choice between a complex, lengthy and expensive implementation or a barely passable piece of off-the-shelf software that was likely to be rejected before it was properly configured. Today, there are any number of software suites that offer considerable flexibility, functionality, scalability and choice with very little upfront investment of time, effort or money.
However, many of the PMOs that manage an organization’s project execution functions have failed to adapt to this advancement in software. This leaves them at a distinct disadvantage, either failing to leverage all of the capability that is available to them or potentially limiting the benefits that the organization can gain with approaches that have become archaic. In this article, I want to look at how PMOs need to adapt and adjust in order to leverage these tools.

Five things an online Masters whilst travelling taught me.

It will soon be three full years since I last stayed put somewhere in this world for longer than 8 months. In that time, I have visited over 15 countries and had some amazing experiences.

Five months ago, I started studying a Masters in Applied Psychology on-line, part-time. So far I’ve studied in Ecuador, Chile, and Argentina. Soon the list will grow to Uruguay, Belgium, Spain, England, Israel and Russia.

I’ve experienced remote and awesome places, I’ve studied in hostels (Patagonia) and cozy small apartments in high-rise buildings (Santiago). I’ve studied in buses and awesome outdoor settings. It has been a beautiful experience, and I wanted to share some insights for anyone considering something similar: