Loading…
Agile2018 has ended
Experience Reports [clear filter]
Monday, August 6
 

10:45 PDT

Joining Forces: An Agile Experiment in Merging Teams (Kevin Normand)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
When teams are working well and firing on all cylinders, you don’t want to mess with them. But what happens when two such teams are merged into one for the duration of a project? In this experiment we did just that, and what we stumbled upon was a bit surprising - and inspiring!
In this report we begin by exploring why mixing things up from time to time can be valuable opportunities for mentoring, improving work practices, rejuvenating spirits, and let’s not forget - meeting that aggressive deadline. We then dive into the recipe we found to make the experiment work (for example, that the teams should each bring unique value to the project while having at least some overlapping skill sets and work practices, that both teams should have similar Agile work practices and be ready to compromise, and that individual roles should be clearly defined from the start). Finally, we share retrospective feedback from team members highlighting the positive experience.
View the Experience Report

Lessons Learned from Your Experience:
  • Bringing two teams together for duration of a project: a) is a refreshing experience for the teams with high engagement and creativity - an opportunity to break away from the mundane; b) can be very effective for meeting an aggressive deadline; c) actually improves communication between individuals
  • Steep learning curves are quickly overcome by working with knowledgeable peers
  • People enjoy learning from new colleagues; but can be shy about mentoring new colleagues.
  • Kick off the project with a meet-your-neighbor retrospective
  • Leave time in the first planning meetings for consolidation of practices - be ready to compromise on story point metrics, definitions of constructs; and then move on. When the teams are already performing similar Agile practices, the combined process is easier for all.
  • "Role collisions” are a possibility. Good leadership and teamwork skills will come into play very quickly.

Attachments:

Speakers
avatar for Kevin Normand

Kevin Normand

Deputy Manager, R&D, Fugro
Devotee in the arts of Agile, Machine Learning, C#, Git, JIRA, Confluence, AWS, C++, team spirit, transportation planning, cycling, team sports, teamwork, maps, old maps, new maps, and more. Proponent of retrospectives, continuous learning, roundabouts, and Joy in the workplace! Advocate... Read More →


Monday August 6, 2018 10:45 - 11:15 PDT
Torrey Pines Room 1, 2, & 3

11:30 PDT

Learning to Experiment (Christopher Lucian)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Learning to Experiment
The best organizational changes in my career have happened as a result of emergencies. Support for the process of experimentation only seems to become enabled whenever the status quo has completely broken down. In those moments of crisis rebuilding with better has been possible, but why do we wait? In this report I share our experiences with experimentation at Hunter and encourage you to develop a culture of continuous improvement and continuous experimentation that will get you to where you want to be without having to be in a crisis mode.
Today I am the director of a new software development department and we continue to utilize Mob Programming as well as many other practices. This report is about my journey through software development and specifically the experiences I have had with the process of software estimation. We are currently a department of 27 with 6 full time mobs; each team does not estimate software but instead practices pure Kanban and delivers vertical slices of software daily. Hunter is not the first place I had dropped the practice of software estimation for a project. Back in 2007 I was working in an Environmental Chemistry and Military Contracting organization that had a more traditional waterfall environment. During that time, we created a Gantt chart of how each project would go until one day there was an emergency that prompted us to do things slightly differently. I have come a long way and experienced many iterative steps through my software development journey. Let’s start with where we are today and work our way back discussing practices and insights we discovered on the way.
View the Experience Report

Lessons Learned from Your Experience:
  • Experiment with process and technical direction now, don't wait until it is too late.
  • Emergencies can give you space to experiment when things are dire.
  • Artificial constraints like estimation can get in the way of your team developing their skills.
  • Dedicated learning time for a team is a prerequisite.



Monday August 6, 2018 11:30 - 12:00 PDT
Torrey Pines Room 1, 2, & 3

14:00 PDT

SESSION FULL: The power of three: the journey of an Agile Leadership Team (Nienke Alma)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
It’s 2015, and ING Bank is about to start an exciting transformation. A new Agile Way of Working is introduced for the entire domestic bank in the Netherlands. The Way of Working also requires a challenging cultural change. Delivery goals and delivery approach are no longer directed top down. Feature teams that are formed everywhere in the organization have to learn how to deal with a much larger set of responsibilities. Fortunately they are not alone: there’s a new Agile Leadership team that provides guidance, helps them to develop craftsmanship and shows how to deal with their autonomy in an Agile organization. This Agile leadership team is the “POCLAC”.
In the new organization, the Product Owner, Chapter Lead and Agile Coach form a virtual team supporting the Purpose, Mastery and Autonomy of the feature teams. Each role has its own focus area, but together they share one goal: making sure the feature teams can flourish. That all may sound easy, but the reality is very different. How do you make sure these three roles truly collaborate? Which conditions should be created to make this work? And how do you prevent this virtual team from being perceived as a traditional management team by their environment?
In this talk we will follow the journey of one POCLAC during the past two years. We will see how people with very different backgrounds explore their common grounds in the first meetings. We will look back at the ups and downs, while we will learn that good intentions not always lead to the greatest results. For sure it has been a bumpy road, but there’s a lot to be proud of today. This POCLAC has become a leadership team that is widely recognized for the example they give of the mindset and behaviour needed in an Agile culture.
View the Experience Report

Lessons Learned from Your Experience:
  • We have learned how the responsibilities between POCLAC members should be divided
  • We have learned how the structure of POCLAC meetings influences the impact of the POCLAC on the feature teams
  • We have learned which behaviour in the Agile Leadership team supports the performance of the feature teams and which behaviour is counterproductive
  • We have learned how important it is for an Agile Leadership team to respect the autonomy of the feature teams
  • We have learned that the autonomy of the feature teams impacts the expectations that the feature teams have of the role of the POCLAC

Attachments:

Speakers
avatar for Nienke Alma

Nienke Alma

Agile Coach, ING
Nienke Alma is a people oriented Agile enthusiast with 12 years of experience as Agile coach, trainer, Scrum Master, tester and test manager. She currently works as an Agile Coach at ING in the Netherlands.She has special interest in team dynamics. Getting the best out of individuals... Read More →


Monday August 6, 2018 14:00 - 14:30 PDT
Torrey Pines Room 1, 2, & 3

14:45 PDT

A Natural Servant Leader Unlocks the Power of Employees at a Global Contact Center (David Grabel, David Reichert)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Have you ever known a natural servant leader? We had the privilege of working with Serena Godfrey, VP of Customer Service for Vistaprint. She easily passes Robert Greenleaf’s best test for a natural servant leader - “Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?”
In this session, we will briefly share how, as a servant leader, she fundamentally transformed the work lives of 1,800 employees in a global contact center while delivering outstanding business results. She turned an unpleasant command and control environment into a self-organizing, Agile organization. Attendees will have a chance to meet and ask questions of Serena, members of her leadership team, and front-line employees who have traveled from their offices in Montego Bay, Jamaica.
View the Experience Report

Lessons Learned from Your Experience:
  • At the conclusion of this session, you will be able to:
  • Explain how servant leaders can improve the lives of their employees and enable those employees to deliver better business outcomes.
  • Apply the principles of servant leadership and Agile to elevate rote work into knowledge work.
  • Guide leaders who are not natural servant leaders on their journey towards becoming servant leaders.
  • Guide leaders in developing an organization with servant leadership at all levels.

Attachments:

Speakers
avatar for David Grabel

David Grabel

Enterprise Agile Coach, Fidelity Investments
David Grabel is an enterprise agile coach consulting at Fidelity Investments bringing Agile to the entire organization. He has introduced Scrum, Kanban, XP, and SAFe at both small and large organizations. His previous clients include Vistaprint, Trizetto, Bose, and PayPal where he... Read More →
avatar for David Reichert

David Reichert

Agile Coach, Vistaprint
As an Agile Coach at Vistaprint, David assists key leaders in continuing the organization's Agile transformation through education, mentoring, professional coaching and facilitation. He has co-developed and co-delivered Agile leadership pathways which have helped leaders gain the... Read More →


Monday August 6, 2018 14:45 - 15:15 PDT
Torrey Pines Room 1, 2, & 3

15:45 PDT

"Soup or Salad" - Models of Diversity (Avraham Poupko)
Limited Capacity seats available


Abstract:
Diversity is a multi-faceted and overloaded word. In this experience report I describe some of my own experiences with diversity along with some insights and musings. One of my main points is that diversity is great, but we need to go beyond the accepted types of diversity and find new (and diverse) ways of being diverse.
View the Experience Report

Lessons Learned from Your Experience:
  • If we want to reap the benefits of diversity we must understand the following:
  • 1. You do not get the benefits of having multiple views by compromising between the views. You get the benefit of multiple views by adopting the great parts of each view, or better yet by arriving at a new view.
  • 2. We need to think critically about what diversity is. If we are going to be dogmatic about diversity, we will loose a lot of what diversity has to offer.


Speakers
avatar for Avraham Poupko

Avraham Poupko

Senior System's Architect, L&T Technical Services
I am an Architect and leader of a group of Architects in L&T's Center of Excellence in Jerusalem. I am fascinated by the ways by which people get together to create software. The idea of minds joining to create something "abstract" such as software is one of the great wonders of... Read More →


Monday August 6, 2018 15:45 - 16:15 PDT
Torrey Pines Room 1, 2, & 3

16:30 PDT

The Flying and the Thud: Mental Health Issues on Agile Teams (Cass Van Gelder)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Years ago during a personal crisis, several of my friends who were unaware chastised me at a party for sitting in the wrong seat. While I had been struggling with deep medical issues, they had chosen microscopic issues to pick at and hover around, things that would not matter the next time the sun rose. I had likened it to my friends complaining I had ants in my sink while I was battling lions at my front door.
Similarly, through my work with Agile teams, I have seen a preponderance of ADHD, OCD, anxiety, etc. issues - team members' own personal lions at the door. Colleagues admonished them and even made fun of them behind their backs. Managers wrote them up for infractions that were more symptoms than real problems. What they are missing is the incredible caverns of hidden surprises that come from inside those brains.
Agile is currently being overwhelmingly used in software development. In turn, software developers have shown to have a preponderance of ADHD, OCD, Asperger's Syndrome, autism, Bipolar Disorder I and II, etc. Additionally, since Agile encourages teams to work together, these issues can be a stumbling block (and sometimes a 50 foot wall) that keeps the team from growing, and even from simply functioning.
While supervisors have supported ridding the teams of these "difficult" team members, I have advocated maintaining the members and tweaking our approach to be more inclusive.
Surprisingly, this became a more personal issue recently.
Come join me while I talk with you about my experience of advocating for understanding and accommodation, and a personal revelation of my own - my own lion at the door.
View the Experience Report

Lessons Learned from Your Experience:
  • Basic Understanding of Mental Health Issues
  • Background on Common Mental Health Statistics and Their Effects
  • Connection to Agile
  • Potential Issues
  • Potential Solutions


Speakers
avatar for Cass Van Gelder

Cass Van Gelder

Scrum Master, CSM, CSPO, CSP-SM, CSP-PO, Kroll


Monday August 6, 2018 16:30 - 17:00 PDT
Torrey Pines Room 1, 2, & 3
 
Tuesday, August 7
 

09:00 PDT

You Have to Say More There: Effective Communication in a Distributed Agile Team (Johanna Rothman, Mark Kilby)

Abstract:
For years, we’ve heard that only collocated teams can use agile approaches. This disregards the roughly 50% of agile teams who already are distributed or dispersed and their successes or failures. Instead of assuming agile teams can only be collocated, what if we wrote a book to help distributed and dispersed teams see options for their agile success?
As we co-wrote the book, we realized we were living the same principles as distributed and dispersed agile teams do. We worked in short timeboxes and reflected often. We chose to write together, rather than separately. (We did choose to create images separately so we could then discuss them together.)
We created at least two communication paths as backup for our primary path so we always had a way to talk with each other (google docs, Zoom, and text message). We learned the power of a streak, to continue writing every day (or as close to it as we could) to finish paragraphs, sections, and chapters. We learned how to use the tools and when to evolve the tools we used. We looked like an agile team, with continuous integration, continuous delivery (to each other), and continual reflection and refinement.
We also learned several key phrases that helped us learn when we worked well and not so well together. Some of these phrases are:
  • "You have to say more about that" (signaling it might be clear to one of us, but concerned a type of reader may not understand)
  • "When I’m not so tired, I’m pretty human" or "the writer did not show up today" (reflect our readiness to work and where we might lean on the other person)
  • Mind if I tweak that? (to switch pairing)
  • "I found where you are" and "Let me click to where you are" (when we needed to synchronize where we were working - in a Google doc)
  • "I’m okay with that" (reviewing work)
  • Comments, highlights and XX marks the spot for more work
View the Experience Report

Lessons Learned from Your Experience:
  • How checkins are valuable to reset/recreate our work together, by syncing on our context every time we worked together. (And allowed for a little whining about the weather.).
  • How cadences in writing are different than timeboxes.
  • How to pair at distance. How writing together made our work stronger (ideas and writing).
  • How to articulate our working agreements and evolve them.
  • Guidelines for pair writing at distance.
  • How to recognize key phrases that help a team write together.
  • How quick reflection can help collaboration.
  • How we could declare done or done for now: chapter goal, word count, and our definition of done

Attachments:

Speakers
avatar for Mark Kilby

Mark Kilby

Agile Coach, K5Labs LLC
Mark Kilby coaches leaders, teams and organizations on how to work more effectively, whether they are distributed or collocated.  For over two decades, his easy-going style has helped his client learn to collaborate and discover their path to success and sustainability.Sometimes... Read More →
avatar for Johanna Rothman

Johanna Rothman

President, Rothman Consulting
Johanna Rothman, known as the "Pragmatic Manager," provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Johanna was the Agile 2009 conference chair. Johanna is the author of several books... Read More →


Tuesday August 7, 2018 09:00 - 09:30 PDT
Torrey Pines Room 1, 2, & 3

09:45 PDT

Reinventing Research: Agile in the Academic Laboratory (Kendra West)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
In a world of editable genomes and customizable cancer treatment, it’s time to reconsider how the academic lab operates in order to keep pace with rapidly advancing research. The Broad Institute of MIT and Harvard is one of the world’s leading genomic research centers, where over thirty academic laboratories, groups, and platforms work collaboratively to enhance human health and medicine. “Agile Academia”, the Broad’s Agile affinity group, is working to help academic laboratories to incorporate Agile values into their day-to-day operation in order to more quickly respond to change and enhance the research process. This talk will detail Agile adoptions by multiple Broad Institute laboratories and introduce challenges faced by the teams — competing priorities, staggered timelines, scientists’ skepticism, and how best to support inherently individualized work. Agile consultants and practitioners of all experience levels will learn new strategies for introducing and fostering Agile values in novel contexts.
View the Experience Report

Lessons Learned from Your Experience:
  • A clear understanding of how academic research is performed, how academic labs work, and how the Agile values can enhance teams in this space
  • Methods to approach the introduction of Agile values in a field with no industry-specific examples
  • Recommendation of Agile-based tools to complement any type of team, regardless of industry
  • How a successful introduction of Agile-based tools can lead to accelerated, organic team growth
  • Strategies to align individuals who have differing goals in order to build a team and foster collaboration

Attachments:

Speakers
avatar for Kendra West

Kendra West

Scrum Master, The Broad Institute of MIT & Harvard
Scrum master and science nerd! I enjoy exploring ways to enhance teams and organizations through coaching and creativity.


Tuesday August 7, 2018 09:45 - 10:15 PDT
Torrey Pines Room 1, 2, & 3

14:00 PDT

Agile Road Trip, Lessons from a Coach at Toyota (Bob Tarne)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
While Toyota is known for the Lean practices developed as part of the Toyota Production System, their prowess on the production line didn't equate to a well-running Information Systems (IS) department. An Agile transformation began in 2016 to move the North America IS group from waterfall practices to Scrum. This report is based on the experiences of one of the coaches working on that transformation, the challenges he faced, and the tools he used to move the transformation in the right direction. The discussion will include how concepts such as Crew Resource Management (CRM), High Reliability Organizations (HROs), Red Teaming, and the ZoneFive tool from AGLX were used to build high-performing teams. CRM was first developed to reduce human error that had led to a number of airplane crashes in the 1970s and is cited as one of the reasons there were no causalities in the 2009 crash of US Air flight 1549. HROs developed out of complex, highly volatile environments such as aircraft carriers and nuclear reactors that are able to avoid catastrophes in spite of their volatility. The discussion will also talk about how the Scrum@Scale model was applied and the challenges in getting managers and executives engaged as chief product owners and metascrum participants.
View the Experience Report

Lessons Learned from Your Experience:
  • - How to overcome group-think by using a tool such as "think-write-share" and practicing good planning poker techniques
  • - How to plan a sprint better by applying critical thinking during the planning process
  • - How to use the military briefing approach to "debrief" after activities such as stand-ups to assess how effective they are being run
  • - The importance of working with all levels of management during a transformation to create the environment where teams can be high-performing

Attachments:

Speakers

Tuesday August 7, 2018 14:00 - 14:30 PDT
Torrey Pines Room 1, 2, & 3

14:45 PDT

Yes, You CAN Let Your Teams Self-Organize! (Faye Thompson, Rob Reed)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
'Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.'
This principle from the Agile Manifesto - that teams are 'self-organizing' - may sound simple; however, supporting self-organizing teams can be one of the more significant cultural changes that a company in transformation faces. This is especially true in a large enterprise. You may see hierarchical structures and processes in place that prevent teams from aligning themselves around work to be done. You may even go so far as to think 'there's no way that would work here.' But we're here to say that it can work, and it can yield happy, productive teams who are more energized than ever before to deliver value for your customers.
We are scrum masters at American Electric Power, one of the largest electric utilities in the U.S., serving nearly 5.4 million customers in 11 states. The teams we are a part of have explored dynamic reteaming, self-selection, interviewing and hiring new team members, pairing and co-training in order to build the strongest teams possible for the work at hand. All of this was done with the support of our management, and through incremental change. While our path wasn't always easy, we did learn a lot along the way. We want to share our story so that you might start to envision a future reality in which your teams can be trusted with organizing themselves.
Read the Experience Report

Lessons Learned from Your Experience:
  • Team members enjoyed having a say in which team they would work on
  • --- The teams came up with the idea for adding the 3rd small team, which addressed a problem everyone had experienced for a long time, which was business partners having to wait a long time to get smaller projects that should have been quick-hit items. So in the end, they truly felt that they had collaborated on a solution that would satisfy their customers
  • --- There were people who wanted to be a part of that shorter/quick-hit work
  • --- Some team members really didn’t care which team they were a part of, and those were the most difficult situations to work through
  • Team members were able to voice concerns about missing skills that were needed in order to be cross-functional, and this provided an actionable guide for management to support whole-team learning
  • No one got hurt!
  • --- Often organizations state that this kind of self-selection exercise would be impossible because they envision contentious talks and playground behaviors
  • --- For our teams, it really was a collaborative, respectful exercise with one goal: let's organize ourselves in a way that makes the most sense for our company and our customers
  • --- All the discussions were positive, e.g., ‘You are really good at this – you should be on that team to help them learn that skill.’
  • --- The teams enjoyed the exercise, and now plan to re-evaluate and reteam as needed at the start of each new round of projects
  • The trust demonstrated by our manager and among the team members during this exercise has allowed and encouraged us to explore other areas of self-organization, e.g., team involvement in hiring decisions for new people, approval of new training requests, and designing our workspaces when we moved to a new office building
  • We have identified a few things we want to investigate and/or do differently next time:
  • --- Contractors were not included in the collaborative session this time, and there really was not a good reason to exclude them. Next time, they will be a part of the discussion.
  • --- No allowance was made for individual professional development goals, possibly due to the time of year when the reteaming occurred. We want to discuss what impacts any of this could have on performance goals.


Speakers
avatar for Rob Reed

Rob Reed

Scrum Master / Agile Coach, American Electric Power
15 year project manager turned scrum master for the last few years. Dipping my toe into coaching other teams at AEP. Passionate about agile mindsets, having fun and helping teams improve and progress along their agile journey. Check out my amazingly horrible retrospective drawings... Read More →


Tuesday August 7, 2018 14:45 - 15:15 PDT
Torrey Pines Room 1, 2, & 3

15:45 PDT

Agile & HR: Driving cultural change as one team (Melissa Rockman, Amy Jackson)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Is your HR department slowing you down? Do you feel like they’re a major impediment in your agile journey? We will tell the story of how Vistaprint’s HR team, now known as Talent + Experience Transformation Team (T+E), transformed from a traditional HR team of office dwellers and privacy screens to a more agile way of working (we don’t even have desks now!). We discuss what propelled our transformation, which parts of agile were easy to adopt and which parts didn’t work as well for our team, and the critical steps to make it happen. We’ll even share how our agile coaches are now embedded within our T+E team!
Join us as we retell this part of our agile transformation journey including the lessons learned and fun we had along the way.
View the Experience Report

Lessons Learned from Your Experience:
  • How to adapt the agile manifesto to resonate with HR teams
  • How to overcome varying degrees of agile knowledge and experience
  • How we transformed our performance management process
  • How we established a culture of real-time feedback
  • How we’ve evolved the role of the leader in an agile environment
  • How to coach HR teams to work in smaller increments
  • How agile is becoming a part of our culture and how we work

Attachments:

Speakers
avatar for Amy Jackson

Amy Jackson

Agile Coach, Vistaprint
Amy is an Agile Coach at Vistaprint in Waltham, MA.  With nearly twenty years’ experience in Human Resources, and a passion for working with teams, she began exploring how the mindset and practices of Agile might help “non-technology” teams achieve high performance in order... Read More →
avatar for Melissa Rockman

Melissa Rockman

Agile Coach, Vistaprint
Melissa is an Agile Coach at Vistaprint in Waltham, MA.  Her background is in online marketing where she discovered how experimenting with agile led to a happier team and more value to the customer. From there, she completed Emergn's Expert Coaching Pathway and began coaching teams... Read More →


Tuesday August 7, 2018 15:45 - 16:15 PDT
Torrey Pines Room 1, 2, & 3

16:30 PDT

codeX Story: Challenging the Metrics that Limit Diversity in the Software Industry (Cara Turner)
Limited Capacity seats available


Abstract:
codeX is an agile-first vocational coding programme in South Africa, with a mission to increase the talent pool that the software industry can draw from.
We focus on reaching groups who are under-represented in tech, provide them with a solid agile web developer skill set, then connect them with jobs where they can flourish. Diversity is what we live and breathe.
Now in our fourth year of operations, we have shaped our programme year-on- year, based on the needs and insights of all our customers (applicants, mentors, coaches and employers).
Covering stories of our graduates' and employers' experiences, this talk looks at what we have learnt about hiring and diversity, fundamental indicators of developer talent, and how we have worked with organizations to create environments that support team members from different socio-economic backgrounds.
Beyond gender and ethnicity filters, one of the greatest barriers to diversity lies in the infrastructure and environment differences between affluent communities and those in poverty, and the hidden biases of recruitment processes and performance measurements.
In this session I'm introducing the indicators we developed for accepting applicants that go well beyond academic filtering, and how we are helping companies review the profiling-type filters that their HR departments got stuck with, to find homes for developers who bring both agile thinking and diversity of perspective to their teams.
View the Experience Report

Lessons Learned from Your Experience:
  • Agile first: blending education and discovery practices
  • Metrics that block diversity
  • - How recruiting and on-boarding practices work to keep diversity out
  • Measuring to create success
  • Changes we made in the on-boarding process
  • - New models we developed for internships


Speakers
avatar for Cara Turner

Cara Turner

CEO & Agile Coach, codeX
Cara is the CEO and Agile Coach at Project codeX, an agile-first software training programme that equips aspiring coders with high quality skills and experience, while bridging the digital divide.Having spent years helping teams adopt agile practices that reduce risk and increase... Read More →


Tuesday August 7, 2018 16:30 - 17:00 PDT
Torrey Pines Room 1, 2, & 3
 
Wednesday, August 8
 

10:45 PDT

Share the Load: Distributing Design Authority with Lightweight Decision Records (Michael Keeling, Joe Runde)
Limited Capacity seats available


Abstract:
Documenting architecture design decisions is commonly considered a good practice but few teams take the time to write down the decisions they make. In our experience this happens for a few reasons: architecture documentation is rejected as being too heavyweight, documentation is typically out of sight and out of mind, and many developers don’t know what to document. Architecture Decision Records (ADRs), a lightweight documentation approach proposed by Michael Nygard, solves these problems by recording design decisions in a simple markdown template in the same repository as the code affected by the decision. We've found that this technique has many advantages. Documenting ADRs creates opportunities to involve more teammates in the design process. Up and coming architects can safely practice design under the guidance and review of experienced teammates. Over time ADRs form a catalog of proto-patterns that can be bootstrap future architectures.
In this talk we will share our experiences and lessons using ADRs over the past two years while working on the IBM Watson Discovery Service. By the end of this talk you will know how to create effective ADRs, introduce the technique to your team, and avoid common pitfalls with the method.
View the Experience Report

Lessons Learned from Your Experience:
  • How to phrase a decision as a lightweight decision record and share it with others
  • How to think through decisions and how to guide others in doing so
  • ADRs help us write better code
  • ADRs help us understand what risks we are accepting and we are able to think more strategically about risk
  • Other documentation is still required and ADRs are a good way to figure out what else needs to be documented. ADRs are a part of a minimalist set of design documentation
  • We can learn from past decisions in other parts of the system and extract team and institutional patterns

Attachments:

Speakers
avatar for Michael Keeling

Michael Keeling

Staff Software Engineer, LendingHome
Michael Keeling is a software engineer at LendingHome and the author of Design It!: From Programmer to Software Architect. Prior to LendingHome, he worked at IBM on the Watson Discovery Service. Keeling has a Master of Science in Software Engineering from Carnegie Mellon University and a Bachelor of Science in Computer Science from the College of William and Mary... Read More →
avatar for Joe Runde

Joe Runde

IBM
Joe Runde is a software engineer who recently started his career at IBM. There he works on Watson while teaching about machine learning methods and learning about software design from many smarter folks. Joe has an MS in Machine Learning from Carnegie Mellon University and a BS in... Read More →


Wednesday August 8, 2018 10:45 - 11:15 PDT
Torrey Pines Room 1, 2, & 3

11:30 PDT

Beyond Whack-a-Mole Coaching - Using Data Analysis to Find High ROI Coaching Opportunities (Marie Dingess, Doug Steele)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Determining where to focus Agile Coaching and Training in a large “already Agile” Tech organization can feel a bit like playing Whack-a-Mole. With hundreds of Agile practices and mindsets to potentially target and hundreds of teams at various levels of maturity and scale, how do you know which ones to target that will really make a difference? It’s easy to just focus on the areas that are least mature, rather than on the ones that might have the most impact.
In 2017, Capital One used a different approach with 2,600 employee survey responses in the areas of Intent, Planning, Flow, Team Health, Scaled Agile, Continuous Improvement, Leadership, and Engineering. We used statistical analysis to identify the impact of different Agile practices on two key areas: Team Health and Frequent Delivery of Business Value – revealing our Agile ROI!
In addition to sharing our analysis, we will tell the story of how we used these results in a multi-channel communications strategy to influence change agents towards improving practices with the largest impact rather than just improving the least mature ones.
View the Experience Report

Lessons Learned from Your Experience:
  • Through this experience, our Coaching team and organization learned:
  • • The benefits of using survey data to focus coaching efforts and influence leadership to support positive change, rather than relying on industry best practices alone
  • • The need to package statistical analysis approaches and results in ways that are easy to understand for non-specialists
  • • For our organization, there are specific Intent, Planning, and Scaled Agile practices which impact Frequent Delivery of Business Value
  • • For our organization, there are specific Leadership, Continuous Improvement, and Planning practices which impact Team Health
  • • Some provocative findings:
  • o Teams sizes larger than 5-9 were effective; only at 12+ did team effectiveness suffer
  • o Planning activities were highly correlated with Frequent Delivery of Business Value and Team Health, despite internal perceptions of the opposite

Attachments:

Speakers
avatar for Marie Dingess

Marie Dingess

Agile Coach, Capital One


Wednesday August 8, 2018 11:30 - 12:00 PDT
Torrey Pines Room 1, 2, & 3

14:00 PDT

Agile for All (Agile is Caught Not Taught) (Naveed Khawaja)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
We strongly believe that 'Agile is for Everyone'. For an agile transformation to succeed at scale, non-IT departments play a vital role to bring about a sustainable change.
In this report, we will share how business teams at AstraZeneca are choosing to adapt the Agile ways of working across the globe.
Brief History: In 2016 we shared the initial success of adopting Agile with large IT programs, creating quick wins that responded some naysaying such as…
“We can’t run Agile. We have globally distributed teams”
“We can’t run Agile. We have to validate our systems.”
“We can’t run Agile because Agile is for application development. We deploy COTS programs”
Today: Motivated by clearly articulated organizational values and behaviors (that reflect an agile mindset), AstraZeneca business teams are beginning to ask how they could bring Agile practices to the work of their teams.
What's important is context:
Understanding the context of how a team works, and what that work is - has been a critical step for business teams to adopt agile practices. What works in one team, does not necessarily work with another team even in the same department.
We will share:
How have we made the steps to adapt agile for business teams?
When we failed, how we failed and what we learned.
Lessons from business teams, video interviews with business leaders and their take on agile and lean mindset
View the Experience Report

Lessons Learned from Your Experience:
  • How this 'Agile within Context' approach builds bridges between IT teams and business teams?
  • It's all about stealth marketing - how to start the conversation with the business.
  • Agile as a way for business teams to address rapidly changing priorities, limited resources, and time pressures

Attachments:

Speakers
avatar for Naveed Khawaja

Naveed Khawaja

Director, Agile & Lean Business Transformation (Master Trainer & Coach), Xecofy Consulting
A busy British father of five who sees the family and life as a whole with the Agile & Lean lens on a daily basis and inspires people all around the world.Some friends call him "the KanBan Man" as he helps everyone in being more productive and living a more fulfilled life.His passion... Read More →


Wednesday August 8, 2018 14:00 - 14:30 PDT
Torrey Pines Room 1, 2, & 3

14:45 PDT

Scaling XP Through Self-Similarity at Pivotal Cloud Foundry (Evan Willey)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Pivotal's mission is to transform how the world builds software. We believe in the core tenets of Do What Works, Do The Right Thing, and Be Kind. We express those beliefs every day through our commitment to following XP practices and principles, such as sustainable pace, test driven development, continuous integration, and pair programming. While Pivotal has had a long history with XP, it's been on the Pivotal Cloud Foundry project that we have been applying those practices and principles to our approach to Program Management. That's the story I'd like to tell you about in this experience report.
During the last four years the Cloud Foundry R&D team within Pivotal has grown from around 10 two-pizza teams to over 60. We've scaled from two offices to eight that now spread across the globe. Adoption of the Cloud Foundry Platform as a Service (PaaS) by over half of the fortune 500 has increased the stakes we're working under and the responsibilities created by a mature, successful product (a good problem to have!). Our growth has been consistent and shows no signs of slowing down, and all along the way we've used XP principles to adapt our systems to new challenges that scaling presents.
In my role as the Senior Director of Program Management I've been around for this journey and the many lessons we've learned along the way. In that time, we've grown the TPM team, defined what Program Management means within Pivotal's context, tried many experiments, and continue to leverage the learnings of a few that have worked out well.
View the Experience Report

Lessons Learned from Your Experience:
  • When facing a scaling challenge we find that it's usually best to first ask, "what would a single, high-functioning team do?" as a starting point, then take a small step forward via an experiment, and then reflecting on the results before expanding the solution further or refactoring.
  • Successful adoption of new ways of working happens best and lasts for the long haul if the change agents, who in our case are frequently the Technical Program Management team, work with, and not for, our product teams. We do this through pairing directly with product, engineering, and other functions across the org to grow empathy and buy-in for the right solution to the problem we're trying to tackle. Often, the problems we're addressing have been sourced from the teams themselves through regular cross-team retrospectives, a process that also helps with solution adoption.
  • Self-similarity isn't the be-all-end-all. For example, there have been times where individual teams' focus on a single backlog of prioritized customer problems hindered our ability to create healthy flow for cross-team 'chores' such as security or compliance work. We've had to invent some new techniques and tools to help things out there.
  • Conveying and understanding strategic intent across a growing product organization such that PMs and teams maintain agency over their own local context while still keeping alignment to larger organizational goals is difficult. Coming up with the right metaphor and level of abstraction for a single 'backlog to rule them all' of customer outcomes has been a challenge that we continue to iterate on.
  • Program Management's continuous focus on 'automating ourselves out of our jobs' and an R&D organization that sees the long-term value in allocating engineering Pivots to assist with that cause has been incredibly valuable. As a team, we are not comfortable doing the same thing we were doing this time last year.


Speakers
avatar for Evan Willey

Evan Willey

Senior Director of Program Management, Pivotal


Wednesday August 8, 2018 14:45 - 15:15 PDT
Torrey Pines Room 1, 2, & 3

15:45 PDT

Experimenting with Mob-programming (Amr Noaman)
Limited Capacity filling up


Abstract:
Mob-programming is a revolutionary technique for developing software. It's like pair programming with 6-7 team members in stead of two! Seems ridiculous, right? This is how extreme programming (XP) practices seem at first before they spread like wildfire!
In this report, I'll explain how we ran mob-programming sessions with four teams. I'll explain the setup we have selected, the types of tasks we were resolving, obstacles we faced, and my observations while facilitating the sessions. Also, I'll share some of the comparisons between mob-programming and solo-programming for sample tasks and the amount of effort/duration they consumed. Finally, there were hidden wastes (like integration, handoffs, misunderstandings, extra-features, etc.) in our process which were viewed by the team as usual work tasks or activities! Mob-programming opened our eyes to see these wastes and made us feel and quantify how much time it used to take us.
View the Experience Report

Lessons Learned from Your Experience:
  • Mob-programming saves the hidden cost of integration, handoffs, misunderstandings, extra-features, etc. which amounts for a large percentage of team time (I would say more than 60%. At least, we witnessed 20-30% of team time spent on integration and resolving integration issues)
  • Simple hints and partial solutions from team members accumulate and form an excellent overall solution and short-cuts
  • Some tasks would have never been carried-out without mob-programming them
  • It was fun! and joyful
  • It may be impossible to work this way if we're working under pressure

Attachments:

Speakers
avatar for Amr Noaman

Amr Noaman

Co-Founder & Principal Coach, Agile Academy
* Coach, consultant, and speaker passionate to propagate lean and agile thinking in the Middle East and North Africa* One of the drivers of Egypt's GoAgile program, transforming tens of teams and organizations from a wide range of private and public organizations. * Co-founder and... Read More →


Wednesday August 8, 2018 15:45 - 16:15 PDT
Torrey Pines Room 1, 2, & 3

16:30 PDT

All Track Development (Anthony Boobier)
Limited Capacity filling up


Abstract:
We all know the importance of product designers and developers working more closely together. One approach to achieving this is ‘dual-track delivery’. But we shouldn’t think of dual-track delivery as separate tracks, because they’re not. They happen in tandem. They happen on one overall track with one purposeful team. A team with UX and development skills working together to test assumptions, learn what a customer really needs and deliver an outcome that is truly valued. Dual Track is actually All Track.
This talk will show how we used tools and techniques at BNZ Digital to implement All-track development’ and bring multiple disciplines together as one team – how we use a mash up of mindsets and tools to balance the ‘Speed of Learning’ with the delivery of ‘Value to the Customer’.
View the Experience Report

Lessons Learned from Your Experience:
  • How we created an All track delivery approach and included disciplines such as UX Researchers, UX Designers Product Owners and Managers
  • Product management is disciplined empiricism using experiments and is a mash up of Lean, Agile and Design Thinking
  • introduce some tools and techniques you can use to bring discipline to track All track delivery approach
  • Embrace agile, lean and design thinking mindsets and tools to bring different disciplines together rather than - respect these approaches and disciplines, involve them rather than trying to change them
  • Have a simple agreed set of language and agree at the heart why we do the work you do, based on 'Why' not 'What'
  • Understand Why you do do and focus on the principles not on what you do and the practices
  • Your agile coaching cohorts are Product and UX, work with them to enact change

Attachments:

Speakers

Wednesday August 8, 2018 16:30 - 17:00 PDT
Torrey Pines Room 1, 2, & 3
 
Thursday, August 9
 

09:00 PDT

Self-organizing competency building and practice sharing with a group of 12 Agile Coaches (Gerrit Lutter)
Limited Capacity filling up


Abstract:
By now there is a good body of knowledge on how teams can self-organize to do their work. But how about groups that aren’t teams? How might they profit from self-organization? How might they find ways to collaborate better, build competency and share good practices?
This experience report reflects on the journey of the Agile Coach group at idealo, one of Europe’s largest price-comparison platforms. With 12 coaches and about 280 people in the product and development department, there are plenty of lessons learned. The report will reflect on how the need for new solutions came about, how they serve us today and how things might evolve in the future.
In doing so, it will also build on the author’s experience working with Scrum Master teams in three other organizations. The lessons aren't exclusively for Agile Coaches, but for other working groups as well.
View the Experience Report

Lessons Learned from Your Experience:
  • Wanting to work Agile outside of a regular (development) team can quickly lead to a cargo-cult
  • How we found our nearly perfect format to discuss all relevant operational topics with 12 people in less than an hour each week
  • Forming smaller groups (Communities of Practice) within larger working groups will get everyone closer to meeting their needs
  • Agile Coaches are a diverse group, but maybe quite similar in some regards (which might make it hard to form a team)
  • If you want to collaborate with other Agile Coaches, be clear about the desired outcomes of that collaboration

Attachments:

Speakers
avatar for Gerrit Lutter

Gerrit Lutter

Agile Coach, idealo
Agile Coach, Scrum Master, Facilitator, Mediator, Coach


Thursday August 9, 2018 09:00 - 09:30 PDT
Torrey Pines Room 1, 2, & 3

09:45 PDT

Agile Transformation Spurred Innovation and Development of Value Delivery Operating Model (Cherifa Mansoura, Andre Ferrell)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
How do you successfully transform the culture of an organization hesitant to change? What do you do when an organization has decided to change and innovate at the same time? Thinking about innovation, while undergoing an agile transformation, is a daunting challenge for any organization. However, it was a challenge Acme Corp Information Services decided to tackle in 2015. The report describes Acme leaders’ journey in developing a framework that fosters value delivery.
The experience report will focus on how Acme agile transformation journey evolved from adoption to developing and implementing a value delivery model, known as the Value Delivery Operating Model (VDOM), while being an early adopter of agile within Acme group. The report and presentation will highlight the key components of the VDOM framework.
In addition, the case study will detail how:
  • Acme brought together disparate practices and disciplines into a clearly defined enterprise framework for guiding customer value conversations.
  • The enterprise framework was developed to facilitate the transformation through the submission of an idea to a triage, innovation and into a product.
  • The framework was designed to improve leaders’ ability to create more value added in new and existing products and services.
Moreover, the presentation will articulate some concrete advice and systematic guidance concerning the “what”, “who” and “how” questions related to value management will be addressed in this case study review. Furthermore, in addition to the VDOM, a leadership triangle supporting the framework was necessary to develop for additional roles and for the scaling of existing roles.
View the Experience Report

Lessons Learned from Your Experience:
  • Using an existing framework or coming up with your own customized one requires vision, collaboration, and patience across the organization
  • Effort and a commitment to delivery are essential attributes when the team members are not dedicated resources to one product.
  • Getting team members to change their thinking that developing VDOM was not extra work but a part of their daily assignments
  • It is “okay” to customize agile and other value models to fit your organization. However, it is also “okay” to challenge existing practices and even change practices to become more efficient and effective
  • Involving leaders from the organization is crucial and allowing them to own their model is even more important
  • A framework developed by the leaders lead to a better result than engaging external consultants who worked in a silo.
  • Using agile practices to facilitate the development in the VDOM challenged the leaders to work together differently and more collaboratively.


Speakers
avatar for Andre Ferrell

Andre Ferrell

Business Analyst, Allegis Group, Inc


Thursday August 9, 2018 09:45 - 10:15 PDT
Torrey Pines Room 1, 2, & 3

10:45 PDT

Scaling agile development across loosely coupled teams using microservice architecture (Anastas Stoyanovksy, Steven Pritko)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
The topic of this talk came about naturally from a 6+ month project in collaboration between IBM Watson and IBM Research in which we had to find an efficient way for engineers to be able to iterate on system design while researchers iterate on the state of the art, without losing significant time to friction in the process itself. In this session, we share our approach to scaling a scrum-like development process across teams with different incentives and backgrounds, in our case research and engineering teams; by designing and implementing a microservice-based system architecture in which concerns that are specific to or play to the strengths of one team are hidden behind component boundaries with simple RPC APIs, such loosely coupled teams were able to effectively work together to deliver a cohesive, state of the art product. Although we took this approach to enable collaboration between research and engineering teams and will discuss some points specific to that situation, we believe that the approach generalizes to collaboration between teams that generally have different disciplines or specializations; we discuss lessons learned, observe useful patterns, and derive principles to generalize the approach.
View the Experience Report

Lessons Learned from Your Experience:
  • Designing a microservice architecture suited to cross-team collaboration
  • Requirements for teams with different incentives to be able to work together towards a common goal
  • Emergent error conditions arising from the complexity of a microservice architecture developed by two separate teams

Attachments:

Speakers
SP

Steven Pritko

Senior Software Engineer, IBM
AS

Anastas Stoyanovsky

Senior Software Engineer, IBM Watson


Thursday August 9, 2018 10:45 - 11:15 PDT
Torrey Pines Room 1, 2, & 3

11:30 PDT

Scaling at Food-tech Startup: Transformation Challenges, Lessons Learned and Growth (Nari Kim, Hyunjoon Cho)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Our scale-up Journey was a roller-coaster ride, Scrum to Waterfall to Agile
I have been a Scrum Master for three years at food-tech startup in South Korea, one of the most competitive markets in the world. Since then, the company has grown explosively through mergers and acquisitions. Our tech organization faced drastic changes in the way of working and culture. I hope you will taste the real-world practices when a startup scaled up and see how our tech organization has evolved at each stage of the progress.
View the Experience Report

Lessons Learned from Your Experience:
  • Working at a startup means that you will always face challenges. So, it is highly essential to adapt to the rapidly changing environment and have a growth mindset.
  • Increasing employee engagement is the key to organization health at every level. A retrospective is a powerful tool for boosting communication and cultivating a culture in the organization.
  • To integrate two cultures after a merger, it is strongly recommended that you set the cultural integration strategies and define what culture you’re trying to build at the very beginning. Otherwise, it might be too late.
  • A top-down direction of the need for change is not sufficient. It is required that you promote bottom-up involvement continuously to make progress in organizational transformation.
  • Last not but least, a scrum master role and responsibility at a startup can be transformed into a Project Leader or developed to an Agile Coach according to organizational growth and continually changing environment. Sometimes, this might be confusing when it comes to making other people understand clearly about your role. From my experience, I would like to suggest that being open-minded and trying to define and shaping your core capabilities rather than sticking with titles are the valuable takeaways when working at a startup.

Attachments:

Speakers
avatar for Nari Kim

Nari Kim

Scrum Master, RGP Korea
I am a Scrum Master with 9 years of professional experience in product planning, project management, and Scrum. My scrum journey started in 2014. Since then, my career transition began from being a project management professional to a Scrum Product Owner. I expanded my career as a... Read More →


Thursday August 9, 2018 11:30 - 12:00 PDT
Torrey Pines Room 1, 2, & 3

14:00 PDT

When Agile and Lean Converge – The IT Transformation at American Electric Power (Joe Astolfi, Gregory Dartt)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Many organizations are using agile frameworks to enhance their solutions delivery. Others are leveraging lean to improve their processes and practices. But how many organizations have combined both a large agile adoption and an enterprise lean initiative to become a flexible, responsive organization built on continuous improvement? And what happens when the implementations of the agile and lean practices conflict?
Joe Astolfi and Greg Dartt are members of the Agility Services and Coaching Team at American Electric Power (AEP), a Fortune 500 utility company. They will take you on a journey of AEP’s agile adoption in IT over the past 9 years, and its convergence with AEP's enterprise-wide lean implementation. You will learn how the logical union between the two disciplines turned into a battle of philosophies at the team level. As tensions rose between the agile and lean experts, ways to resolve the conflict were required and developed for the continued growth and success of the organization. And on the positive side, you will learn how the implementation of lean greatly increased the adoption of agility across IT.
Learning Outcomes:
  • Learn where the agile and lean implementations conflicted at AEP, and the techniques used for resolving those conflicts
  • Understand which lean practices were especially damaging to agile values and principles, and how the heightened tensions were diffused
  • Learn how the agile adoption across IT was accelerated by leveraging lean practices, specifically a lean management system
  • Explore the way lean language made agility more accessible to management and business partners
  • Identify ideas you might try at your organization to gain greater momentum in your agile transformation
View the Experience Report

Lessons Learned from Your Experience:
  • Even though agile has its roots in lean, there is a divergence of practices and implementations that create the potential for tension and conflict. In our case, the lean consultants wanted to see standard work implemented at the team level, creating visual process adherence and visual process performance measures for management. I, and my agile colleagues, resisted the notion of penetrating teams with standard work to protect the desire for self-organization and innovation. We executed Kaizen events staffed by team members to work through the differences and arrive at workable solutions, and then the solutions were piloted by a subset of chosen teams before they were proliferated across all teams.
  • The lean consultants wanted us to visualize the Scrum team's plans, and their progress along those plans (which took the form of Release Burn Up charts). They also wanted to highlight the abnormal condition when the team was no longer 'on plan', and create a discussion with management on how they would get back on plan. With Scrum teams, the plan emerges, and the plan changes based on emergent factors in and around the team. This created some of the highest tension and misunderstanding between the agile and lean experts, and we needed significant discussions and shared understanding to come to resolution. Unfortunately, there were winners and losers in this fight.
  • Pairing the agile transformation with a larger enterprise initiative created additional momentum for our agile adoption. Our CIO volunteered to be one of the first areas in the corporation to embrace the lean initiative. We tied our agile adoption to that larger initiative by marketing Scrum as our implementation of lean in IT, and value stream mapped our process from IT demand to delivery of solutions. When the to-be value stream map was created, it resulted in every IT team schedule to utilize agile frameworks to deliver to our business partners.
  • Using common language made agility more accessible to management and business partners across the enterprise. Since the agile transformation was being mostly led from the IT group, other areas did not know or understand the language or practices. However, when we began to speak in terms being used by our enterprise lean initiative, the management and business partners more readily understood our new way of working. It helped create shared understanding between the Scrum teams and other parts of the organization.

Attachments:

Speakers
avatar for Joe Astolfi

Joe Astolfi

Director, Agile, NiSource
Joe Astolfi is the Director, Agile at NiSource, where he works with others to be great leaders, increase their agility, and find joy in their work. He is also the Vice-Chair and a Board Member of the Central Ohio Agile Association, and an adjunct professor at Miami University. Joe's... Read More →


Thursday August 9, 2018 14:00 - 14:30 PDT
Torrey Pines Room 1, 2, & 3

14:45 PDT

ExxonMobil: False Starts, mis-steps, and the emergence of something great (Michael Adrian, Jeff Rosenbaugh)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
ExxonMobil has formally been on a journey in pursuit of agility since 2012. In that time, we've pivoted multiple times as we've understood the complexities of transforming a large enterprise with over 140 years of history. As we've worked the transformation, we've found that with a 6,500 person IT workforce, certain tech stacks dating back to the 1960s, and a large global footprint brings specific challenges that have forced us to forge our own path. We have had to learn to embrace our culture, understand our own organizational limitations and peculiarities, and reshape our expectations for how we're going to be successful over the long term.
In this report, we'll highlight where we've been, how we've had to approach this change differently than others in our history, and what we'd do differently if we could do it all over again.
View the Experience Report

Lessons Learned from Your Experience:
  • Understanding the complexities of a VERY old enterprise
  • Management support is not a binary thing and understanding the political landscape can help drive long-term success
  • While many have wanted us to, we cannot transform the entire company at once and certainly found ourselves in a very bad situation with too much transformational WIP
  • Learning from our loosy-goosy early days, we now focus on making sure we set structure, plans, and non-regrettable steps early in the process
  • ExxonMobil has a cradle to grave hiring strategy (college to retirement, very few experienced hires) which requires a different approach for success
  • As some agile transformations publish that they've lost 30+% of their organizations during the journey, our organization has very little appetite for that
  • Upskilling the organization cannot be done via external hires - management of change and training are major investments ($$$ and time)
  • Changing mindset around valued skills has been extremely difficult (e.g. building internal coaching capabilities has been a significant challenge)
  • Finding others to partner with has been a key!
  • Developing a relationship w/ Target has helped us build our own Dojo, which has been a huge success
  • Working w/ other enterprises in non-tech industries has helped us effectively answer senior management concerns around agile only working "for software development companies"
  • Scaled Frameworks != Salvation
  • We made a decision to use a scaling framework as a basis for discussing transformation at the senior leadership level which has led to some unintended outcomes
  • We've re-focused on "little a" agility and foundational principles, hoping to drive non-regrettable behavior in areas where we cannot commit full-time coaches

Attachments:

Speakers
avatar for Jeff Rosenbaugh

Jeff Rosenbaugh

Transformation Office Manager, ExxonMobil IT
Jeff is a force multiplier who has been accused of having a “larger than life personality” and being a bit of a trouble-maker (though hopefully in a positive context). He’s spent his career coaching on innovation, searching out bleeding edge technology, and evangelizing an Agile/DevOps... Read More →


Thursday August 9, 2018 14:45 - 15:15 PDT
Torrey Pines Room 1, 2, & 3
 

Filter sessions
Apply filters to sessions.