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.

Background

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.

Summary

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.

Advertisements

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…

http://www.estherderby.com/2011/08/rethinking-managers-relationship-with-agile-teams.html

Changes that stick


My rating: 5 of 5 stars

Great examples of change agents in different fields and how to apply them in your own

View all my reviews

Scrum 1:2:2 (Month One:Week Two:Day Two)


This is my second day of the second week of my first month at my new job.  The differences between me and the other Scrum Master are really style at this point so it doesn’t make sense for me to sit in on all of their meetings anymore.  I’ve been focusing on the Business and the process they go through today to get work done.  Boy, it’s a mess!  There are, by title alone, about 3 Project Managers for just about every area of the business and they don’t seem to talk to each other much.  The PM at the outer most realm of the actual delivery team doesn’t really know when or who works on their request and they appear to communicate solely via email with questions like “What’s the status of x?” and “Is anyone working on Y?”  The most important thing for our teams right now is to find out WHO is doing WHAT and WHEN are they going to be done.  There is work being done already but it’s unclear who has been assigned or what their schedules are.
Using my connections through LinkedIn, I was able to find out more than the Product Owner candidates resumes told me.  Our interviews for the new Product Owner are coming along but they won’t start by the time we kick off our first sprint.  In the meantime, I’ve created a draft backlog with Business Owners, Resource names, Roles and requested launch dates so we can begin collecting every project known to the team.  We’ll need to discuss what work must continue, what work should be transitioned.  As busy as it seems and chaotic as it is, this is when I get excited because bringing clarity to chaos is my specialty.  Bring it on! My goal of getting the Scrum Teams trained and in their first Sprint Planning session by the 18th of August is too aggressive considering we don’t have a clean backlog and we are still missing the Product Owner and a Dev Engineer.  I met with the team today to formally introduce myself as their Scrum Master and to share everything I know about our teams, our workload and began our first exercise of team building by voting on simple things as a team. I made sure to include everyone when asking for their input on the team make up (even the one UI guy that had to call into the meeting), and made a point to use words that were team friendly – the “we”, “our”, “us” and “this team” so that everyone begins to hear and feel how being part of a Scrum team will be. We agreed on staggering the sprint start and end dates from the other two team in case we ever need to be at their sprint planning sessions for cross-team impacting stories.  We agreed that our team’s core working hours will be between 10:30am and 3pm to accommodate everyone’s individual schedules.  Two other decisions that will be decided during our Scrum training in two weeks are the team name, the sprint length and the inclusion or exclusion of the User Experience designers as part of the team.  Our resource plan looked like this for our initial discussion:

  • 1 Scrum Master
  • 1 Product Owner
  • 2 Dev (Sys Eng)
  • 2 UI Designer
  • 2 QA Tester
  • 1 CMS Eng
  • 1 DBA
  • UX (Need to confirm if this role will be in the team or not)

We have enough people to start with two teams but we’re thinking of starting out as one team, focus the first few sprints on Knowledge Transfer between team mates in the same role and then split out to two teams once we can function as two independent fully functional teams.  The team seems to be open to that so we may end up there by the end of our next team meeting.
One of our partner teams is not sold on Scrum so he’s asking many of the standard questions about how Scrum works with UX, what are the processes and procedures for how team members work together and where are the data flow diagrams and detailed documentation which is usually not dictated but rather organically grown as the team or teams mature.  This is an area where I need a successful Scrum engineer to share their successes and failures with different Scrum team make ups.  I want to know what they started with and what they ended up with and what scenarios they went through to get to success. Anyone know someone who’s done it? I’m reaching out to some of my Scrum forum groups to see who I can connect with.
Here are some links I found searching the web:

 

Scrum 1:1:3 (Month One:Week One:Day Three)


Long day yesterday so I’m late with my blog so I’m catching up while I ride the train to our other office.  I observed Sprint Planning for each of the first two teams.  This is their fourth sprint so they are working quite well together.  There is open dialogue about stories and their purpose, detailed tasking of the work to complete each story and consensus about how detailed they should be on day one of the sprint.  Occasionally, the conversation would dive a little deep into solving but their Scrum Master was able to redirect them as needed.  Many of the team members are fairly new to the company and new to Scrum so the relationships and communication styles are still in their infancy.  Even still, they have a very respectful and open tone across the team.  That also describes my relationship with their Scrum Master.  We’re spending a few hours a day sharing insights on the team’s maturity as well as his own delivery style to uncover any opportunities for improvement.  It will be a welcome exchange once my team begins and he observes my style firsthand.

Scrum 1:1:2 (Month One:Week One:Day Two)


Today I spent my time in meetings.  I should just end right there because we all know that when you do that, you’re not getting any actual work done.  It’s the type of day that ends with you wondering where all your time went and how fifty people even know you’re email address!  I managed to squeeze in a few minutes to sort through them and start organizing and prioritizing them so I can stay focused on the more important tasks for the week.
If there’s one thing I could share with anyone with time management challenges, it’s to set up Outlook rules to presort incoming emails.  I’ve been doing this for so long I don’t even know when I started it.  I’ve got some rules that automatically move meeting responses to the deleted folder, rules that move emails with certain subject words to a sub-folder, rules that send a notification to my cellphone when the CIO emails me, and others that do some fancier stuff when I need them (can’t give away all my tricks just yet).  It has saved me hours of time not only checking my mail but also searching for mail.  I managed to crash a smoke break on the patio to discuss a candidate for the Product Owner on one of my teams, observe other team’s Standup meetings, Demo prep discussions, Cross Team communication and sharing discussions, Sprint Demos, Retrospectives, and then I learned a little more about the company and the organization.
Org charts are a tricky thing.  They must be since it’s always hard to find and when you do it’s always out of date.  Sometimes Organizational charts have no direct relevance to the Projects or their responsible Business Owners so defining the RACI model takes more time that it should.  Maybe this is something you have experienced, maybe not.  Almost every project I’ve been on has had some “hybrid” or “matrix” team that support multiple business areas but no one can really agree on the same terminology to describe the relationship so we, as Project Managers, are left to standardize the acumen and duck when the daggers start flying.  You’d think that by now, someone would have finally said “Enough already!  Let’s just use the standard and move on!”    Well, in my career, that person has usually been me.  It didn’t always work out initially but we refined the original and settled on something.  I’ve found that it’s easier for people to refine an idea than to create one.  I’m creating a wiki with a matrix of roles and projects to get the conversation started.
As I’m learning where the work comes from, who asks for it and where they are in the organization, it’s apparent that this department really isn’t any different than most.  Ownership and clearly communicated prioritization are usually one of the weakest links in managing work and it appears to be true for this group.  And that’s actually a good thing, because it’s not so overwhelming or foreign to fix.  Typically everyone knows their process isn’t perfect but they just deal with the fallout when it happens.  Sometimes for legitimate reasons and sometimes just classic avoidance.  Sometimes it’s the “loudest voice syndrome”, as I call it.  Whoever yells the loudest gets the attention of the team.  It usually works for the short term but the residual effects are pretty hefty because the working relationships and trust deteriorate and take an enormous amount of effort to repair.
Focusing on the intake process will help eliminate these issues from carrying downstream and help clear the way for the scrum team to kick off their first sprint plan with a well groomed backlog.
During the business introductions this week, I’ll confirm the backlog we have is accurate and build a responsibility matrix for each of the products or workstreams.  This will be helpful to share with my new teams once we have everyone.  Which, by the way, reminds me that I should talk to the Dev Manager again about his plan to have my two new scrum teams kick off their first sprint on the 11th or the 18th.  At our current rate of interviews and the team training sessions, we’re looking at the 18th at the earliest and even then I’m not confident we can get a full team onboarded and trained with the appropriate backlog items with story points ready.  I would rather tackle work in the traditional way (waterfall or chaos) for a few more days, rather than to cut corners simply to hit a start date.  Would you agree or disagree?  Guess I’ll find out tomorrow when I begin sharing that with my peers and managers.

Scrum 1:1:1 (Month One:Week One:Day One)


So it’s the first day on the new team.  There are already two teams sprinting under the other Scrum Master.  I’ve worked with him before indirectly and he’s got the right experience and talent so it’s going to be a great partnership once my two teams are in flight.  He’s not a push over, not shy, and he’s seasoned enough to know when he’s hearing a bad idea but also open to hearing them before he says it’s a bad idea.  We’re going through the resource plans for the other two scrum teams that I’ll be taking on.  I’m already planning for a Scrum training session for each of them but I’m going to play it by ear before i decide if both teams will be in the same session together.  We have a few openings on each team that we need to settle first; some hires, some transfers between teams.

The first two teams have already taken on names for their teams.  Their stand ups seem to be mature for a new team.  The team is on their feet for at least 15 minutes.  Everyone reports in the standard format; What did I accomplish since yesterday? What will I accomplish today? Do I have any roadblocks or impediments in my way?  They even report if the Scrum tools are accurate for our burndown charts.  They spend another 15 minutes or so (officially NOT part of the stand up) going through each story in a bit more detail to catch up on any detailed discussion that wasn’t covered in the stand up.  They currently use Rally for their backlog but I’m not sure if that’s consistent across the department yet.  I’ll be looking into their backlog and tracking tools more this week.

My Product Owner is actually leaving the company in a few weeks so there will be some transition necessary if I dont’ get someone by the end of the week.  I also met two of the Delivery Leads (new role for me as well as the company) and the Dev Manager to discuss our working relationships and our goals.  We’re still getting to know each other but since we all came from the same company before this one we already have some “war stories” to reminisce over.  My meeting with the PM that I will be replacing was much faster than I would have hoped but I’m sure it won’t make much difference in the end.  Since the teams aren’t formed yet, the work is being done by random resources with SME experience based on their Non-Discretionary status until we have fully functional scrum teams to begin working on a backlog.  This leads me to believe that as soon as we complete our first sprint, we’ll already be outperforming what was done before!  I’m going to spend some time in the morning detailing a plan and begin scheduling the meetings for each milestone. 

Just a brainstorm in my next steps… I’ll need to gather as much knowledge as I can about the architecture of the systems and the business to see the big picture more clearly.  Even if I don’t have a new Product Owner in place, I’ll start pulling together a draft of the backlog and begin grooming the Business Leads that the Product Owner will interface with so I can brief them on how the scrum looks and feels.  I may even do a quick Scrum session just for them.   I’ll be traveling to another site this week to confirm the team members and the openings. I’ll be traveling with my Scrum Master partner, Delivery Lead, and Dev Manager so if there is any room for process improvement or efficiency opportunities we’ll probably spend the train ride discussing those.  So I’ve just built my own two week sprint!

%d bloggers like this: