Posts Tagged With: Process compliance stupidity

Have courage!

When we think of the characteristics of a good team player, we tend to come up with attributes such as demonstrating selflessness, possessing empathy, or being a good communicator. While these are all critical to creating a high performing team, one trait of effective project managers and team members is the ability to do things which take them outside of their comfort zone. In other words, courage.

Why do I consider courage to be so critical?

Courage won’t guarantee that right decisions will get made, but it might prevent some bad ones.

Presented with an unrealistic deadline to deliver fixed scope with fixed resources and budget, if no one demonstrates courage by raising concerns or by negotiating for a feasible commitment, the team might have just signed up for their very own real-life Kobayashi Maru scenario.

Perhaps a sponsor or other senior stakeholder is pushing for the use of a particular delivery approach for political reasons. If it is not the best fit for the needs of the project, it’s rare that the accountability for this bad decision would fall on that stakeholder but it’s more likely that the team will bear the brunt of the issues.

Maybe the business case for your project is no longer attractive. It might be safer to keep your head down and continue to deliver according to approved baselines, but wouldn’t it be better for your company, your team and your own career if you were to bring this concern to the sponsor or other appropriate governance body?

Maybe your organization’s project management methodology requires the completion of a particular artifact. No one on your team believes it adds any delivery or risk control value. If you don’t have the courage to ask “Why?” or to seek an exemption, you’ve likely lost some credibility with your team members.

Courage preserves integrity by enabling us to operate with transparency

It’s hard to tell your customer that there is a unrecoverable variance or other critical issue with their project. But if we candy-coat this message, or worse, avoid telling the customer entirely, the truth will out, and the fall out is likely to be much worse than if we’d summoned the courage to break the bad news in a timely manner.

Maybe one of your fellow team members is behaving in a manner which is irritating others. If we don’t have the courage to provide coaching or constructive feedback sensitively but directly to that team member and give them an opportunity to respond, we aren’t demonstrating respect for that team member or our team.

Courage enables us to grow

Whether your project is being delivered using an adaptive or a deterministic life-cycle, team members and your company as a whole will benefit if they occasionally work on activities which fall outside of their core specialization, if doing so benefits the team. Developing generalizing specialists will take support from both functional managers and from one’s peers, but it also requires a healthy dose of courage for us to try something for the first time, knowing that we might fail. This applies not only to the activities performed by team members, but also the types of projects or work assignments we ourselves take on.

Courage is the most important of all the virtues because without courage, you can’t practice any other virtue consistently.” – Maya Angelou

 

Advertisements
Categories: Project Management | Tags: , , , , | Leave a comment

Does your PMO hinder or help your agile transformation?

An agile project management office might sound to some like an oxymoron, right?

This might be a reasonable assertion as many PMOs were first formed to provide oversight over a portfolio of projects and enforcing standards sounds like the antithesis to agility. But many successful PMOs have evolved beyond governance and control to helping their company reach higher levels of organizational project management maturity, and increasing agility should be complementary and not contradictory to this pursuit.

There are many ways in which PMOs can hamper progress towards greater agility including:

  • Enforcing standards over principles
  • Continuing to apply traditional funding models and prerequisites to agile investments
  • Obsessing over vanity metrics such as velocity or time to market rather than business value delivered or shipped features utilized
  • Evangelizing agile from the ivory tower instead of actively engaging with and supporting teams
  • Failing to inspect and adapt

So what can a PMO do to actively support an agile transformation?

  • Collecting chronic impediments from agile teams, curating and prioritizing them, and championing their elimination by the appropriate senior leaders
  • Having the courage to say “NO!” when a given context is not suitable for using an adaptive approach
  • Advocating for funding to incent early adopters to try new delivery approaches
  • Encouraging staff who possess the right expertise, behaviors and attitude to train and take on Agile Lead/Scrum Master or Product Owner roles with coaching support
  • Examining their own operational processes and leaning them out as much as possible
  • Shifting portfolio reporting from being a manual, onerous process to the automated consumption of information radiators
  • Migrating from an artifact-centric delivery approach to an information-centric model
  • Transforming heavy, gate-based governance to a metrics-driven, exception-based process
  • Working actively with functional managers, procurement, HR and other key stakeholders to change their project engagement models to be more support of adaptive approaches
  • Helping portfolio governance committees to make their investment selection, evaluation and prioritization processes more agile

An agile transformation provides the leadership of a PMO with a good opportunity to review their charter and service catalog – are these still relevant, and if not, what can be changed to ensure that the PMO is not identified as common impediment by agile teams!

 

 

 

 

 

 

Categories: Agile, Facilitating Organization Change, Project Management, Project Portfolio Management | Tags: , , , , | 2 Comments

How successful is your sprint planning?

Sprint planning is one of the standard events within the Scrum framework.

This ceremony or an adapted version has also been incorporated within other agile delivery frameworks which time-box the work of teams. The purpose of the ceremony is to align the team on what they will be working on during the upcoming sprint to ensure that their efforts are focused on delivering the highest priority work items in a quality manner while maintaining a sustainable pace of work.

Successful sprint planning lays the foundation for a successful sprint but this just completing the ceremony doesn’t mean it is delivering value.

Here are four common challenges which impact this critical ceremony.

Where is everybody?

Sprint planning is that singular opportunity to get everyone’s buy-in on what will be accomplished in the upcoming sprint. Partial participation means that decisions are being made on behalf of team members who are not in the room. That is likely to reduce their sense of ownership for the sprint backlog and increases the risk that work may be accepted which cannot be successfully delivered without heroics. While it might be convenient to conduct this ceremony first thing in the morning, the team should develop a sense of when they are likely to be fully present in mind and body and schedule it accordingly. Similarly, it is not advisable to start sprints on Mondays as that tends to be a more common day off than the middle days of the work week.

A lack of preparation

If the backlog doesn’t reflect the Product Owner’s priority, sprint planning is not the time to bring it up to date. Similarly, while highly mature teams are able to complete task identification, modeling, sizing or other preparatory activities during sprint planning, most others find that spending some effort in the previous sprint doing some look ahead planning will reduce the likelihood of running out of time in the ceremony or slicing off a sprint backlog with only a limited understanding of what needs to get done.

Appetite exceeds capability

Its normal for new teams to accept more work in a sprint backlog than they are realistically capable of delivering. However this gap between expected and actual velocity should reduce progressively sprint over sprint. When a lack of predictability regarding team capacity is not a blocker, teams which consistently take on more work than they are able to deliver are either demonstrating a lack of self-discipline or they lack the courage to educate autocratic external stakeholders on the dangers of accepting unrealistic commitments.

It’s my way or the highway

Whether it’s the Product Owner or a (supposedly) observing senior stakeholder, there’s no excuse for the development team being told how much work they will accept in a sprint.

Does your team experience any of these impediments? Is your team sufficiently self-aware and transparent such that these challenges are identified during retrospectives? If not, why not?

 

Categories: Agile, Project Management | Tags: , , | 1 Comment

Create a free website or blog at WordPress.com.

%d bloggers like this: