Scrumptious

Most of you would probably have heard of the 1950's song with the same title. Here's the opening lyrics to that song:

Oh yes, I'm the great pretender
Pretending I'm doing well
My need is such, I pretend too much
I'm lonely but no one can tell

There are many pretenders in the Agile world. These individuals profess to be advocates for Agile, but either consciously or subconsciously exhibit anti-agile behavior. If I had a dollar for every person I've met in an Agile environment that talks the talk, but doesn't walk the walk, I might have saved a tidy sum.

In a recent experience, I came across a manager at a major Australian institution. Agile was a relatively new thing there, but the IT department in particular had matured enough to adopt some semblance of structure and value that kept the gravy train in operation. The reputation of this manager was one of an Agile though leader, and the department's achievements had been celebrated throughout the institution, so much so that this manager's word was never questioned with regards to the future adoption of Agile. But upon closer inspection, I discovered that the grass wasn't so green on the other side.

It became apparent that there were murmurings from within the team of professionals that reported to this manager. At first glance, major initiatives and deliverables were being met, and these brought value to the relevant business units. So, what could possibly be going wrong in this recent incantation of Agile across the institution?

The answer lies in the Great Pretender syndrome.

The manager knew all too well that "Agile" was a strategy that this institution had bought into, and like anything bought into, people will carry on kicking and screaming before they admit anything is going wrong. This allowed the manager to lead initiatives with an Agile flavor (the talk), such as prioritizing deliverables, planning and documenting only what was required, involving the business at planning sessions, professing that teams manage their own tasks, and the list goes on. However, behind the scenes, the manager was not assisting teams to be autonomous, manage themselves, hold retrospectives and reviews (which would have uncovered errors, issues and anti-value), and continuously improve the adoption of Agile (the walk).

Yes, there were the occasional team meetings, but these were predominantly geared toward making the manager and the delivery of initiatives look as rosy as possible to internal customers. Further, while the manager professed to support transparency and open discussions, when push came to shove, their opinion was final and no one could dispute this. In fact, on one conversation, I recall the manager saying "we don't debate here" when someone pointed out an error the manager had made. In another example, the manager would often micro-manage some team members to the point that the deliverable was not met on time. So rather than remove obstacles and be a servant leader, this manager had become the biggest obstacle of all.

So how does the great pretender get away with anti-agile behavior? Well, there are several reasons, and here are some that come to mind.

The allure of momentum
When you have a few wins on the board, and those wins become consistent, it can feel like the momentum is moving in the right direction. But if you are a puppeteer, you can make the puppet appear to be anything you want it to. De-prioritizing projects that you believe may be politically hot, diverting resources from one project to another to ensure it succeeds at the expense of another, and managing resources with the threat of consequences are just some of the ways to make value only skin deep. Sometimes, it may look like progress, but progress at what cost?

One-way feedback process
How any serious Agile transformation can accept a one-way feedback process between managers and subordinates is beyond me. Yet this is exactly what was happening in this institution. You simply cannot champion a transparent, innovative and fear-free working environment if the feedback process only allows managers to give feedback to subordinates, and the feedback from subordinates stops at the supervisor, and is only in a one-on-one setting. Who in their right mind is going to give honest feedback when the only judge of that feedback is the person you are giving it to? 360-degree feedback must be the hallmark of any good Agile environment, and that feedback must flow up the ladder to at least 2-3 management levels above the subordinate. This greatly reduces the chances of the pretender becoming a toxic leader, or their immediate manager protecting them from senior management review.

Emotional debt
You can only stomp on people for so long, even if it is ever so effortlessly. Just like technical debt, emotional debt can build up over time and bite you back. This is precisely how revolutions begin. A project may be tracking well on paper as evident through the deliverables being met, but festering within the belly of the collective can sometimes dwell resentment, anger and demotivation. Fear may drive human motivation in the short term, but in the long run, the human spirit yearns to break free and be what it is destined to be: Agile.

Can you think of any examples of the Great Pretender in your workplace? Is your Agile environment really only skin deep? Is your servant leader really just a leader of servants?

"He who is not a good servant, will not be a good master." - Plato
     

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!

Recently, I have been thinking about the relatively recent role of the Chief Project Officer in organizations. How do they stack up against other CxO's and how do they assist organizations provide real value to customers compared to a CIO or CTO? To answer these and other questions, I went in search of a senior project management professional who holds that CPO title for a major organization.

Peter Moutsatsos, Chief Project Officer for Telstra, Australia's largest telecommunications company, joins us for a very revealing and fascinating Q&A session. Please welcome Peter to our Scrumptious blog.

1. Why do some organizations need a CPO?

When you consider the accountabilities that all other C-suite executives hold, there is no single accountable person who is on the hook for successful project delivery.  Sure, most CEOs, COOs and CFOs are accountable for the outcomes of major projects, especially how these projects contribute to the financial performance of the company.  However, the delivery of these projects and the advancement of professional project practice are the lead indicators that ensure these successful outcomes are met.  That’s where the CPO can add a lot of value.  The CPO can focus exclusively on successful project delivery, developing project talent, and effective project sponsorship.  A CPO helps an organisation to shine the light on project delivery as a critical skill within an organisation.  CPOs know that corporate strategy is achieved through the execution of successful projects.  A CPO can make sure that the right people have the right tools and skills to work on the right projects that will maximize strategic outcomes.

2. What sets a CPO apart from a CIO/CTO?

I have met and spoken with a number of CIOs on this topic.  The main differences are subject matter expertise, their strategy lens and their place in the corporate value chain.  A CIO/CTO tends to be more upstream in a value chain.  They are mainly accountable for information technology strategy and defining the future information and technology architecture of a business. The CIO/CTO role has become increasingly complex over the years as more companies struggle with accelerating advancements in technology, digitization and cyber-related challenges.  This has meant that their focus has had to change in order to be effective in navigating these challenges. This involves a certain level of strategic thinking, information technology know-how, global connections and technical skills in order to be successful. A CPO tends to be downstream from the CIO/CTO.  The CPO’s contribution is to work with the CIO/CTO to frame project alternatives, select the right projects, help prioritize programs and projects, identify and develop key talent to lead major technology initiatives, develop and maintain project methodologies and to provide quality assurance over project delivery. This way, the CIO/CTO does not need to worry about delivery sufficiency and project management competency.

3. How does a CPO differ from a head of Portfolio Management?

The difference between a CPO and a Head of Portfolio Management is more complex to define.  This is because most companies have a Head of Portfolio Management before they create a CPO. The main difference between the two roles would be separating genuine portfolio management and planning from project portfolio delivery. The different roles would emerge because a business has grown large enough to warrant the Head of Portfolio Management to focus on optimizing the corporate portfolio, balancing trade-offs and priorities within each business unit and ensuring that the right mix of projects are funded.  These high stakes trade-off and portfolio re-balancing activities would detract from the same person also focusing on how well each of the funded projects are performing.  In companies that have many projects in-flight at any one time, the CPO becomes a critical function to monitor the delivery aspects of these projects, without also having to be concerned with optimizing the project portfolio.

4. Is Agile one of the skills a CPO needs in their toolkit?

I know there is a lot of debate at the moment about agile.  I like to frame the debate as being about agile as a mindset vs agile as a method.  I believe a CPO needs agile as a mindset in their toolkit, not so much agile as a method. Of course, knowing about all project methodologies is very useful for any executive to have.  However, a CPO, or any project professional, will be more effective if they can demonstrate flexibility and agility in how they approach a particular project.  Methodology alone is not that important.  What’s more important is knowing how to be an effective leader, understanding your customer and knowing which combination of tools in your toolkit will get the best outcome.

5. How do you see the future growth of CPO's?

I believe every decent sized organization needs a CPO.  I feel that there are quite a lot of CPOs out there at the moment, however, they are probably operating under different role titles.  As these people start to become more valued in their organizations for their ability to advance project delivery and to drive successful outcomes, we will see their roles relabeled to CPO, which will give the impression of a sudden increase in this critical function. The same thing happened in the mid 90s with CIOs.  Before CIO became mainstream amongst the C-suite, they were IT Managers.   The IT Manager role elevated to CIO when these IT managers started to have a greater say over company strategy and technology became an increasing factor in strategic objectives.  The same will happen with the growth in CPOs.  Increasing digitization across all industries, disruption from an increasing number of start-ups and greater pressure on CEOs and Boards to deliver greater returns to shareholders will result in new strategies to combat these challenges. These strategies will be achieved through successful project delivery, so you will see more projects in future and hence a growing need for a CPO.  

                                                             ***

You may be asking what does the role of the CPO have to do with SCRUM? I am happy you asked. The answer may exist in one of the answers from Peter himself. One of the key competencies in the CPO's toolkit is an Agile mindset, and while he stresses mindset over method (quite rightly so), most organizations apply a framework for delivering Agile projects. The most popular framework being SCRUM of course. In fact, Telstra adopts SCRUM which I guess is the cherry on top.

So fellow Scrumians, thank you for reading this latest blog post, and a personal thank you to Peter Moutsatsos (LinkedIn profile) for his great responses and contribution to the project management world.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!

There's nothing quite like a bowl of colorful, ripe and fresh fruit to entice the taste buds. They are a heathy source of vitamins and antioxidants to keep us healthy and by extension, happy. While apples are not my favorite fruit of all time, I have been told they do keep the doctor away. However, an unripe or bad apple might just bring the doctor to your front door. They certainly aren't the best option for your health, and probably something you would want to distance yourself from, and in some cases throw away.

In Scrum projects, the Scrum Team is that bowl of fresh fruit vital to the health of the project and the happiness of its stakeholders. The team collaborates and works in harmony toward a common goal which is the delivery of a valuable product. Sometimes however, not everyone is on the same page. There is occasionally a "bad apple" amongst the barrel that can threaten the success of the Sprint, release, and sometimes even the entire project.

Here are some examples of Bad Apples?

Negative - these individuals display bad vibes to the rest of the team for a variety of reasons. Perhaps they don't feel the product is viable, the team is not adequate, or the Product Owner is incompetent. These individuals always seem to find something to complain about and focus on the negatives rather than the positives.

Apathetic - these individuals don't seem to possess any interest, concern or passion for the project. They just do the bare minimum to get away with retaining employment. In some ways apathy can be more detrimental than negativity, as a negative person can still perform or exceed the team's expectations (other than attitude of course).

Dominant - normally a legacy of former glory as a team leader or star developer, these individuals don't respect the collaborative and self-emergent leadership attributes of other team members. They are usually confident, loud, and command the center of attention. Invariably more time is spent on these individuals during face-to-face communication.

What is the cure for these Bad Apples?

Well before we discard the bad apple, there may be a way to save it (or them). That should always be the first approach as a responsible Agile leader.

For the negative individual, firstly we need to understand if what they are being negative about is in fact a serious issue that needs attention. If a team member is being negative about a stakeholder that keeps interrupting them and slowing down work, then that is a real concern. Apart from legitimate concerns such as this, the negative person should be coached on the effects that their negativity is having on other team members. They should understand better ways to voice their feelings that are both constructive and not offensive. Further, they should be made aware that this project is a "happy" place where positivity reigns and negativity has no place. Constructive criticism is fine, but not when it crosses into negative waters.

The apathetic individual is a little trickier. They are doing their job to the bare minimum, but they do not embrace the Agile mindset of continuous improvement and optimizing productivity. For these individuals I find the best antidote is to gain their trust while understanding their motivations; what makes them tick. When you understand that, you can engineer ways to incorporate their interests into the project in ways that make them feel a part of the team. Nearly everyone wants to feel a part of something. You just need to make that thing the project.

Last but not least is the dominant individual. Unless you are scared of confronting issues head on, this is perhaps the easiest one to resolve. These individuals need to be coached privately at first on how their behavior is totally inappropriate and detrimental to the success of the project. When someone is too dominant, we don't get the full flavor of alternative opinions that bring life to stories, features, increments and products. These individuals need to be instructed on team rules and taboos that must be adhered to. However, they also need to save face and not feel embarrassed. I find the best way to handle these individuals is to work on an action plan you both agree to (very important) on some key points at a time. For example: "At the next team meeting, I want you to time yourself and not take more than 3 minutes of the 15-minute Daily Scrum, even if you have a lot more to say."

Failing all attempts to change these destructive attributes, the last resort is to remove the bad apple before they infect the rest of the barrel. No one wants to go there, so we need to identify the first bruise on the apple early so we have time to change the behavior. That way, we have the best chance of getting a healthy, happy, ripe bowl of product features to the market.

"A bruised apple is not all bad. It still has tremendous potential." - Seth Adam Smith

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!


 

Management support for remote working teams is so important in today's Agile organizations. To learn more, please read my latest article in PM Network (March 2018) on page 27 entitled Remote Support by clicking the image below.