The Agile PMO

Special Event - Agile Lunch Program in Chicago on March 21

For those of you in the Chicago area, I am excited about an invitation-only event I am hosting on March 21.  The topic is, Agile Adoption - What's the Payoff?, and it will feature speakers from Nokia/Navteq and our very own Sally Elatta of Agile Transformation.  The purpose is to provide a forum for senior managers who are passionate or interested in Agile to network and learn from each other.  We are meeting at Maggiano's downtown and lunch will be included.  

This is going to be an exciting opportunity to join the discussion on Agile Adoption.  Below is a short blurb about each of the speakers and their topic.  If you are a senior manager or leader in your organization, and you want to connect with like-minded individuals, please contact me.  You can also download the attached flyer for more information:  Invitation for Agile Executive Event Chicago March 21

Financial Payback of Agile Adoption, Jorgen Hesselberg

Agility enables organizations to quickly adopt to changing market conditions. This sounds attractive, but what is the financial impact of increasing the ability to deal with uncertainty? In this interactive talk, Jorgen Hesselberg will explain in plain language and through concrete examples how building a learning organization and maximizing embedded flexibility not only reduces waste, but dramatically improves the ROI of an organization’s initiatives and projects.

Jorgen Hesselberg is the Senior Manager of Enterprise Agile Adoption at Nokia.  With over fifteen years of experience in a variety of business environments, Jorgen specializes in helping companies achieve value through strong leadership and effective project management processes and techniques. As Director of Agile Alliance’s Agile Adoption program and speaker at international conferences, Jorgen is a recognized thought leader of Agile Enterprise Transformation.

Enterprise Benefits of Agile Adoption, Sally Elatta

Are you practicing Agile methods but wondering how you can take Agile and Lean methods to the Enterprise Level? Does your organization approve too many projects without understanding capacity? Do you 'push' and multi-task several projects at the same time using the same team members? This short presentation will give you a glimpse into the Enterprise benefits of stable teams and Agile Portfolio Mgmt. Please watch this video before the session: http://bit.ly/VT4gCC 

Sally Elatta is the President of Agile Transformation and an Enterprise Agile Coach.  Sally has taught thousands and coached dozens of organizations through their Agile Transformation journey.  She is the Agile Expert for the PMI Learning, Education and Development (LEAD) community of practice, hosts a popular 'Transforming to Agile' webinar series on PMI.org, and she is a frequent speaker at PMI and Agile conferences.  

 

 

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

Agile - Yes We Are Really Doing This

I do a lot of work with organizations who are beginning to pilot or adopt Agile in their teams.  Sometimes the PMO is leading the introduction of Agile, and sometimes they aren't.  And sometimes there is no PMO.

Agile transformations require buy in and support of the individuals and teams who are impacted.  Everyone who is involved in the transformation needs to move through a personal change process, and they need to buy in to the concept and to the benefits that the organization expects to get from Agile.

When there is a PMO, it seems that everyone who is involved in the Agile Transformation looks to the PMO to answer one question:

"Are we really doing this?"

The words and actions of the PMO are an important part of leadership, and they are critical to individual buy in and adoption of Agile or anything else.  An appropriate PMO response can send a strong signal that individuals and teams should press forward with the agile introduction.  When the Agile PMO is working effectively, the PMO says or does something that communicates loud and clear, "Yes we are really doing this". 

• Yes we are really doing this, and here is training and coaching for our new agile teams (small consulting firm delivering CRM solutions).
• Yes we are really doing this, and here is the change to our SDLC and standard deliverables to accommodate agile (Financial Services Company).
• Yes we are really doing this, and in addition to training, here are the organizational impediments that we are working to resolve, including implementing Agile Tools (a very small software development firm).
• Yes we are really doing this, and here is the training, ALM Tool implementation, and coaching support we will need (major publishing company).
• Yes we are, and as the head of the PMO, I will be attend your end of iteration demos.  (Financial Services Company).
• Yes we are doing this, and here is the coaching and training and process redesign needed to support Lean Portfolio Management that my team is going to drive (major Healthcare Provider).

When the PMO isn't working, the PMO says nothing, and does nothing.  And everyone gets the message about Agile - "This too shall pass".

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

Agile Bashing and the PMO - Part 1 of 2

I attended the PMI Chicagoland Professional Development Day (PDD) yesterday and observed some subtle Agile Bashing going on.  I suspect this behavior is probably happening across most large organizations, as a reaction to the growing popularity of Agile.  This is an area where the PMO can step in and provide leadership.

Let's start with the PDD.  It was well organized with a variety of speakers on a diverse set of topics.  Because there were multiple tracks, I only attended a fraction of the possible tracks.  What I observed some of the speakers doing which was a subtle form of Agile bashing.  Speakers were disparaging or dismissing Agile, primarily those speakers who were focused on more traditional project management topics. 

I noticed this in the second session I attended, where the speaker was dismissive of Agile.  He said that all of Agile has been around for years and in use.  "It's nothing new" he said. He called it a silver bullet, which is not a compliment BTW.  Let me ask you this, if an idea has been around, but it isn't being used, does that mean it should be dismissed?

I did agree with the speaker's specific example of Rolling Wave planning as something not new.  It has indeed been around a long time, and it is even included in the PMBOK.  By his own admission though, the PMBOK has swelled to over 400 pages and the next edition is likely to be over 500 pages.  So it is not surprising that Rolling Wave is in there.  At 500 pages, what isn't in the PMBOK?  I'll save my rants about the PMBOK for another post.

During a panel discussion, a popular speaker said he was starting a group called "free range project managers".  His point was that he advocated using the right tool for the situation, whether that was Agile or something else.  With a good track record as a project and program manager, a PhD, and several  published books under his belt, I actually think this guy could do a great job selecting the right tool for the situation.

The problem is, the average PM doesn't have a PhD and 30 years of experience and may not be so capable of choosing the right tools.  The track record for IT Projects in particular is abysmal, with only about 1 of 3 IT projects being considered successful by project management standards since the Standish Group began tracking project success rates in 1994. Clearly some of our project managers are not able to be effective, or to choose the right tool for the job, with or without the PMBOK. 

Is it important to point out that the Standish Group says that Agile are 3X more likely to succeed?  I don't want to cloud this emotional discussion with facts!

Trust me, this is an emotional issue.  It boils down to what people know and are comfortable with.  I believe that traditional project managers are threatened by Agile, or by the idea that there might be a better way of working than what they have always done.

Some Agilists have incited conflict by bashing Waterfall, which puts traditional PMs even more on the defensive.  Telling a traditional PM that Waterfall sucks is like saying that my baby is ugly (not true), or that my Mom wears army boots (mostly false). 

The debate is not about good or bad, it is about change, and change may as well be a 4-letter word.  I know for me, it gets harder and harder to change or to learn new things as I get older.  I am not saying this is an old guy's problem, but I did notice that most of the Agile bashing today was done by old guys.  And who can blame them - it's less painful and easier to dismiss new things than to take the time to understand and properly evaluate them, and consider changing.

Maybe we would be better off not using those big labels like Agile or Waterfall.  I think we would all agree that we need some method, process or framework.  And that framework should be based on best practices.  The less experienced you are, the more you need to apply the framework with discipline, without adding or deleting from it before you understanding why it works.  The bigger and more distributed your team is, the more documented, visible, and disciplined that the framework needs to be and hence why we have PMOs.  We should not make it up as we go.  And we should not say that we are something that we aren't, as an excuse to make it up as we go, as some Agilists do.

In my follow on post, I will outline some project management elements from Agile that I think are important enough for me to use for all my projects.  For today though, I think it is important to discuss the PMO's role in the Agile vs. Waterfall debate.  After what I saw yesterday at the PMI event, I have to believe this type of Agile Bashing is going on in most large and established organizations.

The PMO is in the position to make sure that PMs chose the right tool for the job.  We can have all the free range PMs in the world, but we cannot let 2/3 of them continue to fail by doing whatever they want, making it up as they go, and calling what they do PMBOK compliant.  In my opinion, the PMO should be stepping in here; they cannot afford to be on the sidelines. The PMO should be interested in what is best for the organization, and who is to say that it won't be Agile?

Which brings to mind the question of what is the role of the PMO, is it to maintain the status quo or to improve the performance of the organization?   Most PMOs seem to be about keeping things working just like they work today.  They seem to stifle creativity in their efforts to standardize; they squash coloring outside the lines.  (The speaker who dismissed Agile above also said that "PMOs are a wonderful thing...they must have contests about who can create the most templates!")  Hey, but enough PMO bashing! Let's get back to bashing something everyone dislikes - the PMBOK!

If you are wondering what the PMO should be doing relative to Agile, I have some ideas for you.  Here are some specific steps that a traditional PMO could take to properly evaluate Agile for their organization:

• Benchmark with other similar companies on how they are using Agile.  
• Bring in speakers, trainers, or coaches to raise awareness and knowledge. 
• Attend PDDs and see what others are doing with Agile
• Join LinkedIn Groups and engage in discussion
• Nurture an Agile pilot project or two, and clear the organizational impediments
• Really evaluate what parts of the existing methodology may not be used or working effectively for teams
• Rewrite processes that run counter to agile and productivity, like resource utilization over throughput.
• Write an agile track in the company methodology
• Bring an agile expert into the PMO
• Get coaching on how to transition to an Agile PMO
• Read the paper Sally Elatta and I co-authored on Transitioning to an Agile PMO
• Start a blog or wiki or discussion board to capture what the organization is learning about Agile
• Start a (positive) communications campaign within your organization about Agile
• Comment on this post and engage in the discussion
• Dig in to the success statistics on Agile success rates, or the business value of Agile and create a presentation for your team

Here are some things the PMO should not do:

• Put their collective heads in the sand and ignore agile
• Call Agile a fad or silver bullet, or disparage it in other ways
• Fight to maintain the status quo
• Burden fledgling agile projects with unnecessary documentation or governance

In my next post, I will tackle the best practices for project management from Agile that I think should be part of every organization's methodology tool kit.  You can use it as a checklist to see how many are in your methodology, or embraced by your PMO.  You don't have to call them Agile, just use them.

Cheers!

Anthony

Agile Culture Change Part 2

Last week I posted on how Agile drives Culture Change at the team and individual level.  This post looks at how Agile drives culture change at the organization level.  Change still occurs at the team and individual level, but the impact is on the distribution of power and control at the organization level. 

Many organizations find themselves in a power struggle between two groups of people who both feel that they are smarter than the other.  Yes I am talking about IT and the business customers that they service. As an outside consultant who is typically brought in to recover troubled projects, I've seen some pretty hostile (and sad) environments.

In many organizations, the relationship between the business and IT ranges from strained to downright contentious.  Hey, maybe it’s because I often seen only the problem projects.  Whatever the reason, I tend to see a lot of "friction".  Friction between people on the same team, sometimes, but more frequently it is the friction between IT and the business.  Both sides are trying to prove they are right, they are smarter, they are in control, whatever.

I once worked in the IT organization of an academic-related organization where the "business" was comprised of some really smart people who were usually Phds.  From the customer’s point of view, they were the real brains of the operation.  They tended to think of the IT team as a bunch of dweebs, or simply as order-takers carrying out their brilliant ideas.  In some cases they were right!  But mostly, their condescending attitude fostered a superior/inferior position that created a lot of unnecessary friction.   

In this organization and many others like it, IT had the reputation of never getting anything right.  The IT projects took too long, they cost too much, and they didn't deliver what the customer needed.   IT was bypassed whenever possible.  IT was the whipping boy of the organization; it was an expense to be managed and a necessary evil. 

And the feeling was mutual.  IT would definitely concede to the problems, but felt that many or most of the problems were the result of the business customers, not IT.  The business customers didn’t know what they wanted or needed.  They always changed their minds.  They always had unrealistic expectations about how fast things could be done. 

The beauty of this setup is that it allowed both IT and the business to have what they wanted.  IT could be the victim of the business persecutors.  The business could feel as though they were at the mercy of IT, and had a handy scapegoat to blame for anything that went wrong. 

This was really a struggle for power and control, about who would have the say over how the resources would be spent.  Neither side truly won, but they both felt they were not losing as long as the other side was to blame.  

Introduce Agile

Agile changes things.  Agile puts the buyer in control of the team and the spending.  Literally.  It is as if IT said, “we give up, you win”.   Agile puts the customer into the role of product owner and embeds them into the Agile team.  This changes the relationship dynamics, and forces a true partnership where both sides collaborate to achieve the best possible outcomes.

It doesn't end there.  The business person who is put on the team is put in the role of the PO.  Even the language is important - the product "owner" gets to set the priorities, provides leadership and direction, and make decisions.  And in a twist of fate, they are asked to showcase the results of the teams during the end of iteration retrospective.

The IT team gets to do what they like to do best - develop solutions.  And with access to knowledgeable business people who are able to make decisions, they can actually develop some good or great solutions.  And quickly, since wait times are reduced. 

 There are 12 principles that are at the core of why Agile works.  Several of those Agile Principles are at play here and they are worth reviewing.

 

"Business people and developers must work together daily throughout the project."

This is probably the single most important Agile Principle.  Working together daily. When a team works together on a regular basis, they get to know each other.  The Product Owner learns more about what it actually takes to specify, develop, and fully test applications.  The team gets the opportunity to ask questions about how and why people will use the solution, once it is developed.  False assumptions  can be brought to light and dispelled.  The risk of building unneeded functionality is lower, so that solutions can be built and deployed faster.  And where possible, working solutions are put in place sooner, rather than waiting till the end.

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

I wonder how many IT organizations, prior Agile, would say that they have a priority on satisfying the customer?

"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

Many organizations believe that if they could just freeze the requirements, then everything would be OK.  From my early training as a PM, I was taught the value of change control.  All changes must be signed off.  I helped to introduce change control processes that thwarted change, or made  change so painful that it was avoided. 

The problem with that approach is that change is a constant.  The competitive landscape today drives a pace of change unlike no other.  Traditional change control methods simply don’t work.

What does work is to allow the business to change requirements when they need to.  The only time the requirements are frozen is during the iteration, which is usually just a week or two.  Change in everything else is possible. 

But Does Agile Really Change the Culture?

The reality is that the relationship between the business and IT is very symbiotic.  One cannot exist without the other.  Agile brings that concept front and center.  For those organizations that want to change, Agile will drive culture change.

I've heard some great quotes from business people who were once in the battle with IT, but have now crossed over and embraced Agile.  Here are a handful:

"There is a much greater comfort level that the final product will be what we requested and what the end user needs."

 

"No longer am I hoping that we get what we need at the end."

 

"We won't do projects any other way."

 

"Our Product Owner never used to smile when she was working on IT projects, but now she is smiling."

 

"We want all our projects to be Agile Projects."

Your thoughts?

Anthony

Complacency kills!

I was reading a recent article from The Economist about the recent decline and near death of Kodak.  The article is called "The last Kodak moment?" and the subtitle is, "Kodak is at death’s door; Fujifilm, its old rival, is thriving. Why?"

It is an interesting read, especially the comparisons drawn between two organizations with the same core business and different strategies for survival.  Fujifilm is alive and well and Kodak isn't, and the reason seems to be the decisions made and the level of urgency with which they addressed the threat to their core business. 

Reading the article, I couldn't help but think of the typical PMO, in response to the growing popularity of agile methods.  I am not suggesting that agile methods will put the PMO out of business, but it does change the need for the PMO, the role of the PMO, and the role of project managers in the organization.  PMOs need to adapt and leverage the new methods and concepts that agile offers.  The alternative is to resist change, to justify and focus energy on current methods, and to ultimately become an impediment.  Agile enthusiasts know what happens to impediments.

I've recently seen the ugly face of resistance up close.  In a recent agile transformation project, the biggest resistance was seen from a PM that had transitioned from the PMO to be a scrum master.  Unfortunately for this individual, she continued to focus on the priorities of the PMO (budgets, status reports, and related projects) rather than their new duties of scrum master (coach and facilitate the team).  I don't know whether this was a fallback to the familiar and comfortable, hostility toward the agile introduction, or simply a resistance to change.  Whatever the cause, the result was an ineffective scrum master who was holding back her team.  She became the team's impediment.

Harvard professor John Kotter published a book in 2008 called A Sense of Urgency.  You can get a taste of the book from Kotter's 11 minute video interview called The Importance of Urgency.    He talks about the rate of change in the world today and the importance of leading change in organizations with a sense of urgency.  Organizations that don't change and adapt fall behind.

Kotter also noted a natural tendency for individuals and organizations to become complacent.  He suggests that we need to guard against the tendency for complacency.  Kotter claims that all organizations are at risk of growing complacent, even those as progressive as Google.  Even the largest and technically advanced firms fall prey to complacency.

Is your company, department, or team complacent?  Is your PMO complacent?  How do you think they would compare to Google or Kodak?

Complacency kills.  Be a change agent instead.

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