6 Ways Leaders Avoid Becoming Roadblocks

Whether you’ve been managing for a long time, you have a new team or are a new manager; include your own positive and negative contributions to the team when you evaluate the team’s overall success. There could be times where it’s you that may keep the team from growing.  You could be out of touch with the team, maybe you’re still using traditional methods that are no longer reaping the same results, or perhaps the pressure from senior leadership is driving your decisions in a different direction than where the team is going.  Whatever the reason, take some time to try some of the idea s below.

Rely on Experts
A very wise man once told me that he always surrounded himself with people that were smarter than he was.  At first pass, you may agree, but he was an expert too.  Remember that as a manager you are there to lead, motivate, mentor and, when necessary, even discipline.  The people on your team are there because of their expertise and every day that you rely on them to bring their very best to the rest of the team you allow them to make good decisions based on their expertise. Challenge them to grow further and then step back so they believe they are trusted experts.

Sit in the Pit
The best way to understand what motivates and runs a team is to take time regularly to be around them.  All too often, I see managers move further and further away from their teams for the office with the nice view and the big door.  You’ll be missing out on an abundance of non-verbal and verbal information that could help you understand how to manage the team and who might need the most guidance.  Anytime the source of truth is further than the mouth that speaks it, surely the message will be old, inaccurate or both.  (This is a great paragraph, it really reads so well.)
Publicly Praise the Team
It’s nice to hear when you’re doing a great job so think about the last time you praised your team.  If it’s sincere they will know and appreciate it.  If it’s not, they’ll see right through it. If you don’t know what to praise them about, it’s possible that their goals are not clear or maybe your expectations are too high. Sit down and consider what the team could do that you would consider praiseworthy and then share it with them.

Raise Individual Concerns Privately
It’s difficult to hear constructive advice and it’s just as hard to deliver it.  To build and retain trust within a team, corrections should be done privately, courageously, and with respect.  Use examples of what initiated the need to discuss it and offer a suggestion on what could have been done instead.  Doing this privately shields the rest of the team from unnecessary stress, defensiveness and confusion that may be uncovered while you work directly with the people that most need the help.

Allow the Team to Fail
We are told as children not to fear failure; it is part of learning and we should persevere with the courage to try.  Lanette Creamer, a writer and speaker, says, “If failure is not an option it is guaranteed.”  When teams are given the security to fail and still keep the respect of their manager and peers, they will keep trying.

Manage Up
Everyone has a responsibility to someone in the corporate ladder, so consider that while you are trying your best to stay out of the way while providing clear direction and support. Your boss may need the same advice. If you are having difficulty, allow the team to evolve and grow because of influences above you. Take the time to smooth the path for the teams by smoothing the path between you and your manager.

These are simple pointers to help you stay engaged with the current state of your team and how to encourage progress..Encourage your peers and leaders to consider these ideas and pass them along.  When we have better leaders, we have a better chance of having great teams. If you have other ideas, I would love to hear them!


Common Agile Practices That Sabotage Us

Sometimes we need help to improve our team and sharing insights into why some practices and behaviors can sabotage team progress.  Take a look at the following observations teams have made to see if your team can identify with them and take action before it becomes a bigger or longer term problem.


We have a lot of stories that are closed by DEV and then new stories for QA testing are created to test what Dev hands over.

Impact to the Team:

  • Because the number of stories in the sprint steadily increase during the sprint, the burndown chart will likely look like the team is always behind schedule.
  • Individual capacity is extremely difficult to plan during sprint planning because the number of stories at the beginning of the sprint will be lower than reality.
  • Forecasting sprint plans and project schedules via velocity is useless here because the team velocity is not consistent each sprint.
  • Without the ability to forecast with solid data to prove the estimates are achievable, the team’s commitments aren’t reliable so the confidence of schedule estimates will be low or non-existent.

Options to improve:

  • Create a user story by including the user scenarios to help clarify the expected outcome and user experience of the story. This not only helps QA kick start the test automation earlier in the process but also helps Dev to understand how the feature will be used in different situations and they tend to have lower bug counts.
  • Keep a user story open until it has cleared QA.  A user story is NOT DONE if it hasn’t been tested and accepted by the Product Owner.
  • When logging bugs against a user story, keep the bugs as close to the story as possible. If your tool allows you to add the broken test cases inside the story, do that. Everyone should be able to quickly see which stories are not done and why.

Observation: We can’t seem to get our user stories done in a single sprint so we have the same story in several sprints.

Impact to the Team:

  • Because the feature that is represented in the user story is not done for several sprints, the team’s work cannot be “potentially shippable” at the end of each sprint.
  • Because the user story is not uniquely defined each sprint, it may not be clear to everyone what is expected to be done by the end of each sprint.
  • The work for the user story keeps “sliding” to the next sprint and it’s unclear whether the feature is on track to be completed by the last user story that was extended.

Options to improve:

  • When reviewing a user story during sprint planning, identify stories that are too large to get all of the work done; that means development as well as cleared by QA. Break up those stories into more than one by grouping a set of user scenarios that CAN be done in a single sprint and “rebranding” the user story to reflect those scenarios so that when you look at each story, it’s clear what will be delivered in each new story. They should be uniquely identified.
  • Remember that at the end of any sprint, the Product Owner should always have the option to request all stories that are DONE be “shipped to production.”  If your team cannot do that, then the user stories weren’t really “DONE” in the sprint(s).

Observation: We have people that are on more than one agile team.

Impact to the Team:

  • Team members that are on more than one team become less efficient because they are attending multiple sprint planning sessions, daily stand ups and working sessions.
  • Individual capacity planning is more difficult because the team member must be consistent in the time that they commit to each team so that they are able to commit to their work and keep each team’s velocity consistent.  For example, I am on 2 teams and I will consistently commit my time 50/50 between them so that team velocity and my individual capacity is reliable and consistent.
  • Scheduling sprint planning and daily stand ups become more difficult to schedule because of team members that have more than one to attend.

Options to improve:

  • This situation should be temporary.  There should be a transition plan in place so that teams have the ability to continue taking on new work and their velocity can stabilize and continue to improve.
  • If people have a unique skill set and transitioning is not an option within a few months, determine which agile team has the most work for that skill set and put them on that team.  Any new work that requires that skill set is assigned to their team, becomes part of their velocity and capacity planning metrics.
  • Ensure that when new projects requiring that person’s unique skill set come up, they are invited to the release planning and the user stories are appropriately written and part of that team’s sprint planning.

Observation: We have people that get moved from one agile team to another throughout the year based on projects that come up.

Impact to the Team:

  • Team velocity is useless because the aggregated capacity is not constant and each team’s velocity cannot stabilize.
  • Individual capacity planning is more difficult because the team member must be consistent in the time that they commit to each team so that they are able to commit to their work and keep each team’s velocity consistent. For example, I am on 2 teams and I will consistently commit my time 50/50 between them so that team velocity and my individual capacity is reliable and consistent.
  • Scheduling sprint planning and daily stand ups become more difficult to schedule because of team members that have more than one to attend.
  • Forecasting sprint plans and project schedules via velocity is useless here because the team velocity is not consistent each sprint.
  • Without the ability to forecast with solid data to prove the estimates are achievable, the team’s commitments aren’t reliable so the confidence of schedule estimates will be low or non-existent.

Options to improve:

  • Consider that teams that are able to stay together over time become more efficient as they learn to work together, improve together and their individual skills increase.
  • When building an agile team, ensure that the type of people and their skill set is appropriate for the backlog of work they will receive.  A healthy balance of development, testing and operations on a single agile team is key.
  • Rather than sending people to projects, keep the same people on the same teams and send the appropriate project work to the team.  This is where Release Planning for a project will ensure that each team identifies which user stories from the project are “theirs.”

What options do we have to integrate a UX/UI team into our Scrum process?

Although this question doesn’t come up all the time, it certainly comes up enough that sharing how our team made the decision to keep the Design team work outside our scrum team’s sprint could be helpful to others.
Just to give you some background, this team has been focusing on the intake of new projects, how we define new projects and what information is needed to ensure we make good business decisions in the future.  And, since this post references some processes in a previous post, you may want further clarification, so check it out here.
Our team has had many organizational changes over the years so we decided to take time to evaluate our agile practice and our teams to see how they were doing.  During our reviews, we heard that our design team wanted to understand how they would participate in our scrum practice and previous attempts weren’t going well.  So, to keep our discussion simple and make a decision quickly, we had leads from Product, Design and Tech review two options that we could use to plan and execute with consideration for how design/UI/UX is integrated into the process we continue to evolve.  Take a look and come prepared with your input on which option you believe works the best for your team.
Each option assumes…
…for each new project that is approved and moves to the “COMMITTED” status, we will have release planning with all teams invited (product, design, tech, ops, etc.) before we begin so that everyone understands the goal of each release (if there is more than one per project) and what high level features are being requested.  
…at the end of the release planning session, each team comes up with their estimated schedule to complete the project and each release/milestone along the way. This is the way we create the CPE (Concept Phase Estimate) and projected completion date and the project moves to the “READY” status in our Intake workflow.
Red text represent the variance between options
Option 1 = Design iterations of a user story are done prior to team sprint planning
  1. Features and scope from the approved project are prioritized within each release by the Product Owner
  2. The first set of features (highest priority) are broken down into user stories by the Product Owner focusing on the “what” and “why” but not the “how”
  3. First set of User Stories are presented to the Design team that will be part of the next engineering sprint planning session
  4. Iterate with Design until each user story from the first set is ready with all required information for engineering to begin
  5. Product Owner presents the user stories along with lead Designer at the engineering sprint planning session
  6. Sprint commitments are made on which stories engineering can complete in the sprint
  7. Product and Design are available to the scrum team for questions and tweaks to the design during the sprint
  8. Design and Product continue to work on the next set of user stories during this sprint that will be presented at the next engineering sprint planning session
  9. Product Demo is held the last day of each sprint to demonstrate each completed story and gain Product Owner acceptance
Option 2 = Design and Dev of a user story is done in same sprint
  1. Features and scope from the approved project are prioritized within each release by the Product Owner
  2. The first set of features (highest priority) are broken down into user stories by the Product Owner focusing on the “what” and “why” but not the “how”
  3. First set of User Stories are presented to the Design team and the Tech at the same time during the sprint planning session
  4. Sprint commitments are made on which stories Design and engineering can complete in the sprint
  5. Product and Design are available to the scrum team for questions and tweaks to the design during the sprint
  6. Design and Dev are done in parallel on the same stories during the sprint
  7. Product Demo is held the last day of each sprint to demonstrate each completed story and gain Product Owner acceptance

Early in the discussion, most people were already on board with Option 1 but we continued to discuss examples so that we all understood how it would play out in the day to day ceremonies that our teams already had such as Release Planning, Sprint Planning and daily stand ups.  We agreed that leads from Product and Design would continue to attend the sprint planning and daily stand ups as needed by the team.

Agile Ceremonies

NOTE: Since this post references project workflow and you may want further clarification, check out my other post regarding project workflow here.
Please take a look at the summary below which explains the type of meetings and practices throughout the lifecycle of our projects that we’ll be focusing on improving and adjusting as we grow as an agile organization.  Remember that every team and organization customizes things to match how they work so this is not meant to be prescriptive. Use it as a guide and go from there with your team.SAM_1313

Yes, We’re Agile but we still Plan, right?

Yes, of course you still need to plan – even when following some type of agile method. It still amazes me that so many organizations stop doing this. Some don’t it because they believe that agile means no planning and some don’t it because … well, there are so many other reasons. Is it really worth repeating?  Maybe I’ll do another post about that, but for now, let’s look at one team established an intake process for new projects and made it simple yet effective.

000 Blog Agile Topic Photos - 10


Before our teams begin working on new projects, we need a way of ensuring that there’s a solid business case to do it and a clearly defined scope of features or benefits.  Sounds like planning right? Well, you could say that but, actually it’s before we even start really planning; we’re evaluating, we’re justifying, we’re using the ROI (Return on Investment) model to ensure we are pursuing the right project in the right order (priority).

Let’s look at the scrum model for a moment.  Each sprint starts with a fully formed group of user stories in the backlog that are “ready” for the team to start working on them right?  Well, how do you know that those stories are really the right ones to pick up next?   We started by tracking backwards from the backlog to build a process the supported how we were working and kept us in an iterative learning state of mind.  The image here shows the process or workflow that we are using.

The Product Owner is constantly evaluating current progress against the backlog of new ideas.  Once they have something to present, they prepare a proposal that includes key data points of their research and ideas in the form of business justification and benefits to the company and our consumers. We ask for 1-3 sentences describing the end result of the project.  It should address questions like “Why are we doing this?”, “What is current problem statement or potential improvement and what is the expected outcome at the end of this project?”  Along with this justification, we also ask the Product Owner to detail the benefits to the company and/or our consumers by providing either target or concrete goals for the project that fall into categories like Cost Reduction, Revenue Generation, UV Lift, PV Lift, Brand Lift or Efficiency Gain.

This provides everyone reviewing the proposal a clear understanding of the why they may want to approve the project to be approved and funded.


If a proposal is approved, it is moved to a “Committed” state where the teams involved do a release planning session so that all the impacted teams (internal and external) are able to evaluate the size of the work and the interdependencies between team as well as other projects that my have higher priority to agree on a projected start date, completion date and estimated cost.  Those data points are provided back to the approvers to ensure that the ROI is still positive.  If everything still looks good, we move the project to “Ready” and each team picks up user stories from the Product Owner for their sprint planning sessions.

Not every project begins immediately after the release planning is completed but we try not to allow too much time between the session and the project actually starting.  There are cases where a proposal is approved but it’s low enough on the project priority that it could be months before we are able to start working on it so we delay the release planning to be closer to the start date. We move the project to “In Flight” once work begins and place it in “Deferred” status when and if the project is put on hold.

Notice that even after a project is moved to “Complete” it’s not all the way through the project workflow.  This was an important step in  iterative learning and decision making that we added after a few months running the projects through the workflow.

Some of our project leads were reporting that even when the final production installation was completed, the benefits that were expected from the project would not be true until several weeks or months afterwards.  And no one was going back to evaluate the results of the completed projects to verify that the benefits had actually been achieved and to what degree.  That was the beginning of our Project Retrospectives.

If you think about how Scrum teams do team retrospectives to determine what changes were working and which ones weren’t it makes total sense that as a business, you’d want to do the same with projects.  Every month, we began retrospecting about each project that was completed in the prior month.  The team members were encouraged to present the results and we started to see improvements in several areas not just in the new project submissions but also in the cross pollination of product knowledge across the organization that did not have a venue in the past.  People were curious about why we were doing certain projects and now they had a space to hear the results, see the bigger picture and feel how each of them were part of the overall goals.

Once we completed the retrospective for a project, we move it to “Benefits Realized” adding the results so that we can reference it in future project proposals. Here is a template that was used for each project retrospective.  Note that our company uses the capitalization accounting practice so it’s also evaluated.Image

Agility is about the ability to react quickly when necessary and appropriate.  So yes, we plan and we are still Agile.  We use the intake workflow to keep us in the cycle of learning and adapting.  We’ll likely make adjustments as we evolve as a team but for now, this is reminding us to keep watching if we’re going in the right direction and allow the agility of the teams to respond as we learn and adjust our business roadmap.

No Scrum Master? Is it still Scrum?

What happens when the team gets all the training about Scrum, begins to kickoff the process but they don’t have a Scrum Master?

There are arguments (some legitimate and some not) to justify why Scrum will work without a Scrum Master. First, let me say that a Scrum Master is a role not a title so there really shouldn’t be any restrictions on who can fulfill the role.  Second, someone should take on the role and really dedicate time and energy to give the team the support they deserve. Check out Mike Cohn’s blog about Rotating the Scrum Master Role.

SAM_2306So what work does a Scrum Master do that now needs to be covered by someone else or the team as needed?  There have been a number of response to this question all over the internet and books so you’ve all probably heard that standard answers of remove impediments, champion the process, shields the team from outside interferences, etc. but I’d like to take it a step forward or maybe sideways.

Scrum Masters are champions for the team, their decisions, their delivery and even their failures. They are constantly looking at how the team operates from both an internal and external lens; one that the team members are very rarely able to use because they are in the thick of things and may not have the objective eye.  When a Scrum Master is able to identify things that are impeding the team and help them discover it rather than point a finger, jump up and down and demand they fix it, a bond is developed between the team members that gives them the confidence and trust that someone is looking out for them and is there to help them achieve their next level of expertise.

Eventually, a Scrum Master should find that the team needs their guidance less and less over time.  There are a few exceptions to that.  Teams that are dispersed  teams that gain new team members, teams that experience growth and then split (scaling scrum) will need more time and attention from their Scrum Master during these times.  They may have been experts at their process and become self managing but anytime the dynamic changes, there will be more to talk about, more to decide on and generally shakes the team for a time.

Another thing to note is that Scrum Masters are not Project Managers or even Tech Managers in their primary role.  There is a tendency to do this and it’s a dangerous thing because it can taint decisions and imply a level of power and control that should be absent from a Scrum Master.  Members of a scrum team should continue to rely on their managers and peers to improve their level of skill and professional growth whereas a Scrum Master may notice and relay recommendations about team members to their manager as a way of keeping the health of the team and growth of the team moving in a positive direction.

Hope this helps some of you!

Enterprise Agile Rollout at AOL

Experience Report Published on PMI Agile Community of Practice Newsletter February 2012: Enterprise Agile Rollout at AOL

This report is a reflection of how AOL identified a need to change development methodologies and grow team creativity and ownership.  The company reinvested in agile training and support over the past twelve months with the goal of a complete paradigm shift for the technology arm.  This report below points out some critical decisions, adaptations, and the responsiveness to change during the rollout of Agile through training and coaching.


An effort had been made in recent years to move to Agile but did not consistently receive the support necessary to embrace and sustain it.  In late 2010, there were two major agile tools in use globally across AOL.  A consolidation of agile tools was made in late 2010 to cut costs and to begin to centralize the company backlog.    Many teams had been trained in Scrum over the years so during the early planning stages of the transition, it was assumed the tool switch would be simple and quick.  Tool training sessions were held and it was during this time we discovered how many teams still needed basic agile concepts, tool use, team alignment and training.

In February of 2011, I took on a Program Director role to evaluate training needs, manage the training vendor relationship, implement and manage our corporate agile tooling system, build an internal agile community of agile experts, monitor progress and make recommendations to the CTO and his technical cabinet.  I managed this function with the addition of two people on my team, both with strong project management experience but neither considered themselves to be agile experts when they started on the program.  With this small team, we took on three major challenges. First, we needed to figure out how many teams needed training whether they knew it or not (hint hint). Second, we had to figure out how to handle the requests for tool training for teams that did not have a clear understanding of what agile really was.  And lastly, we needed to do all of this as cost effectively as possible so we could reach over 1,500 people across Technologies and our business organization within our approved and assigned budget.

We made a few assumptions in the beginning.  Training would be team-based so that we weren’t simply teaching people about a new set of techniques and tools but rather helping teams to start thinking and behaving in agile ways and provide a baseline to begin their journey as a team that we would revisit at key intervals to monitor their progress.  We selected Scrum and Kanban as the two standard styles of agile courses.  Teams that were not already in our standard agile tool would wait until after they completed their agile training before we would train them in the tool.  This rollout would be tracked through a standard agility survey at three different points in our rollout: a baseline in March, a six-month check and a twelve-month final survey. My team’s goal was to ensure that the rollout was not simply “complete” after we trained everyone; we needed to find a way to sustain the investment past the classroom and continue to see improvements.

Please do visit the PMI Agile Community of Practice site http://agile.vc.pmi.org to raise questions and discuss this report.

Getting Organized

To begin, we created a roster of all the teams in the company and began estimating how many Scrum and Kanban classes we’d have to schedule. This was a challenge that even HR could not have solved for us.

 When we talk about “Teams” in agile it’s usually related to either a Scrum team of 5-9 people or a Kanban team of up to 35 people.  These teams should be set up independent of organizational lines so that they are fully functional teams and can remain together despite changes in reporting structure.  However, as we began to pull our rosters together, we would get Scrum Team rosters of over 40 people or sometimes only 2 people.  Based on this discovery, we spent time working with managers, development teams, business leaders and product owners to help them understand the difference between an agile team and an org chart team.  This helped us define the correct team sizing, establish a management view of how their teams would be working together during the training as well as after the training and determine the number of classes that would be necessary to consider our classroom training phase complete.

Setting a Standard

Having already started down the agile path over the years, the popularity of Scrum still had a strong influence.  However, Kanban was getting some interest in one of our larger consumer product areas so we decided to offer training in either Scrum or Kanban as our two standard agile practices.  We made sure to educate people about the differences, the pros and cons before teams made their decision on which practice to use.

Figure 1: What AOL thought they were doing

While there are many different thoughts on how to choose between the two styles, we tried our best to stay agnostic and allow the teams to make the choice.  In most cases, teams that felt they had a mature and seasoned group of teammates and needed little to no guidance chose Kanban.  Teams that chose Scrum based it either on prior knowledge or their opinion that heavily date driven work would work best in Scrum to keep them focused on delivery dates.  Understand that while some agilists would try very hard to dispel myths and correct false assumptions spending valuable cycles debating with teams, we felt it would support our efforts to drive the self-management culture by allowing teams to make these decisions for themselves rather than dictate them or have management decide for them.

I’m pleased to share that overall, this was successful even when some teams stumbled along following their own path.  The Classic Mail and Phoenix Mail teams started with Kanban and after about three months choose the go back to Scrum.  We also learned to be a more flexible rather than push the purist approach to Scrum and Kanban.  Many of us in the agile community with strong opinions and valid experience have a difficult time with this lax attitude but it was a lesson learned that when working with such a large globally operated company, there is no cookie cutter way to gain trust and adoption from the very teams you work with.

We began using the phrase agile with a small “a” rather than agile with a capital “a” so that people would understand we were trying to adjust our approach and recognized personalization of a team’s agile practice was indeed very personal and should be honored during conversations, coaching and formal training courses and we continue to support this approach today.

Agile Tool Solution

Several teams were eager to jump into our standard agile tool even though they were not practicing Scrum or Kanban specifically. For example, some teams believed they were a Scrum team but their sprints lasted months instead of weeks, their sprints weren’t all the same length and they often had a single team working on more than one sprint at a time.  All of these were red flags to investigate further into what the teams were doing, why the made those decisions, confirm some of their terminology, and determine the next step to help them, not to bulldoze in and “correct” them.   Despite our advice, some teams plowed forward with the tool only to become frustrated once they realized what they were practicing may have been agile but wasn’t necessarily Scrum and was difficult to adopt our tool. There were some teams that slowly abandoned the tool all together or left the project managers to do all the entries and monitoring in the tool.

I must note here that the tool we used was heavily Scrum bound so for Kanban teams, it required a bit of customization and workarounds which, for a new agile team, was a big distraction from focusing on getting work done and learning a new way of working together. To minimize this, each team was encouraged to continue using the physical board from their training (Scrum Story Boards and Kanban Boards) and move it into their work area for a few cycles or sprints.  While the team used the boards to reflect their work in progress and plans, the Scrum Master, Kanban Leads or Project Managers would set up the tool mimicking the progress in the tool.  This allowed some time for the leads to become proficient in the tool, make adjustments to the set up and allow the team to gain confidence in their agile practice before launching the full team into the tool.  Teams that followed that path, seem to have had less frustration with their agile practice and they recommend it to other new teams.

Agility Surveys

Fortunately, our rollout was not given a hard deadline but we did have a set budget that we estimated would last about 10-12 months.  Knowing that large change efforts of any kind take time, momentum, adoption and support; we created an online survey based on a template provided by our training vendor and gathered a baseline response from everyone in the company willing to offer their input.  The agility survey contained questions to determine each person’s perspective about how things were going in these categories: Product Ownership, Release Planning & Tracking, Testing Practices, Planning & Tracking, Development and the Agile Team.

The results of the baseline from March 2011 were shared with the agile trainers to provide awareness on potential training opportunities and the leadership team of each organization to reinforce the need for the investment in training and coaching.  In November 2011, teams took the survey once again and the results showed between 8% and 14% improvement over the baseline.  It was useful to see where people believed they were taking a step backwards and where they were leaping forward.

We presented the survey as

  • a pulse of how people believe their teams are doing
  • a snapshot of changes over time
  • an indicator of positive and negative impacts
  •  only a sample of people willing to provide their feedback

and most importantly

  • a conversation starter.

The survey was NOT

  • equal to product success
  • enough information on its own
  • finished

We still need to dig deeper through conversations around these results.  While it does not always equal revenue and product success; it can help.  We accepted that it would show purely the perception that our teams had on where they were at a point in time during the rollout.  We also hoped we could supplement further evaluations such as coaching observation, Product and team level metrics to make correlations between them and the agility survey.  Our next survey will be in March 2012 and we look forward to seeing steady improvements.

Ensuring Long Term Sustainment

It was apparent very early in our rollout that a three person rollout team was not enough to support a large scale rollout.  We were not so ignorant to think we could do it all alone but we were wise enough to realize that we would slowly regress from all the work we did in the classroom if we didn’t invest in creating leadership from within our own people.

Because we were so dedicated to spending our money efficiently and wisely, rather than hire more people on our rollout team, we asked for the senior leaders in each organization to nominate an individual for the “Agile Champion” role.  This person would be the central point of contact for their teams to funnel training requests, answer basic questions about the rollout and even offer coaching if they were comfortable.  They would liaise with the rollout team each month in an Agile Champion meeting where the status of training requests, survey results and Q&A would be covered. Over time, these champions provided not only a buffer and filter of the overabundance of questions and training requests but they also became our external and internal champions, supporting us in places where we could not be.

Over the summer of 2011, nine teams from HR/Legal, Advertising, Identity Services, AOL Mail and AOL Search had taken either basic Scrum or Kanban courses but they struggled alone without access to experts in the days after class and we began to see the need of post-class onsite coaching to help when needed.  This lead to our monthly Agile Leader meetings where we invited anyone from around the company to join us for an hour to discuss any topic, ask any question and even do a few show-n-tells.  Several people started to really shine in these sessions.  They became our next generation of agile trainers that we use today and have been very successful because not only are they experienced having gone through training with their own teams but they WANT to help people in other teams even if it’s not in their job description or their organization.   To have passionate, experienced and engaging people working towards the same goals made the rollout the success it continues to be today.  This is where we really started to make a difference in sustainment.

Scaling an Agile Rollout

At the beginning of the rollout, we attempted to get each team through the training courses as quickly as possible.  We started in early February with 12 teams on the West and East Coasts in the midst of launching Scrum and Kanban and the list of teams waiting for available trainers quickly grew faster than we could deliver.  We also noted that after teams completed their training, they often needed help but our trainers were already booked to begin training the next team.  It was becoming increasingly difficult to give the time and attention to the teams that had completed training and they often struggled alone and frustrated with no one to help them apply all of their new training and skills.

This is about the time we began to reevaluate our rollout model and worked with our training vendor to make necessary adjustments.  Rather than plow through the training requests just to get every team through the training, we selected a set of product areas and teams that showed the most interest, had high visibility projects and the best executive support to focus our training dollars and devoted our attention to them for 3 months with classroom training, and leadership coaching. MapQuest, AOL Classic Mail, AOL Phoenix Mail, Anti-Spam, and AOL Search made up these core focus teams, which we called our “Wave 1” group. By providing these teams with a dedicated agile coach to help them through their adoption post-classroom, they were able to give attention to their practice and their tool adoption with help readily available without significant delays that we experienced early in the rollout.

With this shift in our attention and training dollars, a waitlist of training requests was created.  Because of this waitlist, some of our agile volunteers were eager to learn more and volunteered to help train the teams that were not included in the Wave 1 group.  They attended Wave 1 team training sessions, learned how the trainers worked through the materials and assisted in writing a mini-training course that could be offered to those teams not in the Wave 1 group.

By November of 2011, we had a library of course materials including video training that our volunteer trainers created.  The library included helpful guides, links to sites and recommended books, videos of Scrum, Kanban and even Scrumban mini-courses that our volunteer trainers had completed.  They were able to successfully provide a training alternative to waitlisted teams that did not want to delay their own agile adoption.  With these course materials and resources available to anyone at the company, the need for additional training funds lessened and more teams were already adopting the culture of helping each other and becoming self-managing by doing the research themselves and trying new things on their own.

By the end of 2011 we had helped over 114 teams from the US, UK, Ireland, Germany, Israel, and India.  We had launched new agile teams, help agile teams tune up their practices, assisted teams in adopting our agile tool and coached teams through particularly hard situations when they needed an unbiased third party to intervene.  We were able to do all of this because of several key volunteers who stepped up to keep the momentum of agile adoption going.  I’m extremely proud of such a small group of people that took the time to learn more, share what they learned and continue to offer their time to other people.  We have created a network of leaders, coaches and trainers that we would not have without their contributions.


In my experience, a balance between outside expertise and internal champions is important to increase the return on the agile investment.  It is tempting for us to believe agile is a quick and simple approach to get fast results from our teams when we begin adopting agile into our organization.  It is also common that we trustingly usher a crew of agile consultants into their “work homes” to take control and whip everyone in to shape through a few classes.  Hiring knowledgeable, quality people with practical agile experience can be a challenge when our own understanding is limited and we are unaware of what it takes to undertake such an enormous task of changing a culture, changing behaviors, and putting the right people together.

In order to make your consulting dollars really pay off, invest in spreading the knowledge and expertise within your own people so that the learning keeps going and the energy to continue is not dependent on your budget.  But remember that the learning should not stop and while your teams may have completed their initial training, access to a knowledgeable coach can make the difference between success and frustration, minor improvements and steady improvements and agile buzzwords and agile behaviors.  One of the indicators I look for in a great agile team is when they are not satisfied with the status quo and they continuously look for ways to improve without being prompted to do so.  Those are the teams to showcase and encourage.  As the teams share, they become more confident and as more teams see what success looks like, they more they will be open to adopting those new ways of working together.

About the Author

Christen is an Agile Evangelist at AOL and is currently responsible for agile training and support across the company.  She is also program managing a large technology initiative to centralize all user identity for AOL products such as AOL Mail, AIM and AOL Music.  She provides coaching and mentoring over 114 different AOL Technology teams around the globe and ensures that all training needs are met.  Christen has over eighteen years of experience in a variety of roles and environments and is passionate about using Agile methods to help guide teams in the implementation of quality products and deliverables that would stand out as successful examples to other teams and encourage Agile practices at an organizational level.  She was so convinced after getting her CSM in 2006 that agile was that “special sauce” for building great teams that she voluntarily began offering a simple Scrum class to anyone in the company that wanted to learn.  The changes caught the attention of the Technology leaders, at which point she was asked to integrate agile techniques and practices into the traditional waterfall SDLC model for AOL.  This transition led to their interest in full adoption of agile in 2007 and a large re-investment in 2011.

Christen is a requested speaker at local events in the DC area and an active blogger and contributor in the agile community. Christen is a certified Project Management Professional and a Scrum Alliance Certified Scrum Professional.

Is AOL going to come back or fade in the background?

I have the luxury of working at a company that is both youthful and experienced (proven by our AIM AV testing in the photo above). We represent the top talent, creative thinkers, early adopters and sometimes trend followers. In very interrelated ways, my fellow AOLers brought the strange, complicated and even unattainable internet into the homes of the young and old without the need for a 300 page manual. We brought America online.

So where does AOL take us next? That seems to be the big question for us. We claim to be on the path to a comeback but we haven’t quite hit that sweet spot and the headlines continue to beat us down, tell us we’re failing and question whether we’re even still around. Our CEO, Tim Armstrong, is driving our business model to content driven platforms, advertising and hyper-local news.

I started at AOL back when millions of people had @aol.com accounts, everyone used AIM to chat and the stock price was over $100. We were focused on bringing products into the everyday lives of our consumers. I think we did that successfully. We had over 30 million members, beer bashes on the lawn during the week and over 14,000 employees all of the world. Ahhhhh the good ol’ days.

In 2012, we are still struggling. I won’t sugar coat it – I can’t sugar coat it. I don’t even want to know what the stock price is and most of my friends are using gmail. *Sigh* What happened to us? I’d love to be blogging about my awesome stock portfolio and the three vacation homes I travel to but that’s not the case. And, while we’re tired of hearing people ask if AOL is still around, we’re not surprised because we seem to be the largest consumers of our own products. Now, having said that, we SHOULD be our biggest fans, but we’re trying to build products that gain popularity in the community. If we are the only ones using our products, we’re failing. Or, we need to change our target audience to working technologists like ourselves.

The business of creating technology that improves people’s lives is a very tough market. Our consumers are becoming more tech savvy and the bar is progressively getting higher. The younger generations are pushing the needle and they are in the mobile space is masses. They have access to build and deploy simple apps in a very short time allowing the least amount of effort to test out theories, ideas and make relatively small bets in a very open space.

So, where ARE we going? Tim’s vision with Advertising and content is a huge swing from what AOL was in the beginning. We’re spending a larger portion of our time and attention on selling advertising space on our content sites. Yes, our content sites might be fantastic; the authors, bloggers and editors are popular and the topics are important and interesting. But I joined AOL because of the products, services and cool shit we could create, not to get people to buy more shit that don’t need. Ugh, it’s a catch 22, as they say though. We have to generate revenue so we can fund projects to build this great stuff and we don’t have a large enough, loyal enough audience to become a premium service. I’m torn on this. It’s like cable television or apps on iTunes. As a consumer you can get your content for free and be subject to disruptive but sometimes entertaining commercials to pay for the shows you watch or you pay a premium to watch your shows without disruptive commercials.

I don’t have the answers but I wish I did so I could help AOL leap forward but for now… I believe my job is to continue to do my best to support the people around me who might just have that next big hairy audacious idea that will make a difference in people’s lives.

Trade Your Wasted Efforts for Tactical Plans

Frequently I have blogs, articles or emails sitting in my box for weeks before I have time to read them but when I do, it was at the right time for me to read them.  One of those articles surfaced in my mailbox today and it was yet again, perfect timing.  The article was from Martin Yate where he explains “How to ace the world’s toughest interview question” and while it would seem perfect for someone looking for a job, I read it with a different lens.  I was looking at it from an angle of focusing on what I want to do and making sure that everything I spend time on is directly related to doing it.

Your job exists to help your employer achieve and maintain profitability. How do your efforts support these goals?”

This is the first sentence Martin writes that caught my attention because I’ve been doing Product Planning and Roadmapping with a few different teams over the past few months and this is how I think of the relationship of stories/requirements to the Projects we plan and the Projects we plan to the Goals for the year.  I ask each Product Owner to understand their stakeholders and managers goals for the year and turn them into actionable goals of their own.

You need to think through whether your job is chiefly concerned with generating revenue, protecting assets, improving productivity in some way, or is perhaps a combination of these imperatives. Once you have determined this you have also outlined the correct framework for your answer.”

Too many times, I see work on a backlog or even on the story board already in progress that cannot be clearly mapped to the goals we agreed upon.  Taking this approach to building your Product Roadmap and settling on a plan can help you eliminate wasteful time spent on things that are not going to get you any closer to claiming successful completion of your goals and hence, your leadership’s goals.

Managers Tranforming with Agile Teams

Here is a great article/blog that I believe speaks very well to the topics many companies need to spend time talking about to support the agile transformation…


%d bloggers like this: