XP2019

Abstract:
Software engineers historically have largely worked alone and in a vacuum on key projects. This has caused problems with transparency, creates knowledge towers, increases technical debt, and stifles innovation. Mob Programming has given Clearlink solutions to all of those problems and created benefits that have been unforeseen during our first two years of adopting the practice. From our experiences, we outline some best practices that will be beneficial to all those who wish to also adopt this technique.

Lessons Learned from Your Experience:

• There isn't a right or wrong way to do Mob Programming
• Mob Programming removes knowledge towers
• Code quality dramatically increases with multiple set of eyes always monitoring coding standards and techniques
• Significant decrease in technical debt and rework because work is getting completed correctly the first time
• Increased innovation and creativity occurs when engineers constantly brainstorm better ways of doing things
• An amazing team culture where everyone has respect for others no matter where they are in their career

Abstract:
SimCorp has been a SAFe shop for 3 years, with 550 people in 55 teams and 7 ARTs, across 4 locations. In our pursuit for continuous improvements, we've been experimenting with team self-selection in parts of the organization. This experience report will present some of our learnings from these experiments, both what worked for us and what turned out not to work so well.
This experience report will include our recommendations, which include prerequisites for team self-selection and a suggested game plan for how to run team self-selection workshops and pitfalls to avoid

Lessons Learned from Your Experience:
Before team self-selection:

• Team self-selection requires preparation and the people involved in the process should engage and co-create the process the product backlog needs to be well prepared (as always) and known to the people assuming so people will know what tasks the teams should be able to perform.
• Information on the process needs to be communicated early.
• Co-create guiding principles of team composition (distributed, skills,...)
•  Appoint someone to act on your behalf if you're not in attendance
• Generate a competence and preference sheet to be used and shared.
• If a person has reasons not to be in team with another person then he should let that person know before the event.

During the team self-selection:

• Use an iterative team self-selection approach and evaluate the teams capabilities to . Continue until the result converge.
• Never conclude a result the same day you have the workshop - give attendants the option to "sleep on the result".
•  Do not use names or numbers to identify intermediate team constellations that can lead to any cognitive bias (could be influenced by cultural context, like team "1, 2, 3,.."; "blue, red,…").
• Be aware of bullying and take a time-out immediately if it happens and address the case.

After team self-selection:

• People do take ownership of the outcome.
• Increase trust in teams.
•  Feedback culture can grow.
•  We have not measured, but assume value generation have increased.
• Team self-selection also has the benefit of eliminating corporate politics and power struggles related to who should decide on team compositions. The process is 100% transparent and the only thing managers need to agree on is the guiding principles which should provide a clear and objective picture of what the teams are being optimized for.

Abstract:
Many Agile patterns familiar to software developers lead to failure and frustration when applied to hardware development. In this presentation, I describe an Agile transformation I led for Bird Technologies, a company that makes high-reliability radio-frequency communication equipment. Working with teams of mechanical, electrical, and firmware engineers highlighted key differences in how an effective Scrum process differs for hardware development compared to software development. I identify those differences and present effective patterns here.

Lessons Learned from Your Experience:

• The Scrum process framework worked well for hardware development, but some common Agile practices did not.
• Vertical slices of product functionality are not feasible.
• Product Owners do not write many Stories.
• There are no QA people on the Team.
• Swarming is impractical.
• Story Points are not appropriate for Story sizing and Sprint planning.

Abstract:
The Digital Media division of National Public Radio (NPR) recently went through a period of growth that required scaling up its small sysadmin team to an Agile DevOps team. Initially, it was very tough for the team to let go of their old, ad hoc way of working and adopt new methods they perceived as “too formal” and “adding unnecessary process,” especially while going through institutional change and team expansion. This experience report discusses how I overcame that resistance to change within the team, why we struggled with our initial choice of the Scrum framework, why we wanted to try Kanban, and how we settled on Scrum plus Kanban as the right fit for a DevOps team working within a primarily Scrum-based division.

Lessons Learned from Your Experience:

• Here are the key takeaways I’d like to cover in my report:
• Too much change at once produced change fatigue and a resistance to new ideas or processes, so I want to share how we overcame that with baselines, clear goals, and phased approaches.
• Another key lesson was the importance of making implicit processes (the ad hoc system of emails, slack pings, “hallway conversations”, and ops cave chats that made up work intake, division of tasks and follow up before Scrum) explicit to demonstrate that establishing an Agile framework actually wasn’t more complex than their current system.
• I also want to stress the value of continuing to inspect and adapt through retrospectives and other channels, as that’s how we learned that Scrum alone wasn’t the best framework for a DevOps team, and how continued experimentation led us to Scrum plus Kanban.
• And finally, I’d like to share a brief overview we set up Scrum plus Kanban to handle our specific DevOps challenges and how it might be adapted for other teams that handle both urgent, interrupt-based work and ongoing project work.

Are you curious about experience reports and how they come to be? – Join us for a discussion open to all led by Rebecca Wirfs-Brock and Steve Adolph (Experience Reports Track Chairs) on what makes for a good experience report and how writing and shepherding work provides value to the community. A special invitation is extended to all experience report writers and shepherds to attend and share their perspectives.

Abstract:
In an organization, a single introduction to an agile way of working is not enough to make teams consistently adopt agile practices. Without maintenance of agility, teams revert back to their initial non-agile ways of working. As internal agile coaches ("shepherd") in a large organization, we are required to "herd the stray sheep" by enabling teams ("sheep") to find their way back to agile practices. But, how do we do that? We followed the journey of a team who once "strayed" but later found their way back by leveraging the team's willingness to change, regular feedback from outside of the team, and an agile community of practice. With the newfound knowledge, we can implement ways to help teams re-adopt agile practices.

Lessons Learned from Your Experience:

• Change agents within the team: In this team, the change was advocated by three of the development team members. One of them knew how Scrum worked in his previous team, another was a very structured person, and the last one was vocal about things that need to be changed. They went the extra mile to find out better practices from outside the team, devised a new way of working, and implemented it. Once the team has strong drivers/agents of change who recognized the teams’ pain points that lead to poor performance, they can influence others to improve the situation.
• Feedback and/or fresh perspective from outside the team: In this team, one of the pain points was story misestimation. No one from the team realized that this was caused by poor planning, that the story was not estimated by the development team. However, the functional manager spotted this out during a one-on-one meeting, in which he told some of the engineers to “find out the answer” at a guild meetup that discussed agile practices. Here, a regular one-on-one mechanism between team members and their functional managers (or someone from outside of the team) could give a fresh perspective and enabled the team to point in the right direction.
• Support system from the organization: A community of practice (“guild”) played a key role in solving this team’s problem. When the team members needed to discuss agile practices deeply, they could always turn to this community by attending the meetups. Agile coaches could also become the support system by providing consultation sessions about agile practices.

Abstract:
Agile transformations are very difficult and time-consuming. Many organizations ask Agile coaches for help and guidance. During this transformation, the Agile coaches take the lead and put an Agile structure to support business agility. However, when the agile coaches leave, the organization tends to fall back on old habits.

In an interactive session, I will share my experience on how to cultivate an Agile transformation and make Agile coaches obsolete. This is based on real-life example, in which I was the Agile Coach.

Lessons Learned from Your Experience:
Improvements & Lessons Learned
I have learned a lot about the organization, the Scrum Masters and about my self during this journey. I will elaborate on the most important ones below.

•  Why it is important to stop having Agile Coaches doing all the work
•  Why filling in every gap in the organization slows the transformation
• how to help Scrum Masters realize they are to be the change agents
• Find good professionals who can support you to stand on your own
• What does it do to an Agile coach once being obsolete

Abstract:
Many agile transformations start life at the top with executive leadership buy-in and then creation of training timelines to move changes down and across the org. In this case study, we'll share a different approach taken by two coaches who, with initial blessing from leadership, decided to work with five line level teams just where they were, and to help them chart their own path towards scaling agile. Over the course of one full work week, instead of running through a prescribed set of training decks, the coaches offered up a buffet of agile and scaled agile resources for the teams to sample and discuss. This approach required just-in-time coach collaboration and improvisation, with nightly pivots and adjustments to the focus for the following day. The only plans fixed upfront were a kickoff session with leadership, and a scheduled playback session for Friday afternoon where the teams would share their learnings with upper leadership and then make their case for the scaled agile approach they wanted for themselves.

Abstract:
Agile transformations are difficult. People must learn a lot of new things. They need to conform to new frameworks, new processes, new ceremonies, new artifacts and new approaches to their work. And while most of these make up the mechanics of Agile, implementing them may not make that big a difference in how a team delivers. To make a real difference, and to get to true Agility, we need to transform team members away from legacy cultural thinking to new Agile mindsets. We classified the most prevalent legacy mindsets to come up with a plan to change them. We made the decision to make the annual performance goals the new ‘Agile Mindset’ goals. We also came up with related goals for the people leaders such that we could reinforce the new mindsets from both bottom-up and top-down. Each of these goals tied directly into the corporate strategic themes, and is tied to merit increases. We believe by institutionalizing these behaviors in the annual goals, we aim to minimize the potential of introducing conflicting priorities between our new direction and legacy momentum of the past.

Lessons Learned from Your Experience:

• Cultural issues and legacy behaviors can be more ingrained, pervasive and detrimental to Agile transformations than imagined. Organizations transforming to Agile need to be prepared to consistently and effectively deal with transforming from legacy to Agile mindsets and behaviors. Using annual performance goals to reinforce Agile mindsets and behaviors can be a valuable tool to prevent backsliding.

Abstract:
Have you heard about When life gives you lemons, make some lemonade? Call it transformational challenges, difficulties, or even adversities; we encountered many types of lemons as part of our organizational transformation from when we were a small company to when we were part of one of the largest enterprises in the World! Trust me, each time, we sliced those tough lemons and made them the sweetest, and of course, the most memorable lemonade or rather, the most exciting professional journey of my life.

Interested to hear more?

As a person who went through at least a handful of mergers and acquisitions and organizational transformation in our company, I gained firsthand experience and insight into some of the difficulties that companies face as part of their transformation.
As part of this talk, I would like to humbly share our unpublished detailed experience representing our novel leadership stance with examples of our challenges, observations, and reflections. Our goal is to share, exchange and inspire you by inviting you to take on this exciting roller-coaster journey of enabling operational excellence and improving employee development, satisfaction and retention over the last seven years.

Growing Pains! Sorting our ducks in the row!

During this talk, you will learn about our foundation chapter. The most important chapter of our transformation, which started with empathy. As a small company, we got acquired by one of the biggest software companies in the World. I will share with you the transformation in our roles and responsibilities, as well as development processes and practices.
As part of this talk, I will share that when you believe in the Agile values, how that toolboxes can help you in any transformation.

Lessons Learned from Your Experience:
We present our topic in a way that you will leave the sessions with the following inspirational takeaways:

• What was the most critical learning of these seven years? How did we leverage our Agile mindset and toolbox to help us navigate, embrace and succeed in our transformational challenges?
• How did we deliver value incrementally and experimentally throughout the organizational transformation?
•  What was the role of diversity and inclusivity in our team? How did our DNA enable each person to bring a different and valuable perspective to the table? How did we embrace different working cultures and locations? How did we innovate?
•  How did we stay focused and prevented endless philosophical discussions?
•  How did we intentionally and carefully create and define our own culture in our team? How did we remain open, transparent with a high level of energy? What was the value and impact of such culture as part of this transformation? How did we embrace our differences and conflicts?
•  What was the value of having a big picture throughout this journey?

Abstract:
Organizing effectively to deliver great end user services in the digital age is often a challenge for well-established, complex organisations. It often requires a significant transformation in how people work and how teams collaborate. In New Zealand, the Department of Internal Affairs (DIA) and Assurity Consulting have partnered to set up the Service Innovation Lab (SIL) as an experiment, with the aim of seeing what value can be gained by creating an innovation environment with support from coaches to help teams work in new ways. The ultimate mission is to help raise the level of collaboration across agencies in delivering better services to New Zealanders.

We feel that innovation alongside an organisation is where some real transformation of mindsets and cultures can be brought about. That’s why we’re excited about SIL as an experiment. The findings should help us find truly sustainable ways to transform how we deliver and refine services for New Zealanders. We’re also very proud to share the findings of our SIL work in Wellington. We hold regular Open Lab events for people to come and see for themselves and feel one of the great outcomes from the work is the pooling of lessons from visitors to the Lab.

Lessons Learned from Your Experience:
The SIL experiment was modeled on what we believe is the DNA of successful digital organisational cultures. This means that when teams come to the Lab:

•  everyone commits to a set of design principles that shape how we work together (more on this in the next few weeks)
•  work is done in the open and everyone is located in a collaborative space, set up for multi-disciplinary teams
•  there are a range of coaches available to support teams to get better at delivery
• governance groups meet here and get to connect directly with the delivery teams and their work

We hope that the Service Innovation Lab work we’re doing is one part of the solution. We believe it will certainly help move Integrated Service Delivery in government forward at pace here in New Zealand. We look forward to sharing more about this as we continue the experiment with the Ministry of Education of New Zealand.

Abstract:
Agile Test is still a practice not well solved in the agile teams. The theory is beautiful, consistent and accepted but when you see in the practice, the hard work to implement leads the teams to leave that.
The difficulties are very close: frameworks not so easy, non-adherent culture, lack of technologic support, lack of technical knowledge, too much legacy code, too much time to run all tests, and so on.
This session will show a way to cross these difficulties, addressing every issue with real cases of agile and automation test, learned past 20 years of experience. And working on a legacy, critical, giant system and scaling teams.

What did work? What didn’t? Where did we have to invest? Is there any shortcut?
It is a history that will benefit technical developers, managers, and agile enthusiasts since it shows how attitudes make the difference when talking about overcoming obstacles and evolving.

Lessons Learned from Your Experience:
During the presentation, we expect to answer, in a practical approach, questions such as:

•  How many automation is really needed?
• How to structure the team?
• How to deal with integration tests and external systems?
•  How much of each kind of test implement, considering unit, functional, integrated, and UI?
• What relation you have between investment and quality increasing?
• How to obtain better execution efficiency, considering technical aspects?
•  What about when running on a single machine is not an option?
• Consider yet, having to scale more and more?
• How to deal with complex scenarios where the solution depends on the timeline?
• How to improve the performance of tests that depend on the data population?
• What happens if you decide to change the development language along the way?
• How to deal with intermittent test results?
• And testing concurrency?
•  How to automate tests with production data, combining performance and production settings?

Abstract (delivered by video on an exceptional basis):

Dodo Pizza IT team grew from 2 developers serving one country to 60 people serving 11 countries over the course of 7 years. I rebuilt our processes and implemented some engineering practices, but this was too slow. It was not clear how to organize the quality work of several teams on a single product.
We are too carried away with the development of business features and have accumulated too much architectural technical debt. When marketing launched an advertising campaign in 2018, we couldn’t stand the load and fell down. It was a shame. But during the crisis, working in an extreme mode, we realized that we can work many times more efficiently. The crisis has pushed us towards revolutionary changes in processes and the rapid introduction of best-known engineering practices.
After the crisis, we took the LeSS framework as a basis and imposed a number of engineering practices on it. Some of them worked perfectly, while others did not. For example:

• Try: Feature-teams
  During the crisis, we worked in teams that made a feature from start to finish and were not dependent on anyone. It was great. After that, most of our teams are cross-functional and cross-component feature-teams.
• Avoid: Unstable teams
  During the crisis, the composition of the team was chosen for a specific task. But we quickly realized that it was much more comfortable for developers to work in stable teams.
• Try: Stop the line
  The more changes you make between releases, the more risky each release is. We stop development if the release takes more than 48 hours and focus on eliminating the causes of the delay. Over several stops, we significantly stabilized and accelerated the deployment pipeline.
• Avoid: Bug fixing team
  Previously, we had a separate team for bug fixing. Now, after introducing the practice of Zero bugs policy, this team become redundant.

We have built an efficient process in which 9 feature teams work on a single product in a common code. We learned how to combine business development and gradually improve the quality of code and tests. We split the monolith into microservices and use the DDD approach. Our process has not yet been settled, so we continue to experiment with engineering and process practices. But we firmly know that the focus on technical excellence is a guarantee of the stable development of our business.

Lessons Learned from Your Experience:

• Engineering practices protect business from crisis
• Do not accumulate technical debt. It may be too late and cost too high.
• Evolutionary changes take several times longer than revolutionary ones.
• Crisis is not always a bad thing. Use crisis to revolutionize processes.
• However, a long evolutionary preparation is required in advance.
• Do not blindly implement all the practices that you like. Some practices are waiting in the wings, and when he comes, the teams will use them without resistance. Wait for the right moment.
• Over time, the teams themselves begin to make strong decisions and implement them.

Abstract:
Transitioning a growing development team into smaller, mission-oriented sub-teams is challenging, particularly until a collaborative decision making process for shared concerns is agreed upon. Within the framework of XP, we hypothesize that this challenge comes from a fracturing of shared understanding as those sub-teams form and storm. In order to navigate this process and re-establish that shared understanding, we took inspiration from Robert's Rules of Order, Newly Revised (RONR), which is the most widely used manual of parliamentary procedure in the United States.

Some of the specific inspirations we drew from RONR were to establish a formal charter and bylaws, treating our wider development team as a formal organization; we reimagined and redefined these and other formalities in terms of Agile ceremonies and XP practices. We will describe the integrated framework we developed and will share our experience implementing it at IBM Watson to foresee and ease organizational growing pains, accelerating the onboarding process and allowing our organization to grow more effectively.

Lessons Learned from Your Experience:

• By the end of the session, attendees will have a better sense for how growing teams can establish guidelines for decision making to ensure better communication and knowledge sharing.
• A historical view of the evolution of self-organization of groups that have shared values or goals.
• Example rules of order guidelines that they can take back to their teams.

Abstract:
Everyone has a different Agile journey. But there is one similarity in that the journey (i.e. the learning) never ends.

The importance of this NeverEnding story cannot be understated as Agile continues to evolve. Today's Agilists need to find creative ways to continue their learning and provide learning to others.
These learnings can be described in 5 key areas with each learning area representing an opportunity for Agilists to further their knowledge.

We all know that learning can be an immense time commitment. In many instances the financial commitment is just as important but gaining approval can be difficult. Both time and financial commitments are necessary to fully appreciate the 5 key learning areas:

• Individual
• Intra-Team
• Inter-Team
• Within the Organization
• Outside the Organization

The Agile Manifesto was written almost 20 years ago. If Agile were a fad, it would have surely died by now. Instead, it has continued to evolve and 5 years from now it will look much different than it does today. That is why it is so important for the learning to continue. The further you fall behind, the longer it will take to catch up. Learning doesn't have to be an onerous process. Making it part of your daily life ensures the learning continues and makes it more fun.

Lessons Learned from Your Experience:

• The learning never stops because you'll never know everything.
• Agile will continue to evolve so you need to find creative ways to keep up.
• Individual learning is important but it's not enough.
• One of the best ways of learning something is not only to practice it but also teach it to someone else.
• Everybody learns differently.
• Strong leadership is required to foster a culture of learning.
• You need to figure out which methods to apply to the learning areas because it will be different for everyone.

Abstract:
We developed native mobile applications with the same feature set across three platforms: iOS, Android and Windows Store. Nine months into the development of iOS and Android; you’re tasked with delivering the same feature set with half the engineers and you only have seven months. All three need to be released around the same time.
Half the team and half the time – How we used XP to deliver feature parity in 25% of the developer hours.

Lessons Learned from Your Experience:

• Adoption of different is hard. We released feature parity with only 25% of the developer hours using very different coding technical practices. There is resistance by others to even try writing code this way. Simply showing it CAN be faster and better isn't enough for people to try something different.
•  I believed XP, OOP, and refactoring combined could accelerate a product timeline before taking on this product. Delivering in 25% of the developer hours proved that they can. It takes A LOT of discipline to do it though.
•  There needs to be a strong and core set of hands-on-keyboard technical practices that work together to produce highly maintainable code. The ones we identified before and found during keep complexity out of the code.
• An amusing lesson learned to me is how design patterns just ‘appear’ in the code. I learned that you don’t plan structure around design patterns, you improve structure when you recognize a design pattern emerging