The Agile PMO

I Need to Become an Agile PMO Quickly!

A subscriber to this blog, who I will call Chen (since that is his name), wrote me recently to ask how he could become an Agile PMO Quickly.  He wanted to know what resources I could share with him to help in his development process.  I thought it was a a great question, and apparently one that I hadn't yet answered effectively in this blog.

I initially responded to Chen that one doesn't necessarily "become" an Agile PMO, as much as they become more agile as a PMO.  I am not sure we ever arrive, so to speak, and become Agile.

I surmised that when he said quickly, Chen wouldn't be interested in doing like I did and spending 20+ years doing projects the traditional/waterfall way.  That experience helped with my perspective.  The cost, including a fair amount of frustration with problem projects and programs, served to motivate me.  But that won't be quick.  So I guess if he wants to be quick he had better learn from and stand on the shoulders of those who are further along the path from him.

Here are an even 10 different resources that will help anyone to become a MORE Agile PMO Quickly.

#1 Study the 4 Agile Values and 12 Agile Principles - If you review and internalize those values and principles, and strive to be consistent with them in everything you do, you will be well on your path to being an Agile PMO.  Visit the Agile Manifesto.

#2 - Master Scrum - Scrum is the most popular Agile framework that replaces much of the traditional project management needed by a team.  Scrum flips the traditional triple constraint upside down, and fixes schedules and costs, while requirements are allowed to vary.  The Scrum guide is free, quick and easy to read, and should be absorbed in it's entirety.  After you read it, go watch an agile team for 1) a daily standup and 2) for the end of sprint/beginning of sprint Scrum meetings.  It will be enlightening.

#3 - Understand Agile from the Project Management Viewpoint - A good paper for this was written by Mike Cottmyer for VersionOne.  I think it may be helpful to PMs who are trying to ramp up on what Agile is all about.  Follow this link to register at VersionOne for the paper.  Another way to understand Agile from the PM perspective, is to review the PMI Agile Certified Practioner (ACP) materials, including the PMI-ACP exam content outline.  You can also tackle some free PMI-ACP practice exam questions to get a flavor for what PMI thinks Agile is all about and how you would do on the PMI-ACP exam.

#4 - Read what is an Agile PMO - There are a handul of items out there that will help.  I blogged last year about a good paper from Kevin Thompson on Agile PMO.  In hindsight, I was a little hard on Kevin as he was attempting to do what many of are attempting - shed some light on what it means to become more agile, in particular at the PMO level.  Kevin's written several other related articles, like Scrum Meets PMP.  You can also read everything that is posted on this blog!

#5 - Study Sally - Sally Elatta is an Agile thought leader, trainer, coach, and President of Agile Transformations.  Sally has done many webinars on Agile Adoption for the PMI Learning Education and Development (LEAD) CoP.  In addition to being a terrific speaker, Sally has a deep understanding of Agile concepts and communicating to various audience levels.  Here are links to some of my favorite Sally webinars; note that some require registration or PMI membership (updated on Feb. 5):

• Transforming to an Agile PMO
• A Journey Through the Agile Lifecycle
• Scrum 101 Short Videos
• Success Factors When Transforming to Agile
• Agile Portfolio Planning with Kanban

The free videos require (free) Registration on AgileVideos:

• The Business Value and ROI of Agile Methods 
• Servant Leadership 

These recorded Webinars require that you login with a valid PMI Membership:

• Agile Requirement Gathering
• Agile Idea Qualification and Project Initiation
• Agile Iteration Planning and Execution
• Agile Estimating and Planning
• Agile Requirements
• A Journey Through an Agile/Scrum Project Lifecycle 
• Transform Towards High Performing Teams Webinar
• Success Factors for Transitioning to Agile

#6 - Pizza Party - Pick one of the webinars that you like from the list above, buy a pizza or two and invite your team or colleagues to view it over lunch.  Instant learning lunch!

#7 - Study More Sally - Sally Elatta and I co-authored a paper (did I mention that I work for Sally?) for the Cutter Consortium.  The topic is Transitioning to an Agile PMO, the do's and don'ts. Click here to to register with Cutter and get it for free.

#8 - Watch this video about the dark side of PMO's and Agile.  The video from Rally features Dave West, a VP of Research at Forrester Research.  The most interesting part of the video comes at the beginning.  Dave West was part of a panel group interview at a Rally event, and made some comments about the posture of PMO's, basically saying that as things get more complex, their reaction is to add more governance.  Hat tip to Scott Dunn and his blog on Software Development and Human Capital.

#9 - Form a cross-organizational team to promote Agile Adoption in your Organization.  Some people call this group the Agile Champions Team, some call it the Agile Working Group.  It doesn't matter what you call it, but have a group that is dedicated to Agile, and empowered and motivated to identify and remove organizational impediments to Agile Adoption.  Jorgen Hesselberg shared his presentation on the Agile Working Group at Nokia/Navteq at a recent Agile Meetup in Chicago and it was extremely helpful.

#10 - Listen in, or better yet, join a discussion.  Ask your questions.  Let others explain what worked for them and what didn't.  LinkedIn has lots of places to look for these types of discussion, you might join in the discussion here as a starting point.  You can also post your comments, challenges, inspirational thoughts, or humorous quips here on this blog.

So there you have it, 10 ways to Quickly Become an Agile PMO.  What do you think?  I'd love to hear from you.

Cheers!

Anthony

Emotional Intelligence for Agile Leaders - 9 Tips

As I noted in a previous post, I have been working on the second edition of Emotional Intelligence for Project Managers.  Thankfully, I was able to turn in the manuscript on time today, so that is no longer hanging over my head!

The second edition includes a new chapter on Success with Agile Teams.  Anyone who has used Agile methods will attest to the fact that leading Agile teams is not the same as leading traditional teams.  There are a lot of challenges for those of us who have a lot of experience managing traditional project teams.  Agile teams are expected to be self-organizing. This doesn’t mean there are no leaders, but it requires a style of leadership that is less prescriptive and more supportive.  It is often called Servant Leadership, and it requires a lot of emotional intelligence.

I ended the new chapter in the book with the following 9 tips for leading Agile Teams with Emotional Intelligence.  I'd love to hear your feedback on these.

1. Evaluate your level of Command and Controlism.  Take a step back and really evaluate the ways you use command and control.  Are you holding back the teams you lead by trying to control them?  If you are having trouble seeing it in yourself, note whether you see it in others.  Or, ask those you trust to provide you accurate feedback on your behavior.  
2. Proactively step back and let others step up.  Try stepping back and letting others decide what to do.  Spend less time trying to force your will on others, or to manipulate them to do what you think they should do.  Trust that whatever they do, they will learn from their behavior.  
3. Say less; a lot less.  Rather than always being the first to speak up, trying shutting up and listening more.  Really tune in to what others say, rather than your own internal chatter, or simply waiting for your chance to speak.  See where the leadership comes from when you don't hog all the airtime.  Try the empathetic listening techniques we've discussed in the blog and in Chapter 5 of the book.
4. Practice some form of daily mindfulness.  This is important for all PMs, but it is especially important for leaders of Agile Teams.  Whether you use meditation, prayer, journaling, or some other technique, establish this as a daily practice that you do to be clear with yourself before you engage with the team.  Put to use some of those Self-Awareness techniques discussed in this blog.
5. Get underneath your fear.  Most of us who feel the need to control do so out of fear, and many of our fears are irrational or unwarranted.  Look below the surface to see if you can determine what you are afraid of.  I know for me this is usually a fear of failure.  I am afraid that the team will fail and that it will reflect poorly on me.  Some of us also fear a loss of relevance.  After all, if the team can do great work or come up with great ideas without me, what value do I have?  Dig deep into what your underlying fears are, so that you can understand how those are affecting your behaviors with the team.
6. Use Jedi Mind Tricks - When it comes to decisions, put the decision back on the team rather than jumping in and making the decisions for them.  Try holding back on your own opinion even when asked.  Take time to pause and to ask the team, “What do you think we should do?”.  You might be surprised at what they say.  Or you might say, "Is anyone else feeling the pressure to decide right now besides me?"
7. That’s a Great Idea! – Some of us are so hungry to be affirmed, that we often find it hard to accept new ideas or perspectives from others.  We’re used to saying things like, “that is a good idea BUT it won’t work because of… “.  To overcome this type of behavior, practice saying "That’s a great idea!", and then look for every opportunity to say it. It may not come easy.
8. Use Positive Regard with Everyone - See the team at its very best, not necessarily in their worst moment.  Know that the team will rise to the occasion when they need to; that they will learn from their experience, and that they will get better over time.  Hold each member of the team, and the team as a whole, with high positive regard.
9. Be a Servant Leader – Agile team leaders, Program Managers, and Functional Managers all need to support the agile team.  They frequently need to serve as a buffer between the Agile team and the rest of the organization.  Tune in to the organizational norms that run counter to Agile and run interference for the team.  Help streamline mandatory documentation or other PMO requirements do that the Agile Team can be empowered and self-organizing.

I've mentioned this book several times before, but it is worth mentioning again.  A great resource for Agile project managers, coaches, program managers, and functional managers is Lyssa Adkins 2010 book, Coaching Agile Teams; A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Lyssa provides many ideas for supporting Agile teams, overcoming command and controlism, and leading ourselves.

I'd love to hear your comments, whether you are an agile project manager or one who is using more traditional methods.

Cheers!

Anthony

Agile Bashing and the PMO - Part 2 of 2

In my previous post, I noted that some of the speakers at the recent PMI Chicagoland Professional Development Day were bashing Agile.  They were derisive and dismissed Agile as 'nothing new'. 

The speakers may be right that Agile is nothing new, however, they missed the point.  The point is NOT about the newness of Agile; the point is whether people are using project management methods that are effective.  Most IT projects are not deemed successful, based on the Standish Group Chaos Studies that measure project effectiveness based on traditional project management standards (on time, on budget, and with required functionality).  So stop bashing Agile, and start talking about what is required to increase project success rates.  And in particular for those of you in the project management office (PMO), stop making or accepting excuses for why Agile doesn't work for you.

I promised in my previous post to outline some of the project management elements that I think are critical to all projects, Agile or not, and I challenged readers to compare their methodology to my checklist.  Tell me which of these you don't feel are important in your environment, and why or why not. 

One last thing - it might be helpful to note whether the allowed practice matches your methodology.  If your actual practices for project management vary from the methodology, then it would only make sense to compare your actual practices to my list. 

1. Communications - Most of us would agree that communications are an important, if not critical part of successful projects.  I like the frequent and focused daily team communications that occur during Scrum standup meetings.  I also like the concept of pairing (2 people working together) from XP; it helps share knowledge and build stronger teams.  Finally, I have a strong preference for using the most intimate communication mode available, like face to face meetings, rather than email.

Give yourself a point for each of these items that your methodology supports:
 ______  Daily Standup Meetings
 ______  Pairing, whether pairing 2 programmers, a programmer and a BA, or some other combo
 ______  Face-to-face meetings are a priority; we use them whenever possible

2. Transparency - Organizations benefit from Teams that are clear about their progress.  The overall team status should be posted in a public place, with clear progress against plan, with nothing hidden and no surprises.  Updates should be at least weekly, and preferably daily or real time.  Teams benefit when the people working on the team are responsible to provide clear and transparent progress reporting at the person-task level, rather than the project manager running around and collecting the information.  Tasks need to be granular enough that they get done by one person in about a day or less.  Task reporting is done by one of three states: not started, in progress or done - we shouldn't waste our time with proving % complete.   

Give yourself a point for each of these items that your methodology supports:
______  Clear and Open Team Level progress Reports, updated at least weekly
______  Clear task level status reports updated daily

Take away a point for this item:
______  Use of % Complete status reporting

3. Predictability - The team should have a credible and effective way of estimating the work remaining, and when the project will be done or a major piece of functionality is delivered.  This should be based on the actual delivery of value (i.e. velocity) as measured on a weekly or bi-weekly basis.  I've seen too many projects where it was on time right up until the date for launch or go live, and only then was it late.  Those are unwelcome surprises!  If you don't have accurate forecasts, it's not working! 

Give yourself a point if your methodology supports:
_____  Predicts team delivery accurately

4. Short cycles - We need to break work down into short iterations of 1 to 4 weeks.  Each short cycle should produce something of value to the end user or customer.

Give yourself a point if your methodology supports:
_____  Iterations that deliver value every 1 to 4 weeks

5. Constant feedback and Learning - We need to incorporate feedback on a regular basis.  Each day there should be some reflection with a more formal lessons learned or post mortem at least every 2-4 weeks.  Lessons learned at the end of the project are a complete waste of time to perform and store.

Give yourself a point if your methodology supports:
_____  Regular retrospectives every 1 to 4 weeks, with feedback incorporated.

6. Planning, and Re-planning are routine activities that the term performs.  We should adopt rolling wave planning so that we plan in detail the work that is near term (the current iteration) and spend less time planning work that is in the distant future.

Give yourself a point if your methodology supports:
_____  Rolling wave - plan in detail only the work to be performed in the next 1 to 4 weeks
_____  Planning - work is planned by the resources who will perform it. 

Take a point away if:
_____  Individuals outside the team plan the work and commit to delivery dates.

7. Change - The pace of change is increasing daily.  We need mechanisms to incorporate not only what we are learning, but what is changing, whether that be technology, competition, or team capabilities. 

Give yourself a point if your methodology supports: 
_____  Support changes in requirements without undue cost, penalty, or waste.

8. Requirements - For all but the smallest of efforts, it is impossible to state with accuracy the requirements up front.  It may actually be counter-productive to specify them in detail, based on the previous point about change and learning that occurs during the execution.  Our methods need to flex, to recognize this fact.  And if the requirements cannot be known well in advance, we should not spend a lot of time on developing detailed budgets and schedules to complete those requirements. Let's stop pretending we can accurately schedule things that are unknown and unpredictable.

Give yourself a point if your methodology supports: 
____  Our methods allow for us to adapt to changing requirements.

Take away a point if your methodology includes: 
_____  We produce detailed project schedules for time frames beyond 90 days

9. Accountability and Commitment - The project manager has been thought of as the 'single throat to choke', or 'the first one to take a bullet when the team fails'.  The reality is that it takes an entire team (crap, I almost said "it takes a village").  The team, not the PM, can either deliver a successful project or not.  To that end, we need mechanisms to shift the accountability and commitment to the team members.

Take away a point if your methodology includes: 
_____ The PM or team lead is held accountable for the team performance

10. Self-Organizing Teams - It is more efficient for the team to figure out what needs to be done, and execute it, than for the PM to do it for them.  It is also more rewarding for the team members, and the PM.

Give yourself a point if your methodology supports: 
____  Our methods encourage self-organizing teams to flourish

 11. Miscellaneous.  Score yourself on the following, with positive or negative points:
____  (-1) Multitasking - System processes that encourage the maximum utilization of resources by spreading them across multiple projects, work against the success of all projects.  People should be assigned to as few of projects as possible, with one project per person be the ideal.
____  (+1) Constant Engagement with the Customer - It is not sufficient to involve the customer only at the beginning and end of projects.  Customers should be involved throughout the project to make decisions and provide direction.
____  (-1) Paperwork and Documentation - Some level of documentation is generated for all projects.  However, most projects waste a lot of time producing, reviewing, and updating documentation either 'just in case', or 'just because' the PMO or other governing body requires it. 

Total Points ____

I believe the above list is a pretty good starting point, based on my experience.  There are a total of 18 possible points across all categories.  What did your methodology score?  Which areas do you disagree with?  Which areas represent fighting words?

Cheers!

Anthony

What is the role in Agile for Project Managers, Program Managers, and the PMO (part 2)?

This is a follow up to my previous posts about role changes for project managers and program managers working in an agile environment.  My last post talked about project managers and in this post, I am going to focus on the program management role.  We might have to tackle this over a couple of different posts!

First, let's start with the role and defined activities for the program manager.  In the PMI Standard for Program Management, the program manager role is described as:

1. Supporting and guiding the individual project managers, in particular to help them understand how their work fits in the big picture
2. Achieving the program and organizational objectives
3. Structuring the program and related processes to support the teams to complete their work and to integrate their deliverables to achieve the program end goal, product or service
4. Ensure projects are organized and executed in a consistent/standard way

Each of these activities plays out in an interesting way when program managers begin to incorporate agile teams within their programs.  This is exactly the thing that I have been challenged with over the last 10 years.

I had my first real experience with Agile back in 2003.  I was asked to lead the IT portion of a large program charged with large-scale data collection in the country of Qatar.  We had a number of teams working together to develop data collection tools and instruments.  Only one team was using agile methods (scrum primarily).  A highlevel project schedule is shown below with the agile activities called out.

 

At the time, we didn't think of this team as being anything different.  We created traditional plans based on a form of waterfall and ignored the fact that they were doing daily standups, they were self-organized, and that they pulled prioritized features and defects from a central backlog.

My next experience with the collision of agile and the program was in 2008.  I was working with an organization that was piloting and preparing to roll-out a vendor software product within their network of hospitals.  The product was an existing off-the-shelf software and the vendor was adding significant new features based on the feedback from our pilots.  A high-level timeline for this work is shown below.

The challenges with this particular product were mostly around the prioritization (and payment for) the added features.  Our pilot teams were providing feedback in the form of specific requirements that the vendor needed to deliver.  Though not written in user story format, the 100 or so statements of functionality were the features that the teams needed. 

Unfortunately the vendor wasn't very clear about how these features would be built.  We worked through an account rep and sometimes interacted with an internal product manager.  They considered our list, and our 'must have' features.  But they had an internal roadmap, that wasn't shared with us, that they used to drive their development.  This lack of clarity and expectations was a major risk for the program since we could not be sure of the functionality that we would get and we needed that to plan the rollout. 

It's also important to note that agile was appropriate for the development of the product.  However, we still needed to have traditional plans for training, rollout, technical support and other functions. 

Also in 2008, I led another large program.  This effort was actually a program within a larger program to support the launch of a global web platform.  There were 4 main components:  a program to develop the web platform (external to our program), development of an administrative system, development of back office application interfaces, and integration testing of the three efforts.  This is shown on the high level timeline below.

One of the challenges in this environment was the synchronization of schedules for the various teams.  For the back office integration teams, this development was done in a traditional way and was mostly completed.  For the platform and the administration systems, the development was being done using agile methods.  Unfortunately these two teams were not synchronized on their sprint cadence or their release points.  This caused numerous headaches for the integration test team who could not be sure what functionality would be delivered at what time.  We also ran into challenges with the development backlog, or more specifically the prioritiztion of development for items on the backlog. 

The last significant example of agile in the program environment occured in 2011.  I had joined a large business re-engineering program with multiple teams.  All the work was being done in a traditional waterfall manner and in fact, months had been spent trying to lock down requirements.  When a new program leader was brought on, he drove the transition of this program to adopt agile methods.  Within 6 months, we had moved to 10 scrum teams who were working from a single prioritized backlog and were delivering against one high level roadmap (see below).

With 10 agile teams, this became the standard method for organizing and driving the program.  There were 4 other teams that were operating in traditional methods but that became secondary to the scrum teams. 

The main challenge in this fourth example were that the Roadmap became the main driver for the overall program.  This replaced the function of the project schedules that were developed for other programs.  There were necessary points of communication and integration with all the teams - including the traditional teams - and these integration points became the main focus for program management.  Finally, it was critical that the program manager become versed in agile and champion the agile practices.

Some of the consistent challenges or takeaways across all 4 of these programs includes:

1. The greater the proportion of agile to traditional, the more important it is that the Pgm Manager embrace, champion, and enforce the use. 
2. Program Manager must be well versed in agile and champion agile practices.  Program managers should understand and leverage the flexibility that Agile teams can provide. Conversely, Methods like scrum actually require a lot of disclipine and the Pgm need to be aware of that.
3. Program Manager needs to understand the critical dependencies between teams and between the development backlogs.  Program needs to align team efforts around the roadmaps and release schedules for the agile teams.  Where possible, all teams should be on the same or a related cadence to simplify communications, training, UAT, and other downstream efforts.
4. It is critical to understand who is going to prioritize the items on the development backlog.  The program manager should be involved in decisions that affect the bigger picture and the other teams in the program to avoid sub-optimization.  A related issue is managing internal customer expectations is critical – feature priority and timing!

It seems inevitable to me that Program Managers are going to need to be comfortable incorporating agile methods.  Hopefully this post will help them thinking about what is required.

As always, I'd love to hear your thoughts.

Anthony