The Agile PMO

Emotional Intelligence for Agile Project Managers, Scrum Masters, Leaders and Coaches

I am working on the second edition of my emotional intelligence book and one of the things I am excited about is adding a whole new chapter on how emotional intelligence (EQ) is applied in Agile teams.  This includes all those soft skills that Agile team leaders, scrum masters, project managers and other stakeholders need.  This is going to be a combination of the two things I am very passionate about so I am excited to dig in.  Also, with the growth of Agile methods in organizations, I think the second edition would be incomplete if it did not address leading Agile projects.

Interpersonal skills are critical to leading Agile teams. I saw the connection between emotional intelligence and Agile teams very clearly when reading Alyssa Adkin's book, Coaching Agile Teams.  Alyssa reminds us of many things that we probably already know but that we may be too busy or distracted to put into regular practice.  Her entire book is a gem and a must read for anyone who is leading or coaching an Agile team.  I will be focusing on the parallels between emotional mastery and the skills required to effectively lead Agile teams.

Here is a laundry list of some of the ideas and themes that I plan to explore over the next month or two.

• Command and control leadership in Agile Teams is a non-starter.  The key to success with Agile Teams is Servant Leadership.  We will explore both what servant leadership looks like, as well as explore some ideas for those of us who have relied heavily on the commanding style of leadership in the past.
• The Agile team leader/scrum master needs to practice being in the moment with their teams.  That means focusing on the here and now, and being fully present and engaged.
• Using our own emotional self-awareness is a great source of information about what is going on.  How we feel, is a reflection of the emotional mix within the team.
• Agile leaders need to be willing to quietly leave space for other members of self-organizing teams.  In other words, Agile leaders often need to be less, so that others can step forward and be more.  This will be hard for some of us who are accustomed to speaking, or feel it is our job to step into the void, or that we know more than others know.
• With self-organizing teams, it is the leader or coach's job to help the team figure out for themselves what to do next, rather than solving it for them.  Adkins often uses the expression 'Take it to the Team".  This reminds me a lot of what my mentor Rich used to say, which I considered one of those Jedi mind tricks - "What do you think you should do?"  He would sometimes take it to the next level with me when I responded with, "I don't know".  He would say, "Well if you did know, what do you think the answer would be?" 
• Taking it to the team is closely related to the concept of positive regard.  Positive regard is assuming that the individual is whole and complete, and that they have the ability to figure things out for themselves.  It is based on the field called humanistic psychology which was pioneered by Carl Rogers.  Rogers believed that all people are inherently good, and that they have all the internal resources required to grow as individuals. 
• My book already has a number of ideas for how to be self-aware and manage our own emotions.  Adkins recommends making this a daily practice and provides several additional techniques for staying grounded that Agile leaders can put to use.
• How our choice of words influences the conversation.  Adkins calls this the level of violence in our communications, and provides a lot of tips for how to understand and adapt.

There will be more topics that surface as we dive into this.  One that I know is relevant is about the proper functioning of other key stakeholders in the Agile ecosystem; program managers, functional managers, the PMO, and executive leaders. 

I welcome your comments and feedback and look forward to digging in to the topics over the next few weeks.

Cheers!

Anthony

Using Agile to Recover Failed Projects Part 3 of 3

Anyone who has been around projects long enough has had the experience of a troubled, or at least challenged project.  As a problem project guy, I've been through my fair share of challenged projects.  In the last few years since becoming an Agile enthusiast, I've been using Agile to recover troubled projects.  Mostly it works.   (Hint:  it doesn't work if you violate the Agile Principles and Values).  This is the third in the series on applying Agile to recover troubled projects. 

The Problem Project

This particular project was actually a program of 5 projects that was underway for 7 months and hadn't delivered.  The program was most likely oversold by the vendor, and underscoped and understaffed by my client.  It was also being driven as a technology project by the software vendor. 

The most apparent sign of trouble to outsiders was the pattern of missed deadlines.  This was in spite of being reported as almost done, which was the other sign of trouble.  The status reporting was of the "good news only" variety.

For various reasons, nothing was ever "done done", though lots of things were in process and some were reported as almost done.  When one particular piece of work was stalled, additional threads would be started in an attempt to get something done.  It felt like a good strategy - start more things in the hopes that more things would finish.  The results are just the opposite.  It was like sending more cars down a freeway that had a traffic jam - it actually made things worse.

The technology was being driven by the software vendor with little true engagement with the business.  The end users didn't understand the software and had little input to the requirements effort that was led by the vendor.  It was little surprise then that much of the planned software was determined to be unnecessary when it was reviewed and actually understood by the business.

After 7 months, the project team was overwhelmed with the volume of work.  The organization's culture worked against the team; 'do whatever it takes', and never say it cannot be done were the norms.  So there was a sense of resolve, of just hunkering down and brute forcing the project over the line.  Even as they fell farther and farther behind, and deadlines looked more hopeless, the team responded by worked harder and harder.  And they threw more people at the problem.  Unfortunately this approach doesn't scale up, nor is it sustainable for more than a short period of time. 

As we began planning for the Agile transition, what immediately became clear was the incredibly inefficient processes in place.  Data conversion was probably the most complex challenge, and the data conversion process involved more handoff's than the Olympic Torch Relay. (*Technically this is not true, the London Olympics Torch Relay involved 8,000 handoffs).  Data was gathered and entered into templates by the local team, then sent to the vendor office on the West Coast where it was entered into other spreadsheets.  Those spreadsheets came back to the local team with questions that had to be answered.  Then they were sent to an offshore team for entry into another tool for conversion.  The offshore team, lacking clear business rules, simply logged the issues  and sent the data back to the local team for resolution.  This created long queues and waiting time between the various handoffs.  Work piled up and rework became common.  Because of the number of people involved, and the lack of clear process, conversions were done over and over again using multiple interim deliverables.  Process changes would render the interim work out of date and the team would start over with fresh data.  The majority of the communications took place via email, with very few face to face meetings.

Various people were trying to fix the broken processes but the reality was, everyone was working so hard that they were fatigued, and no one wanted to stop and think about the potential futility of their actions.  This is a very frequent occurence on problem projects, especially death march progress.  The team members get tired, overwhelmed and they throw themselves into the work, losing all objective perceptions of progress and reality.  It is actually quite similar to what happens in wartime.  The phrase "The Fog of War", coined by Prussian Military Strategist Carl von Clausewitz, speaks to this concept:

“War is an area of uncertainty; three quarters of the things on which all action in War is based on are lying in a fog of uncertainty to a greater or lesser extent.”
- Carl von Clausewitz

The Agile Transition

So we were engaged by the project sponsor to transition the project to Agile.  The sponsor was not initially a fan of Agile, but I suspect the mounting project costs and repeated delays and lack of predictable end dates left her desperate enough to try it.  With her securely on board, we trained 5 teams and worked with them to create the Scrum artifacts like prioritized product  backlogs.  We installed Product Owners from the business teams and put in place the strongest Scrum Masters available.  The sponsor was directly engaged in the initial replanning sessions.  She contributed to the team vision and values, and helped foster an attitude that this could be done.

The Agile transition wasn't immediate or pain free.  The project had been underway for 7-8 months before the move to Agile.  It took two or three iterations, lasting two weeks each, before there was some clarity on what work remained and when the project might finish.  Those finish dates continued to firm up after four and five iterations.

The teams consistently used the typical Scrum processes like iteration planning, daily standups, demos and retrospectives.  Each team had a task board and we used a common team room for those task boards and the daily standups.  In addition, weekly steering committee meetings and two 'scrum of scrum' type meetings were used each week to esure or confirm alignment of the efforts and facilitate cross team communications.

Another tool that was helpful in aligning the teams was having common plans.  A high-level release plan was used to create a framework for major milestones such as the go-live date.  A more granular iteration plan showed how the deliverables from the 5 teams would be delivered over time.  This iteration plan gave the leadership team the type of granular visibility and informed decision making that was needed.  It was reviewed each week, and changed or re-prioritized when appropriate. 

The Payoff - Progress!

The beautiful thing about Agile is that when you apply it properly, it just works.  Work is prioritized, and teams begin delivering useful solutions early.  Iteration progress is visible on the tasks boards.  Business and technical teams work together daily.  As my friend and experienced project manager Cam used to say, "Hey, this stuff isn't rocket surgery!"

Some of the immediate and important benefits of this Agile Transformation:

#1 - Progress Transparency - No longer was the status cloaked in % complete ambiguity.  There was a defined backlog of work that was not done, and the teams completed some of it every iteration.  You could immediately see the progress of any team in any iteration just by looking at their task board. 

#2 - Role and Task Transparency - Progress transparency extended down into the tasks of the backlog so that it was clear what each individual was working on and responsible for within every iteration (see color coding above).  As part of the Scrum framework, team members developed detailed tasks to support the completion of the user stories, assigned them, and tracked them to completion.  Daily standups were used to track process at a detailed level.  The end of iteration demos served to prevent the teams from going too far off the rails.

#3 - Predictability - With common release and iteration plans, and an average velocity for the teams, it became easier to determine the ability to deliver critical functionality.  Not only was there visibility to the plan, the teams were able to be realistic in their commitments, and deliver against their plan with some level of certainty. 

#4 - Team Focus - A critical aspect of Agile is to focus the team's effort like a laser beam.  Chasing a lot of work at the same time is counter productive, though it is often an attractive way of working.  After the transition to Agile, each team scoped what could be done in the next two weeks and just took that much on.  By prioritizing, and focusing on just one or two items critical to the go-live, the teams were able to eliminate a lot of unnecessary work, and speed things up considerably.  "One is better than none" was an early theme of the re-planning effort.  (Focus is also a key Lean principle, though we will save that for another post.)

“One is better than none.”

#5 - Building the Right Solution - The use of the backlog that was prioritized by the engaged business stakeholders meant that the next important thing was clear.  It also meant that we were building the right solution. 

#6 - Collaboration and Working to Common Objectives - By aligning the 5 teams to the release and iteration plans, it became much easier to get teams focused on hitting release dates.  There was a sense of cooperation across the team.  This was supported by the development of the success criteria and elevator pitch, which the project sponsor participated in creating. 

Keys to Success:

Active Direct Leadership from the Business Sponsor - I've mentioned the business sponsor and her direct involvement in the program.  That was one of the biggest factors in the success.  The sponsor participated in the development of the charter and vision.  The sponsor held weekly steering committee meetings.  The sponsor assigned the correct people to be part of the engagement, from across the business and technical teams.  And the sponsor turned up at the end of iteration demos, asked good questions, and thanked everyone for their hard work.  That type of active involvement is important.  As one of my favorite leaders, Bill Hybels, said recently, one of the most important roles of a leader is to energize the team. 

Full Agile Adoption - There was no wishy washiness about the Agile adoption and discipline.  Driven by the business sponsors, everyone on the team embraced it.  A few may have had their doubts about the efficacy, but that lasted only one or two iterations.  Once it was clear that the program was healthy and all teams were delivering against their prioritized backlogs, agile criticism faded.

Getting the Right People On the Bus - One of the principles that Jim Collins taught in "Good to Great" was that leaders need to get the right people on the bus. 

“...leaders of companies that go from good to great start not with “where” but with “who.” They start by getting the right people on the bus, the wrong people off the bus, and the right people in the right seats.”
- Jim Collins, Good to Great

This same principle applies to projects in trouble, and to Agile projects generally.  In fact, one of the 12 Agile Principles speaks directly to this:

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

As the project transitioned to Agile, new leaders were put in place in various roles including the Scrum Masters and Product Owners, and other technical and business leaders.  Conversely, it was also necessary to get some people off the bus, which is also pretty common for the recovery of troubled projects.  I would argue that it is vital that the old guard be moved out of the picture to make space for new leadership, ideas, and ownership. 

Agile Principles Most Relevant to Success:

To conclude this post on this successful project recovery with Agile, I'd like to highlight what I think were the most important Agile Principles to the success of the recovery. 

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.  
• Business people and developers must work together daily throughout the project.  
• Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.  
• Simplicity--the art of maximizing the amount of work not done--is essential.  
• Working software is the primary measure of progress.  
• Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

 I'd love to get your comments, or hear your stories about project recovery or agile transformation.

Cheers!

Anthony

Using Agile to Recover Failed Projects (2 of 3)

Last week I posted about a successful application of Agile to a troubled project.  It was the first time I had attempted this, and it worked beautifully to get the project back on track.  From the time we applied Agile, we had transparency and predictability.

Following that successful recovery, I began to apply Agile to nearly every project I led.  I joined an SAP implementation team as the PMO lead in the Spring of 2009.  In my enthusiasm, I proposed some of the scrum ceremonies like iterations, burndowns and backlogs.  The SAP methodology people came down hard on me, and put me in my place. "You don't know SAP", they told me, "there is only one way of getting an SAP project done."

I have mixed emotions when I get progress updates from that SAP project.  It is still going after nearly 4 years and it hasn't delivered yet.  The organization spent more than 40 million dollars, and has yet to see some return for their time, effort, and resources.But that project wasn't in trouble when I joined (or when I left), and this series of posts is about applying Agile to problem projects.

I had another chance in 2010. I joined a large custom development project team. It was organized as a waterfall development project and the team was working on Requirements. In fact, the requirements effort was widespread.

The massive requirements effort was lead by the business team. They were excited about the task, well intentioned, and wanted to do a thorough job of spelling out the details of the new system. They canvassed the organization to gather requirements from all owners of the business. Subject Matter Experts in various area were identified and asked to participate. An external vendor was brought in to help the team to apply leading and best practices in the new application. Everyone was encouraged to think, no to dream, about what the system could possibly be. This new system was going to be EVERYTHING and fix all the problems of the current system.

I'd like to say I didn't ask enough questions. Or that our executive leadership didn't provide enough direction. Or that my enthusiasm for Agile ways got the best of me. Or that I wasn't really the leader of the team (I wasn't the named leader). It doesn't really matter. The fact is, I take full responsibility for what came next.

Seeing the massive requirements gathering effort as a problem in itself, I proposed that we apply Agile. We broke the Requirements topics down into backlog items, and used two or three week iterations to complete them. Yes, what I am saying is that I set up a 9 month Agile project that was producing Requirements as the final output.

Randy Pausch is credited with saying that "Experience is what you get when you didn't get what you wanted". That sounds a lot better than saying I helped a company misuse their precious resources to gain nothing more than requirements. GOOD REQUIREMENTS one could argue, but requirements nonetheless.

Several Agile Principles and an Agile Value were violated in the process. And I mean violated in the most extreme sense of the word.

1. Working Software over Comprehensive Collaboration (one of 4 Agile Values)
2. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Working software is the primary measure of progress.
5. Welcome changing requirements, even late in development.  Agile processes harness change for the customer's competitive advantage.
6. Business and developers work closely together daily.
7. Simplicity--the art of maximizing the amount of work not done--is essential.

Let's start with the first 4 of these since they are all related.

Agile Value:  “Working Software - OVER - Comprehensive Documentation”

Agile Principle:  “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Agile Principle:  “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Agile Principle:  “Working software is the primary measure of progress.”

This was our primary mistake in the application of Agile to the project.  What we were doing is an ineffective bastardization of Agile called Waterscrum, or Scrumfall. Were we doing a better job on requirements than we would have without Agile?  Perhaps.  But we were still producing requirements, not working software.

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

This was the next big problem. We were taking 9 months to document requirements. Those requirements were going to sit on the shelf for a while, then when the technical team was ready to engage, we would dust them off, review them, and begin to develop the ones that everyone agreed on. It would be full year in most cases between when a requirement was documented and when the development would begin for that requirement.

The key to all of these items is the focus on working and valuable software, and this is where the project was off it's footing from the beginning. As a traditional waterfall development effort, there was a big focus on getting the requirements right. The 9+ months of getting the requirements complete was no where near Agile since there was no development planned anytime soon.

Requirements have a limited shelf life; they begin to expire as soon as they are created. The business needs change, our understanding of the requirements changes, and so on. Worse, the requirements we'd gathered were not able to be finalized because we were missing key reviews and approvals from the technical team. Those technical people were too busy working on other things to review the requirements which leads me to my next violated principle.

Agile Principle:  “Business people and developers must work together daily throughout the project.”

Simply put, we didn't have the technical team engaged in the project.  They were busy working on other projects.  They might occasionally join a meeting, but they were busy with other development.  In effect, they were stalling us because they knew they didn't have the time to engage on these requirements or any type of development.  

Agile Principle: “Simplicity--the art of maximizing the amount of work not done--is essential.”

One of my favorite of the Agile Principles is this one about maximizing work not done.  Our approach to requirements gathering virtually ensured that we would be reviewing and reworking the same requirements over and over until the technical team engaged and even then there would be more discussions.  Most of the work prior to engaging the technical team was throwaway work.

If this project wasn't 'troubled' when I joined, it was troubled at this point.  My attempts at Agile were simply streamlining a misguided approach.  What was needed was a more pure application of Agile, and that came in the form of a new program leader.

Our new project leader decided to implement real agile and abandon waterfall.  It was the right call and I was glad to be part of the process.  Within the next 4 months, I helped to train over 100 people.  We evaluated 3 software packages, selected and implemented VersionOne.  We established 8 cross-functional teams comprised of developers and business people working together.  We had real scrum masters and product owners.  Software was delivered every 2 weeks, gradually increasing in terms of velocity.  We started a scrum of scrums, and synchronized on a 2 week schedule.  We measured  velocity.  By all measures, the program had turned the corner and was now a true Agile program.  

My Lessons Learned from this Project

1. Don't ignore the Agile Values, they are the key to success with Agile.
2. Don't ignore the Agile Principles, they are also the key to success with Agile.
3. Don't lose sight of the end goal- delivering working solutions that provide business value.
4. Ask more questions.  I needed to do that before joining the team.
5. Take in the big picture, and not get focused on sub-optimizing part of the problem.
6. Start small.  This was a massive program and the transition to Agile was a big direction change.  It was painful to change and require a lot of alignment, communication, and change management efforts. 
7. Engage the executive team.  While we had a steering committee, we lacked true executive engagement in the program. The steering committee was mostly ineffective in providing any type of direction.

In my next post, we will look at another successful project recovery.  As always, I welcome your comments.

Cheers!

Anthony

Using Agile to Recover Failed Projects (1 of 3)

I am delivering a presentation in October for the PMI Milwaukee Chapter titled Applying Agile and Lean to Everyday Projects.  One type of everyday project that I think is important is the really messed up project.  My experience has shown that troubled projects can significantly benefit from Agile Adoption.  This is the first of 3 posts on using Agile methods to recover failing projects.

In this post, I will take a look at the first project that I introduced to Agile back in 2008.  My second post will look at a case where Agile did not help a troubled project and why.  My third post will focus on another example of when Agile did work for a troubled project and some of the indications of when Agile will work best for project recovery. 

 

As mentioned, I had my first experience with applying Agile to a troubled project back in 2008.  I'd previously been involved in 4 or 5 other troubled projects and recovered them using traditional project management techniques.  In most cases, that was just to re-establish baselines for requirements, budgets, schedules and risks, and then execute the projects with discipline.  In recovering the 2008 project, we adopted Agile and that turned out to be a great success and one of the most effective and exciting turnarounds I had ever led.  This early success with Agile certainly colored my perception of Agile's overall effectiveness.  That confidence in Agile led to a failure the next time I applied it to a troubled project.   

 

But let's not get ahead of ourselves.  The problem project in 2008 was one sub-project of a very large program to launch an enterprise web platform for a publishing company.  As part of the launch, the company's core documents were going through a source code conversion and testing process so that they would display properly on the new platform.  The conversion part was going pretty quickly and pretty quickly the testing team was finding and logging plenty of defects.  Pretty soon they outstripped their Excel tracking tool and moved to Heat.  Within the first 3 months, the team had found over 11,000 defects and they continued at a rate of about 2,000 per month.  

 

It was the remediation of the defects that was the problem.  With 500 defects closed per month, the defect remediation team fell quickly and hopelessly behind.  The team responded as most teams do in this situation- they hunkered down and began working as hard as they could.  The team moved into crisis mode and gave in to long days.  Communication between team members atrophied, and while there were more meetings to satisfy the curiosity of the management team, the level of effective communications dropped.  Team morale, and productivity, also began to decline. 

 

By the time I joined the team, there were over 16,000 open defects and they continued to outpace the rate of closure.  I deep a deep dive with the individual team members, and then met with the management team to review my findings:

• Lack of Agreed Definition of Done - There was confusion around the exact document set to be reviewed and lack of clarity on the backlog of defects that needed to be fixed for launch.  There were multiple stakeholders that needed to agree on the priorities and no one had taken the time to get their input.  The team didn't know at a document level how many defects had to be corrected to get the dcocument through, they were just working as hard as we could on anything that moved. 
• Lack of Productivity - The workload and morale had actually caused a decrease in overall productivity.  The crisis mode led to a lack of alignment of efforts as everyone was just doing whatever they could to fix defects.
• No Roles and Responsibilities - On a related note, everyone seemed to be going in different different directions.  There was a lack of roles & responsibilities.

There were some additional things that I see clearly at that time.  I've come to see that these are often present in problem projects and they tend to make bad projects get worse:

• Lack of Transparency Progress Reporting - This turns out to be one of the common findings on problem projects.  The progress results tend to be so disappointing to the stakeholders that people stop simply stop reporting them.  I had one of the previous team leaders tell me that "We were tracking the completion dates but the numbers were so bad that we stopped reporting them.”  There was a misreporting of the backlog of completed documents that could have either been overly enthusiastic or deliberately misleading, depending on your perspective.  The team was using % complete as a measure of progress but the basis for the % shifted continually.

“We were tracking the completion dates but the numbers were so bad that we stopped reporting them.” 
- Former Team Leader

• Unsustainable pace of work - There was a mindset of just working harder; no one really felt they could take the time to pause or slow down and figure out ways to work smarter.  You have probably seen this for yourself, where people just buckle down and suck it up.  The team feels trapped on the project, and team members shift into survival mode as there is no end in sight to the work.   
• Poor Communications.  The team and program-wide communication had degraded and communication silos were common.

Applying Agile

Just prior to joining this project team, I had developed and delivered an Agile Project Management training course.  Though I had some exposure to Agile previously, I was anxious to put what I learned to use and this project seemed like a great application of Agile.  I made the proposal to adopt Agile to the executive in charge and he agreed.  We immediately implemented the following changes to the project.

• We scrubbed the backlog to get a crystal clear sense of the work remaining.  We started with the list of documents which numbered somewhere around 4,000.  It was hard for me to fathom why there wasn't clear agreement on how many of these documents were needed.  Over time we were able to reduce this number down to 3,650 documents to be corrected, and we prioritized them into three major groups.
• We also scrubbed the list of defects and made sure they were all tied out to the documents.  We were initially focused only on the priority one defects for the priority one documents.   There were 15,700 open defects at that time with 4,700 being our top priority. 
• We began using scrum with two week iterations.  Each iteration was preceded by a planning meeting where the work was planned in detail.  Each member of the remediation team made a commitment to the number of defects they would personally close.  We used daily standup meetings, and a retrospective at the end of each iteration.  We did not use a demo.
• We had senior management fully engaged in the program.  The executive in charge attended the iteration planning meetings and most of the daily standups.
• We created reporting tools that provided us crystal clear transparency into the work we were doing.  This included daily progress reports (see below) that showed the expected and the actual results for the start of every day, and the variance.  We tracked both defect resolution and document completion progress.  This report came out every morning just prior to the daily standup.

Learns

So what did we learn from all of this?  Here are some of the highlights: 

1. Agile Saved the Day!  The adoption of Agile was the structure needed to work our way out of the mess.  Following the Agile Principles was a big improvement over the crisis mode.
2. Morale Improved.  The use of Agile resulted in improvement in morale.  The team was communicating, and everyone was focused on the same set of objectives.
3. Focus Helped the team use precious resources effectively.  The team discussed and focused their efforts for the two week iteration.  Each day when we reviewed the progress report the team focused on what they would be working on in terms of the highest priority documents, and the highest priority defects. 
4. Individual and Realistic Commitments Work.  The team members were able to estimate what they could accomplish in a 2 week period, commit to completing it, and then actually complete the work.  They tended to deliver on their commitments, even if it meant a push toward the end of the iteration.
5. We saw an immediate improvement in predictability.  After adopting Agile, we could begin to deliver predictably.  Coupled with clarity on the work remaining, we were able to make better decisions on tradeoffs, and could predict when we would be done with our work. 

My good luck on this first Agile project may have actually led to a false sense of confidence.  Based on my sample of 1 project, I mistakenly believed that Agile was THE SILVER BULLET.  As a result, I began to look for more problems to be solved using Agile, and that was to be my undoing.  In the next post, we will take a look at a second, less successful attempt to apply Agile to recover a problem project. 

Cheers!

Anthony

 PS:  I mentioned my speaking event in Milwaukee coming up in October.  Here are some other speaking and training opportunities that may interest you.

 Tuesday August 28, 2012, Nashville, TN

How Agile are You? An Agility Assessment for Project Managers, PMI Nashville Agile Community of Practice, Details Coming Soon

Saturday September 8, 15, and 22, Northbrook, IL

PMI-ACP Certification Prep Course.  Anthony Mersino will deliver the PMI-ACP Agile Certification Course.  Results guaranteed!  If you don't pass the PMI-ACP exam on your first attempt, you can take a second training course at no additional fee.  Register Now

Wednesday September 26 - Friday September 28, Nashville, TN

PMI-ACP Certification Prep Course. Anthony Mersino will deliver the PMI-ACP Agile Certification Course. Results guaranteed!  If you don't pass the PMI-ACP exam on your first attempt, you can take a second training course at no additional fee.  Register Now

Wednesday October 10- Friday October 12, Schaumburg, IL

PMI-ACP Certification Prep Course. Anthony Mersino will deliver the PMI-ACP Agile Certification Course. Results guaranteed! If you don't pass the PMI-ACP exam on your first attempt, you can take a second training course at no additional fee. Register Now

Pause and Reflect - A Key Agile Practice

Agile enthusiasts know that one of the 12 Agile Principles relates to a consistent practice of pausing and reflecting.

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. "

Though not exactly a retrospective, I did have the opportunity to take a well-earned break last week.  I slowed down my pace and was completely off the grid for 4 full days.  It was AWESOME!  I came back to work yesterday and felt like I actually liked people again!

I am telling you all this to say I didn't post last week because of my vacation.  I was literally pausing and reflecting.  So here is a quick update on a few topics in place of my regular post.

The Agile PMO

I am thrilled that the article I co-authored with Sally Elatta of Agile Transformation has been published by the Cutter Consortium.  You can get a PDF copy of the article by going to the special site and entering the special code of AGILEPMO.  I should warn you that it isn't War and Peace, but it is still a pretty good article.

I stumbled across a couple of interesting articles about PMOs that are worth browsing.  The first two are from blogs by Todd Williams that I found through LinkedIn.  Todd is banging on about PMOs and their effectiveness.  His first article is titled, Poor Leadership, The Progenitor Of PMOs, and the idea is that the only reason that PMOs exist in some organizations is because leadership is lacking.  The second is titled, No Enterprise PMO Equals Poorly Managed Organization. 

The third article on PMOs was was posted by J. LeRoy Ward over at Ward Wired.  He referred to a study that ESI International conducted on PMO effectiveness.  You can get the article here.  Anyway, it may come as little surprise that many organizations do not find their PMOs effective.  In addition, there is a lack of transparency about the PMOs effectiveness, which I found interesting since transparency is a key attribute of scrum and agile.  Agile bares all, so to speak. 

Another interesting finding from the ESI study was the declining perception of value that the PMO provides.  You have probably experienced this phenomenon in your own companies.  Something that seemed like a good idea at the beginning becomes a slow moving, bureaucratic, and blocking organization within the company. 

Speaking and Training Dates

I also wanted to mention that I am starting to step up my speaking and training engagements as we head into fall.  Here are some initial dates and topics - you can email me for more information or visit my home page at Project Advisors Group.

#1 - Tuesday August 28, 2012, Nashville, TN

How Agile are You?  An Agility Assessment for Project Managers, PMI Nashville Agile Community of Practice  Details Coming Soon

#2 - Saturday September 8, 15, and 22, Northbrook, IL

Anthony Mersino will deliver the PMI-ACP Agile Certification Training Course.  Results guaranteed!  If you don't pass the PMI-ACP exam on your first attempt you can take another course for free!  Register Now  More Information

#3 Wednesday September 26 - Friday September 28, Nashville, TN

Anthony Mersino will deliver the PMI-ACP Agile Certification Training Course.  Results guaranteed!  If you don't pass the PMI-ACP exam on your first attempt you can take another course for free!  Register Now  More Information

#4 - Thursday, October 23, Brookfield, WI

Applying Agile and Lean Principles to Everyday Projects, PMI Milwaukee Professional Development Day  More Information

Well, that is it for now.  We will return to our regular posting on Friday August 10.

Cheers!

Anthony

Agile Culture Change, Part 3

I nearly called this post, "So where do I book my time for this meeting?" because that is the type of question that frustrates me most, especially during early team formation.  This post on team formation is the third installment in my series of posts on Agile culture change.    

Most project managers have learned about Tuckman's stages of team development: forming, storming, norming and performing.  The idea is that new teams naturally move through the first 3 stages before they are able to start performing well as a team.

The challenge is, how do we get teams to the performing stage as quickly as possible?  Forming and storming, though necessary, can take some time, costs money, and it can be painful.  Our traditional PM training would say that team formation is the responsibility of the project manager.  And the main tool used by the project manager is the project kickoff meeting. 

We've probably all had the experience of an uninspiring project kickoff meeting.  The PM gets up and talks about how critical the project is, the business drivers for the project, the timeline, the sponsor, blah blah blah. We find it hard to buy into the mission, buy into the team, or even to buy into the PM as someone you might respect.

New team members often show up for these kickoff meetings with battle fatigue, as if they have heard it all before. They type away on their laptops, only half paying attention. They do seem to tune in just long enough to confirm that the deadlines are all in the distant future. "Great, nothing urgent here", they say to themselves. "I can continue to juggle two or three other projects in the background while I begin charging to this one."

Those new team members aren't going to get excited anytime soon. They don't know what their role is or how it relates to the overall project. "Hey, let's not kill it on our first day" they seem to say as they slouch back in their chairs.

The PM is usually doing her best to sell the project.  Focus on the WIIFM - that's what the training says.  Get the team excited about the mission.  Yawn.

The meeting ends and the individuals slump back to their cubes, put their headphones on, and go back to what they were doing before the interruption. 

After the meeting, the PM makes a mental note to plan some team building activities.   She has the monkey on her back to somehow form the team, energize them, and get them to commit to the project goals and deadlines. 

The problem is, at this point there is no sense of team, just a collection of individuals. There is no ownership or commitment.  Of course it is rare that the PMs get true team member commitments to the deadlines since they didn't have a hand in setting those deadlines.  All the responsibility for the outcomes is on the shoulder of the PM.  Forming the team has barely begun and performing feels like it is a long way off.

Agile Team Formation and the Agile JumpStart 

I am not going to suggest that it is a cakewalk when you start up an Agile Team. I will say that I have initiated over 20 Agile Teams in the last year. Most of these have been part of an Agile JumpStart process where I've trained the team on Agile Principles and then supported the team to plan out the project and prepare for their first iteration.  And that is where the fun begins.

The Agile JumpStart process takes a team through forming, storming, norming and sets them up to start performing.  That is not to say that each of these stages won't be revisited, but the team will have made significant progress.  The team learns about Agile Values and Principles, then spends some time discussing their project vision and team charter.  They work together to develop an elevator pitch for their project, a product box that represents their solution, and a team values statement.  Then they create a product backlog and they begin planning in detail their first 2 weeks of work.  They will do some exercises to better understand Scrum, flow, bottlenecks, and how to work together as a team.

It is usually in this JumpStart week when the team is doing their detailed planning that light bulbs start going off for people. Oh, I need to estimate and plan my work in detail for the next two weeks? And my work is going to be visible for everyone to see exactly what it is? And I need to talk to my team mates about all of our work so that everything gets done successfully in the iteration? And we need to agree on standards, and what constitutes "done" for our team?  And every day, I am going to tell my team what I accomplished, and what is left for me to work on?   Do you mean to say that the shroud of mystery and mystique about what I am going to do will be pulled back, ripped away, and torn to shreds? But I'm an artist!

This represents a big shift for many teams. No more going off to work in my own cube, isolated, with no deadlines in sight.   Agile team members have commitments due in the next two weeks.  Heck, most will have commitments due every day!   Agile team members publicly commit to the work that they are going to get done and they don't want to let their team down.   The commitments are public, the results are visible, and everyone on the team will know what they are. 

Many newly converted agile teams get excited about the visibility of the work and the transparency of the progress.  They appreciate seeing how everything fits together. They see the relationship between their own work and that of their teammates.   They recognize that as a team, they must work together to hit their team goals.

 

The funny thing about Agile Teams is that team formation and teambuilding becomes inseparable from solution building. That is, by working together every day to deliver solutions of value, the team is built. An agile team building activity is called 'doing our job' and 'delivering something useful that delights our customer'.   They may want or have some offsite meetings, happy hours, or other activities, but these events are less about team building and more about enjoying time with each other.

Soon the team is pushing to sit together, and becomes focused on activities that drive their velocity, or productivity higher.   They ask each other how they can help when they find themselves done with their activities for the iteration. The team is formed, stormed, normed and beginning to perform. 

I saw this recently on a team I was coaching.  The team was made up of new IT consultants, long-time vendor partners, and internal business team members.  At first no one really understood what needed to be done, and there was a lack of trust and cooperation between all team members.  Within a relatively short period of time, the team moved into one room and began working closely together.  There was knowledge sharing across the team and individual team members began offering their help.  It wasn't perfect, but the team was beginning to truly perform and deliver the solutions that the business needed. 

Bottom Line:  I am obviously an enthusiastic fan of Agile methods.  I do want to caution against viewing Agile as a silver bullet that is going to solve all problems.  In the case of team formation, I think it is an accelerator that moves the team into performing mode as quickly as possible.

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

Agile Culture Change - Part 1

I'm fascinated with the idea that Agile is a mindset and culture change rather than simply a process or tool change.  I saw this clearly at a recent client engagement, where I was engaged to co-lead the Agile enterprise tranformation.

This particular IT organization had previously experimented with Agile development though they were relatively immature in their adoption.  Moreover, the culture of the organization did not actually support an Agile mindset or approach.  The organization was very top down, command and control oriented with a very strong and non-Agile PMO (Program Management Office).  The organization also had a reward system that encouraged individual performance at the cost of the overall organization.  This led to some of the following dysfunctions which are not uncommon:

• Individual Heroics - People would look for or create ways to come in and save projects at the last minute.  This encouraged procrastination, and even the creation of problems that the individual could swoop in at the last minute and resolve.  Every project was unpredictable and risky, and every major project milestone was a nail-biter
• Taking Credit / Blaming others - Because of the high potential for individual rewards, there was a high incentive to be associated with successful projects, and disassociated from unsuccessful ones.  This led to some predictable but frankly weird behaviors.  Everyone was trying to get ON or ASSOCIATED WITH projects that looked like they might succeed, and OFF or DISASSOCIATED FROM projects that looked like they were going to fail.  There would be long lists of people 'assigned' to projects early on, or requesting to be included in all meetings and emails.  Most of these individuals were unwilling to show up, participate, or contribute to the success of the team.  Individuals were ready to bail from the team or disown any responsibility should the project get into trouble.  Most of these individuals were direct supervisors of the people on the team who would do the work.  At best they were chickens and at worst they were roosters.  This created some unwieldy team lists, impossible meeting schedules, seeds of failure, and ultimately teams lacking transparency or accountability for results.
• Micromanagement - Since teams were so big and everyone felt they had a stake in the success of the project, managers and direct supervisors would involve themselves unecessarily in the details of the project, second-guessing and overseeing the work of their subordinates.

These weird behaviors surfaced immediately when we worked with the first traditional team that we put through the Agile JumpStart process.  The first meeting with the 'team' included a large cross-functional IT group that did not include any business resources.  It wasn't readily apparent who from this group would actually be doing the work.  By our second meeting, we had reduced the participation to mostly the core Agile team.  We had delivered some training and were digging in on the user story backlog and iteration planning.  A manager who was too busy to show up for the training, showed up for the planning.  He immediately began questioning two of his team members about what they were doing and it created a negative mood in the room.  He was so disruptive with his beratement of the two team members, that the discussion ground to a halt and the team regressed. 

 

Observing the behavior, I asked the team to return to their planning activities and invited the manager to step out of the room to discuss his concerns.  He was visibly upset, and I made it a point initially to just listen to him.  While he couched his concners in terms of project risks, it was clear that this was about the impact that the Agile approach would have on him and his position in the organization.

Ultimately this manager feared loss of control and relevance.  He had placed himself in a position where he reviewed and approved every thought, idea and action his resources had.  It was to the point where the resources had been conditioned to let the manager think for them, rather than to think for themselves.  He stifled creativity, productivity, and progress. 

 

As if that were not enough, there was more.  This manager had established himself as the conduit for his resources to interface with the business and other IT resources.  He limited what his resources knew about the business needs and other IT teams, so that he personally could add that value.  He also requested that his resources keep him in the loop on everything.  In a particularly noteworthy example of waste, his resources spent time in meetings taking incredibly detailed notes of the conversation so that they could send them to the manager.  They didn't actually participate in the conversation, unless asked, they just kept typing away like court stenographers.  What a waste of time and effort!

 

There were other losses of productivity, as these two resources were essentially untapped.  Their creative potential was not being used, it was being held back by this manager.  We learned later that one of the two resources was scary smart and had attended a high school for gifted students!  What a waste of talent!

 

The resolution of this particular incident was to remove the manager from the team.  We explained the importance of having full time committed resources on the team and shielding them from interference.  We encouraged him to become a resource to the two team members when they needed him.  We invited him to the iteration demos (though not the retrospectives).    

 

 

The two team members literally blossomed.  They loved the interation with their team mates, and began, gradually, to lead with their expertise without checking back in with the boss.  They stopped taking the detailed notes to send up the chain.  And they came out of their shell and let their true personalities shine.

Shortly after, we found an opportunity for this particular manager to be a scrum master for a second team.  For a variety of reasons, that second team was shut down and not long after the manager decided to leave the company. 

 

Changing the culture of an organization is never easy, and often it is not pretty.  This particular case was one isolated story within the context of a broader culture change in an IT organization and their relationship with their business customers.  During the Agile Transformation I saw many people leave, voluntarily or involuntarily.  I also saw, as was the case with this particular example, the unleashing of the full potential of the team members.  The self-organizing Agile teams we created were being harnessed for the good of the organization.  We had clarity of who was on the team and responsible, as well as transparency of the team's progress and risks. That is pretty exciting stuff!

Anthony

Why Traditional Lessons Learned Are a Waste

I had a strong reaction to a Projects at Work article called Learn your Lessons.  This article by John D'Entremont, PMP, reminded me of some of the strong advantages that Agile Methods have over traditional project management.  I'd like to explore some of the reasons I disagree with Mr. D'Entremont and those Agile advantages here as they apply to project management lessons learned.  I'll also identify some of the Lean and Agile principles that support those advantages.

Where we Agree

Let me start by saying that I can agree with Mr. D'Entremont on the following points:

• That lessons learned play a fundamental role in sustaining project success. 
• If you don't learn from your projects, your growth will stagnant or you will actually backslide.

That said, I fundamentally disagree with John on the following points. 

Where we Disagree

First, I disagree with John's insistence on having a disciplined approach to gathering lessons learned.  In my experience, gathering lessons learned is rarely the challenge.  The challenge is doing anything useful with the information.   I don't believe that you should waste the time and effort on "gathering" if you don't have a process for using them.  

The shortcoming here is that John doesn't actually advocating doing anything useful with the information.  Which relates to one of my favorite Agile principles.

"Simplicity - the art of maximizing work not done - is essential."

We should not do any work that doesn't need to be done.  We should not spend the time collecting lessons learned if we don't have a systematic way to incorporate them, leverage them, or make them part of the team or organization's collective knowledge. 

The creation of an interim work product, which doesn't link clearly to some use, is a form of waste in Lean terms.  Producing a lessons learned write-up that doesn't have an immediate purpose is incomplete work - waste.  It will be a task later for someone to retrieve, dust off, analyze, and determine a way to use this interim work product.  And like other types of inventory, incomplete work that remains unconsumed gets stale and spoils.

I know that many of you are thinking, we do have a plan for how we will use our collection of lessons learned.  I've heard a lot of approaches to this, and tried many myself, and I just don't think that any of them are good:

• Posting it to SharePoint/on the shared drive/team Wiki/Confluence/Lotus Notes doesn't work.  Posting things in Sharepoint is the rough equivalent of printing it, boxing it up, and sending it to Iron Mountain for storage.  Hey, why not send it to the microfilm or microfiche department!  (See rant below for more on Sharepoint). 
• Emailing your colleagues doesn't work either.  They are busy and frankly they don't have time or interest in your lessons learned; they won't even bother to open the email let alone open your elegantly formatted attachment.  Plus, their .NET development project is completely different than your failed SAP or mobile apps project.
• Sharing them at the next department or information sharing meeting doesn't work. Yawn.  Nobody cares - see previous point.
• "Hey, let's start off all new projects with a review of the learnings from all the recent department projects."  This sounds like a promising idea but, like, is this really going to happen?  Many new project teams are behind before they start and are often discouraged from planning so they can get right to the work.  How many of them are going to pause, go back and find all the lessons learned, determine what applies, and start with that?

RANT - One phrase I hear that drives me bonkers is "It's posted in SharePoint!". DON'T BE CRAZY, EVERYTHING IS POSTED IN SHAREPOINT! I think it is safe to say that all of the information in WikiPedia is dwarfed by the information that is in SharePoint. The question is, is the information retrievable when I need it? Will I get the correct version? Do I know where to locate it when I need it? Do I have permission to access it? Is the time spent searching for the right information worth it in terms of return? Stop with the SharePoint comments already, nobody goes there to find ANY organizational learning, let alone your lessons learned from the failed SAP implementation."

Second, I don't agree with the approach to tie lessons learned to the end of project lifecycle phases.  If you only perform initiation or planning once per project, why bother to do a post-mortem after the phase?  It's not going to help that project. 

Chances are, your lessons learned aren't going to help the next project either because the next project will be different in some way.  You aren't going to implement SAP again at your company.  (Unless you are SAP Consulting and even then, I think the track record for applying lessons learned on SAP Implementations speaks for itself.)  The definition of project includes the word "unique" for a reason - project are fundamentally different!

There is an excellent white paper on the Papercut PM which demonstrates this point very well.  "This is why we can't have nice things: A Project Risk Retrospective", talks about the 1st and 2nd projects to build the Panama Canal.  The first unsuccessful initiative was led by experienced French construction lead Ferdinand De Lesseps.  De Lesseps had the benefit of successfully completing the Suez Canal project.  The second Panama Canal project was led by US General George Goethals.  Goethals had the lessons learned from the prior French-led project.  The lessons learned were valuable precisely because they were from nearly the same project, not a similar one!

"De Lesseps had no idea of what awaited him in Panama. While he had previously built the Suez Canal, the geographical environment at the Egyptian work site was flat and dry with marvelous visibility. The Panamanian rainforest was the exact opposite—much of De Lesseps’ previous work in Egypt proved irrelevant in tropical conditions. Goethals, on the other hand, had the benefit of the previous French failure. All of the lessons of “what not to do” were littered across the Central American countryside for anyone who wanted to look. Goethals should rightly be praised for seeking this information, but had this analogue input to his plans been absent, his results may have been very different."

The corresponding Agile principle is below.

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

In our weeklong Agile JumpStart training sessions, we teach teams to pause, to reflect on what works well, what doesn't work so well, and then use that to make change.  It is a structured part of the SCRUM framework and it happens at the end of every iteration.  The beauty of this approach is that you can immediately incorporate what you learned. 

The iterative nature of Agile projects also helps.  Work is structured to take a small component of development and go all the way from requirement to working solution within a short timebox, usually a week or two.  Agile projects don't do analysis or design just once, they iterate again and again.  When you do the same cycle over and over on a continuous basis, you can systematically determine lessons learned, apply changes and monitor the results.  It is like an experiment where you change one control each cycle and monitor the results. 

Third, I also disagree with the idea of the team members individually suggesting lessons learned at the end of a lifecycle phase because it can easily lead to the wrong attribution of cause and effect. Each person on the team may have a different perception of why things were late, risky, or incomplete.  Just like the old story of the people in the dark room describing the elephant that they feel, one persons perspective on the cause of a particular item may be completely opposite another's.

We teach our agile teams that they need to be communicating, collaborating and sharing what is working and what is not on a regular basis.  It is discussed, debated even, and it becomes part of the teams shared journey and collective memory.

Role of the Agile PMO

Many of you may be wondering what role the PMOs play in the lessons learned process.  A previous Projects at Work article with a similar title "Learn Your Lesson" advocates the creation of a full-time knowledge management coordinator inside the PMO.  I do not agree with this top-heavy approach because it would be a difficult job to do well, and it would be an easy target for cost-cutting.

I think the PMOs role in Lessons Learned is to make sure the teams are conducting retrospectives on a frequent and regular basis and incorporating the lessons learned into their planning.  If the teams are following Scrum, the PMO should just check to make sure they are doing what they say through quality assurance reviews.  The Agile PMO should be monitoring all the teams - not to collect their lessons learned - but to make sure that the team's are all doing Agile in a similar way and have not lost their discipline, even though they are self-organizing.

Your thoughts?

Anthony 

 

My Company has gone Agile, Now What?

I am currently working with a couple of new agile teams and coaching several scrum masters who were previously working in traditional software development methods.  It has brought into clear focus some of the challenges and emotions that traditional (e.g. waterfall) project managers have when adopting agile methods. 

The single best resource I have found for coaching these new scrum masters is Lyssa Adkins great book, Coaching Agile Teams.  In every case where the new agile team leader is struggling, I find that Lyssa's coaching and her words are helpful.  Almost Zenlike!

One of the first things that I notice about new project managers is the fear they feel about adopting agile.  There is fear because many of the traits and characteristics that were valuable as a traditional PM or BA are not longer as important for scrum masters.  There is fear because Agile requires servant leadership, whatever that is.  And I think there is fear that if they do the job of being a scrum master or agile project manager, they won't add value in the way they used to, and somehow they won't be valued or  needed.

My colleague and fellow blogger Tom Cagley claims that project managers cannot be scrum masters.  While initially I didn't like the idea (perhaps because I've been a project manager a long time??), I am beginning to understand why he feels that way.  Traditional project managers have learned how to be successful for specific behaviors and efforts, and these are no longer as important, and can be counterproductive in agile teams.   Let's look at 4 very different styles of scrum master and the behaviors that each of them will have to unlearn to be successful.

Example #1 - The Command and Control Scrum Master

My first example is a long term project manager who was PMP certified.  She was accustomed to directing and controlling the work of the team and felt wholly responsible for the outcomes of the team.  Perhaps I should say that she had the illusion of directing and controlling the work of the team because I wonder if she was actually.  If she had a MS Project schedule broken down to the hour, does that mean the project is in control?  Rarely.  She spent a lot of time trying to figure out why things were not going according to her detailed plan and then trying to bring the team performance in line with the plan.

Her command and control style of leadership resulted in her feeling all the deadline pressure for the team.  She literally felt that the success or failure of the team was on her shoulders. One of my favorite Agile authors, Lyssa Adkins, says we need to give this energy back to the team. In her book, Coaching Agile Teams, she says to let the team feel the pressure, and the thrill of figuring things out for themselves.

Example #2 - The Chicken Little Scrum Master

A second example is a new scrum master who was formerly a technical lead.  Early in their second iteration as an agile team, he became concerned about the growing bubble of work that would need to be completed before the end of the two-week iteration.  He saw a big looming problem.  Either the team would have to complete all the work in the last few days of the iteration (which was not sustainable) or the team would miss their iteration goals.   

His intent was in the right place.  The challenge was, similar to the previous PM, he was feeling all the energy for the team.  He was also looking ahead and trying to protect them from what might happen.  Adkins' coaching would be to let the team have the experience, then see if they learn and adapt from it.  While the leader or coach can point things out, it is the team's decision to adjust their working habits. 

Adkins has an excellent quote from Chris Corrigan's book, The Tao of Holding Space.  She goes on to say that even the team's bumbling is better than your perfect plan. 

"Everything you do for the group is one less thing they know they can do for themselves."
- Chris Corrigan

Even more radical is this advice from Adkins:

"Let the team fail:  Certainly, don't stand idly by while the team goes careening off a cliff.  But do use the dozens of opportunities that arise each sprint to let them fail.  Teams that fail together and recover are much stronger and faster than ones that are protected.  And the team may surprise you.  The thing you thought was going to harm them may actually work for them.  Watch and wait."
- Lyssa Adkins

This idea that the team is capable of handling problems relates to a concept that I have learned in my emotional intelligence training - positive regard. This ties back to the work of psychologist Carl Rogers, who believes that each individual has the internal resources required for personal growth and development.

How does apply to leading agile teams? The idea is, to believe that the team members individually and the team as a whole is capable of figuring out what is required, and adapting and growing.  This is one of the 12 agile principles.

"The best architectures, requirements, and designs emerge from self-organizing teams."
- Agile Principle

Example #3 - The Know-it-All Scrum Master

Another behavior that I have seen in a new scrum master is the need to add value by being the most knowledgeable person on the team.  This scrum master was formerly in a business analyst role and a big part of the value that they brought to their BA role was knowing everything about the business context.  Was that helpful in the agile team?

Of course understanding the business is going to help the agile team. The challenge was, this scrum master had previously been valued by bringing the business knowledge to the team.  In their role as scrum master, they need to encourage everyone on the team to become business experts.  They need to take a step back and let the team figure things out.

Example #4 - The 'All Roads go Through Me' Scrum Master

In another example of a new scrum master, this individual would have daily meetings and standups with every member of the team.  They would all update him, and he became the central hub of all information.  This behavior grew out of a desire to avoid surprises and to stay on top of the team.  The question is, was this behavior helpful as he transitioned from traditional development to agile?

As you've likely guessed, the behavior was not helpful at all.  While he knew everything going on, he became the only one who did.   He was the single person that has the complete view of the solution. His team members interfaced directly with him, and he controlled all the communications.  Team members were not accustomed to thinking and acting like a team - they acted like individuals.  They did not communicate to each other or coordinate their efforts as a team. 

A more healthy behavior would be to get out of the middle of the process.  He should facilitate a standup meeting where me makes sure that the team is communicating to each other.  He should take a step backward and let the team begin to self-organize and coordinate their efforts.  Lyssa Adkins frequently recommends that the one of the most important things that the agile team leader can do is shut up.

"Let there be silence:  Get comfortable with uncomfortable silence.  Do not fill it yourself.  Let someone else on the team have room to speak.  They will."
- Lyssa Adkins

What Next?

If you are a traditional PM thinking about or in the midst of making the transition to Agile methods, these approaches may feel too loose, or almost zenlike.  They may feel like a form of Jedi mind trick that is difficult for mere mortals to master.

Take heart.  These Jedi tricks can be learned and mastered.  A great start is Lyssa Adkin's book.

Cheers!

Anthony