Loading…
Agile2019 has ended

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Experience Reports [clear filter]
Monday, August 5
 

10:45

Stop Spinning your Team's Wheels, It's time to revisit your working agreements! (Alex Kanaan)

Abstract:
Are your Agile teams disengaged and failing to meet their commitments? Are you spending too much time in endless meetings? Has collaboration eroded between remote team members? Then STOP spinning your wheels, it’s time to revisit your working agreements! When effective, working agreements create a social contract that helps a group align on what matters most to them as a team.
As an internal Agile coach for a Financial Services company, I started to coach a globally distributed team. While they were dedicated individuals, they struggled to collaborate and failed to meet commitments. Upon attending several ceremonies, I observed only a few people speaking and many perspectives were not being heard. In particular, the offshore tech lead was speaking on behalf of that entire team! There had to be a better way to make everyone feel safe enough to engage and share their opinion. What the team needed were meaningful working agreements.
This was not as easy as you think. The struggle was creating an environment, where ALL team members would feel their opinions and contributions made a difference. Then a thought occurred to me, “One of the reasons the team has been failing was that they didn’t observe scrum values, so why not use those as the basis for rebuilding new agreements?” This aha-moment proved to be a turning point for the team to focus on addressing what matters the most to all. The exercise revealed many hidden barriers. As a result, the team established a new sense of trust that respected each other's culture, boundaries and abilities. This made them value each other’s contributions and as such their collaborated improved to the extent they were much better at delivering on their commitments.

Lessons Learned from Your Experience:
  • Working agreements can help align teams in terms of expectations
  • A team needs to derive their own “meaningful” working agreements, that everyone so can own and commit to them
  • Leverage the 5 scrum values to facilitate working agreements ideation by the team
  • A well-facilitated session helped my team come up with their meaningful agreements and uncovered hidden cultural blockers
  • Remote teams in particular benefit from working agreements
  • Working agreements may need to evolve over time

Attachments:

Speakers
avatar for Alex Kanaan

Alex Kanaan

Agile Coach, USAA
IT Leader, Portfolio Manager and Business Agility consultant with expertise in transforming organizations to Agile using Scrum, Kanban and SAFe. Over 15 years engaging IT and business leaders to deliver complex projects globally with fortune 100 companies including Accenture, Microsoft... Read More →


Monday August 5, 2019 10:45 - 11:15
Chesapeake 7/8/9

11:30

Eureka – How agile helped me to sell crazy ideas to the business (Xavier Lucas)

Abstract:
Have you ever faced an issue as a customer of a company, and then got an opportunity to resolve the issue as an employee of that company?
11 years ago I was a frequent traveler with Alaska Airlines. I was happy to have earned my elite status with their loyalty program, and was looking forward to use the benefits immediately. However, I was left disappointed, as there was an issue with the Loyalty system, which meant I had to wait to use my elite member benefits. As a high value customer I was upset, and called Alaska Airlines customer care to let them know about my frustration.
Fast forward six years, I joined with Alaska Airline as an employee. Guess what? The team I joined and am currently working in is the “Loyalty team” which manages Alaska Airlines mileage plan program. And more? Things are the same, with how the loyalty system works. Could I act on the issue I faced as a customer? NO. Could I work on a crazy process improvement idea or customer experience improvement ideas I had? NO. As a member of the development team(last in the chain of command) I had no power to take my ideas or solutions forward. Work life with Alaska Airlines moved on in a normal pace, without my ability to address customer and business process issues I was passionate about.
Three years later, our eCommerce division chose Agile methodology as our software development process . To be honest, like many other people, I hated it in the beginning. People say agile is a mindset. As I was going through the agile mindset transformation I slowly realized the empowerment it brings to me and to my team. I became vocal in the agile sessions, I actually transformed from an introvert to an extrovert. Agile gave me a safe environment to share my ideas to my team and then as a team sell those ideas to business. Agile processes encouraged me to do small experiments with my ideas. It gave me and my team a seat at the table, we had a say in what we want to do and how we want to do it. With the Agile team structure and mobbing development process we adopted, suddenly the onus of success or failure fell on the entire team, this gave me enormous confidence and also a safety net. I witnessed a personal growth in me and in my teammates.
In this session I will take you into my agile journey. I will share my experience about how agile helped me to transform into a better employee, better teammate and better person.

Lessons Learned from Your Experience:
  • • Agile process actually empowers teams and gives people a seat at the table.
  • • Working as an unified Agile team provides a safety net for experiments.
  • • It is important to gain product owner/stakeholder confidence prior to making/proposing big changes.
  • • Iterative deliverables are less riskier and easier to get feedback on.
  • • Mobbing produces better and effective results.
  • • Self-organizing is the key to become a high performing Agile team.

Attachments:

Speakers
avatar for Xavier Lucas

Xavier Lucas

Staff Software Development Engineer, Alaska Airlines
I am a strong believer in starting with “Why”. I love solving customer problems with innovative solutions. Making process improvements and designing simple systems brings me joy. Agile mindset is the key to my success.


Monday August 5, 2019 11:30 - 12:00
Chesapeake 7/8/9

14:00

Scaling agile for larger electronic health record based initiatives (Vaishnavi Kannan, DuWayne Willett)

Abstract:
With rapid evolution of healthcare knowledge, best clinical practices, and care delivery methods, how can the electronic systems underpinning modern healthcare delivery keep up? Over the last decade, use of Electronic Health Record (EHR) systems became nearly universal. Large EHR vendor software systems now pervasively support multiple workflows: clinical, operational, and financial. So given the rapid pace of environmental change in healthcare, how can one best innovate and adapt on top of one of these vendor EHR platforms?
Agile methods increasingly enable rapid-cycle, responsive configuration and evolution of EHR features (such as clinical decision support tools) by individual teams. But can scaling agile EHR configuration in a healthcare organization leverage principles proven effective in scaling at other types of organizations? In this report, we describe our experience scaling up agile EHR configuration at a large academic medical center, and share lessons learned in four areas: team collaboration, governance, shared architectural modeling and design, and tooling to support our journey towards scaled agile.

Lessons Learned from Your Experience:
  • Team Collaboration: Pros and cons of shared iteration schedules, shared release schedules, or both.
  • Governance: Coordinating organizational span of a given project/initiative with the corresponding level of EHR and operational governance groups.
  • Shared Architectural Modeling and Design: Value of high-level 1-page scoping models such as Use Case Diagrams, Feature Breakdown Structures, Workflow Diagrams (with nested diagrams as needed) for effective cross-team and multi-stakeholder collaboration.
  • Tooling: Challenges and benefits of shared tooling. Providing visibility into backlog and progress relevant to specific customer subgroups in the setting of multi-stakeholder, multi-jurisdictional governance over a single EHR platform.

Attachments:

Speakers
avatar for Vaishnavi Kannan

Vaishnavi Kannan

Data Scientist (Clinical Informatics), UT Southwestern Medical Center
I am a Data Scientist (Clinical Informatics) and lead Clinical Decision Support Specialist at UT Southwestern, developing clinical decision support features within our electronic health record. I work closely with clinicians and the Medical Informatics group on CDS design and patient... Read More →
avatar for DuWayne Willett

DuWayne Willett

Chief Medical Informatics Officer, University of Texas Southwestern Health System
DuWayne Willett is the Chief Medical Informatics Officer (CMIO) at the University of Texas Southwestern Health System in Dallas. DuWayne led the initial design and implementation of the Health System Data Warehouse at UT Southwestern, and first become a student of agile methodologies... Read More →


Monday August 5, 2019 14:00 - 14:30
Chesapeake 7/8/9

14:45

Transforming Healthcare with Business Agility (Emilia Breton, Daniel Scalfaro)

Abstract:
The cost of healthcare administration is crushing Americans. According to National Institute of Health, it was projected to be $315 billion in 2018. This is we (a major healthcare payer) recognized an opportunity to improve the lives of thousands of healthcare providers and people like you and me by streamlining the provider experience. We originally thought launching a single Agile Release Train would help release software faster, making it easier for doctors and administrators to work with the organization. Turns out, it would take far more than that. In this talk, Dan Scalfaro - Director of Digital IT at a national healthcare payer - and Emilia Breton – Agile coach at Accenture | SolutionsIQ - will share their experience working together over the course of 6 months to establish a powerful communication platform that would ultimately break down barriers that had existed between various business and IT organizations for decades. As a result of our partnership, the organization stands to drastically simplify antiquated processes in healthcare, which all of us benefit from in the form of happier, less stressed healthcare providers.
So often coaches are brought into a group to implement a framework and the group never realizes the results promised by agile evangelists. In order to realize the true power of agility we found that we needed to start with transforming leadership and bringing together people, from across different business and IT silos and groups. We started out looking to launch a train and discovered a diverse and powerful group with the ability to change the face of healthcare now and in the future. Over the course of 6 months we built a new group that cut across traditional functional towers, divisions and specialties to launch a new truly cross functional virtual organization with one focus, removing barriers for doctors and make their experience with the organization easy.

Lessons Learned from Your Experience:
  • Start with Why. Once you truly understand all of the driving factors from the business and IT sides the path becomes much more clear, and crossing the edge for true cultural change is a smaller leap.
  • Never underestimate the power of entrenched power structures, bringing multiple business and IT units together can be new and uncharted territory. It often threatens existing fiefdoms. Be prepared to address those who feel threatened and bring them in as allies.
  • Make sure you identify the people you need to make a lasting change happen, it takes a village, many of them may not be inside your traditional business or IT unit, don't be afraid to seek out the people with knowledge and skills you need.
  • Deep insights can be gained with a piece of string. Visualize the communication lines and relationships between groups and individuals, it will help you identify gaps and bottlenecks so that you can address them.
  • Changing the way an organization works requires far more than a single coach for a brief amount of time make sure you have the coaching support you need. If you want to create sustainable change find allies in business and IT, give them the knowledge and freedom so they are empowered to carry the change into their groups and departments, and let them do the work!


Speakers
avatar for Emilia Breton

Emilia Breton

Agile Coach, Accenture|SolutionsIQ
I am a natural-born Agile thinker who managed to swim out of the PMI waterfall almost a decade ago. As an Agile coach, I am constantly looking for new ways to build better software and make the world a better place. As a passionate gamer I believe that teams who play together can... Read More →


Monday August 5, 2019 14:45 - 15:15
Chesapeake 7/8/9

15:45

Undercover Scrum Master (Dane Weber)

Abstract:
After three years as a Scrum Master and Agile coach, I hit a wall coaching a team that did not want to try popular Agile engineering techniques such as TDD and pair programming. I had become a Scrum Master after four years working on the business analysis and account ownership side of things and could not speak from personal experience about engineering practices. In order to get some first-hand experience and to gain a new perspective, I chose to spend a year or two as a software developer on a Scrum team.
The experience has been eye-opening. I experienced a tremendous cognitive load working with a wide array of technologies; this pulled my attention away from many of the collaborative and process-oriented activities I cared about as a Scrum Master. I was surprised to feel strong pressure to complete work quickly, cutting corners, even when the Product Owner and Scrum Master were not asking me to. When this pressure was explicit, it usually came from my fellow developers. On the other hand, there is real joy in writing code and seeing a system do something worthwhile that it wasn't doing before. My outlook has changed tremendously and is something I want to share with anyone who works with development teams, especially Scrum Masters and other coaches. I am still enjoying my time as a developer, but I'm looking forward to returning to coaching and incorporating this experience into my approach.

Lessons Learned from Your Experience:
  • Modern full-stack Agile software development places a heavy cognitive load on developers. This can be directly helped by scripting, automating, and building custom tools. Refactoring and improving code quality also reduces this load and should be supported. The team's norms and workflow processes may be just a bit too much for developers to memorize and embody. This can be helped by taking the burden off of team members, such as by writing up the rules for stand-up or Scrum ceremonies on posters that hang in the room where the meeting occurs. Adding checklists and templates where possible serves as a reminder and ready-reference for the Definition of Ready or Definition of Done.
  • It is easy for a team/project culture to make developers feel like they should hurry and cut corners. Discussions about velocity, cycle time, expected completion of a feature, burn-up charts, and so forth all lean toward doing more faster. It is also rarely in the product owner's wheelhouse to recommend slowing down and being more careful and thorough. It was important for the team to explicitly talk about how we wanted to do our work well, to celebrate it in each other, and to have the explicit support of our Scrum Master, product owner, and others.
  • Writing code is fun. Getting code to work is a rapid and rewarding feedback loop. No other part of the job has the same immediate payoff. While writing automated tests can be part of the fun and frequently pays off, there are many aspects of it that are frustrating and not rewarding. Explicitly adopting team-wide approaches to automated tests and celebrating accomplishments with standing up or fixing test frameworks serve as good and positive reminders to push through. Similarly, being involved in backlog refinement and other planning activities feels like a short-term sacrifice for a long-term gain. Some people are naturally more likely to volunteer for "chores," so to avoid burn-out and unfair conditions, systems that rotate through everyone spread out the responsibility.
  • Many good practices, like good habits, take real, intentional effort to form. Even if people recognize pair-programming and TDD as good practices, it takes a lot more to become comfortable and skilled such that they succeed and come naturally.

Attachments:

Speakers
avatar for Dane Weber

Dane Weber

Lead Consultant, Excella
@daneweber on Twitter and LinkedIn. Dane Weber sees software systems as an extension of human systems and is passionate about improving both. He is a software developer, DevOps practitioner, and Agile Coach with Excella. Dane helps teams, programs, and organizations improve and adapt... Read More →


Monday August 5, 2019 15:45 - 16:15
Chesapeake 7/8/9

16:30

How Do We Know if a Scrum Master is "Good Enough" for our Teams? (Sarah Baca)

Abstract:
In my current role at Express Scripts, I serve as one of the people leaders for our 100 scrum masters. Since I began this role, the biggest challenge in my mind was “How do we know our scrum masters are doing a 'good job?' And what does it mean to do a 'good job' in our highly contextual roles as scrum masters?"
In this session I will share how we are trying to answer this question, and how it is evolving as we learn more.

Lessons Learned from Your Experience:
  • I've learned some ways to create feedback loops between the scrum master and the team, the team to the scrum master, the people leader to the scrum master, and the scrum master to the people leader. I've learned how important it is to make the expectations clear to scrum masters, coach them, and help them grow.
  • I've also had some experiences with things that didn't work - we originally started out with a survey that went out to the teams, asking them to assess their maturity. The problem is that the teams don't know what "good" looks like. And perhaps they were worried about what their boss would think. So they gave themselves high scores on everything. :( I

Attachments:

Speakers
avatar for Sarah Baca

Sarah Baca

People Leader, Scrum Masters, Express Scripts
I'm a leader and agile coach who is passionate about growing cultures where people feel like they belong and are free to focus on creating a great product for their customers.


Monday August 5, 2019 16:30 - 17:00
Chesapeake 7/8/9
 
Tuesday, August 6
 

09:00

A Practical Look Into Self-Selecting, Distributed Teams (Bevan Williams)
Limited Capacity filling up


Abstract:
Your company acquires a team based in another country. A switch in company strategy requires the formation of new teams. A project is cancelled and team members suddenly need to be reassigned. These scenarios happen, so how do you handle these changes to your teams?
What about having your team members choose for themselves? What if this included your offshore teams and remote workers?
If this sounds like a crazy idea, then this talk is for you.
This engaging and light-hearted talk will be an honest reflection of the experience exploring, introducing and facilitating remote friendly Self-Selection at Travelstart - the largest Online Travel Agency in Africa. I will share the highs and lows experienced from preparation, through execution to where it is now, many months later.
By sharing practical experience and challenges I hope to encourage more companies to give their teams the freedom of self-selection - even when considering remote employees.

Lessons Learned from Your Experience:
  • Self-selection can work with remote teams and team members - While co-located teams are always the ideal, they are not always a reality. Having all team members gather for the self-selection too is also ideal, but again not always possible. For this reason, we made use of specific tools and remote facilitation techniques to run the full self-selection process. I would like to assure people that co-location is not a constraint to having self-selecting teams.
  • Management selection alone cannot cater for the traits needed to build high performing teams - Much has been said, and written about building high-performing teams. Focussing on the work of Daniel Pink's Drive, Google's Project Aristotle and J. Richard Hackman's Leading Teams, we learned that while managers have a major responsibility in driving high performing teams, it's not always possible for them to truly be aware of the inter-personal relationships that affect team performance. This event also highlighted a technical knowledge gap between what was being interviewed for versus what skillset(s) were actually missing. For these reasons, we found that what the management team assumed would be good team structure, was quite different to the reality of what was chosen.
  • Self-selection is not just an event, it will radically change your team's culture and how they engage - Since teams were first chosen as at the event, every subsequent decision or change is always discussed with self-selection in mind. This has rapidly increased the level of ownership teams felt within their roles. Teams _wanted_ to be more involved in hiring, tooling, product and business decisions, etc. This means that as a coach or sponsor, you need to be even more aware of decisions that would affect the autonomy of the team.

Attachments:

Speakers
avatar for Bevan Williams

Bevan Williams

Agile Coach & Trainer, Think Agile
Bevan is an Agile coach based in Cape Town, South Africa. He has been an IT professional since 2009 and has previously worked as a Software Engineer, Scrum Master, Head of Mobile and Delivery Manager. He is passionate about coaching, training, enabling and leading people to do their... Read More →


Tuesday August 6, 2019 09:00 - 09:30
Chesapeake 7/8/9

09:45

Downfalls of Coaching in a Hierarchical Model (Allison Pollard, Skylar Watson)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Companies of size require more than one coach for support. How does an organization know if coaching is worth the investment or not? During transformations, it’s common to structure coaches to focus on different parts of the organization based on their specialties (e.g., technical, executive, business/program), resulting in a hierarchical coaching model. Having a tiered coaching structure reduces visibility between the products’ outcomes and how things are implemented on the shop floor. With specialized coaches touching various parts of the organization, localized improvements may be achieved but a holistic view is lacking. Skylar and Allison found themselves frustrated and feeling minimized as agile coaches working where specialized and hierarchical coaching was the model being pushed.
In other engagements, Skylar and Allison would take a systems view to focus on practices with maximum impact to measurably improve teams and business outcomes by targeting coaching around specific products. Early conversations with a team may center on understanding what success for their product looks like and their current delivery capabilities. An approach of teaching agile practices from an organizational checklist shifts to determining what is preventing the team from delivering more value for the product and teaching techniques that help solve that problem.
Better organizational results can be achieved when coaches focus on helping teams meet their product goals. Skylar and Allison will share their experiences working in a hierarchical coaching model versus a product-based model and what they've learned along the way.

Lessons Learned from Your Experience:
  • A tiered coaching structure can lead to higher coaching WIP and less visibility of measurable results than a product-based coaching model
  • Recognized that our coaching group was mirroring the organization it served based on how coaches were assigned
  • Recognized we needed to change our approach as we struggled to answer questions about what was most important for us to focus on
  • The way a coaching group is organized affects its ability to positively impact the organization


Speakers
avatar for Skylar Watson

Skylar Watson

Independent Consultant
Skylar Watson is a software consultant and owner of SkyNet software solutions where he implements high value software to satisfy customers needs. Skylar works with companies both domestically and internationally providing assistance on adopting agile software practices.
avatar for Allison Pollard

Allison Pollard

Agile Coach, Improving
Allison Pollard helps people discover their Agile instincts and develop their coaching abilities. As an Agile coach with Improving in Dallas, Allison enjoys mentoring others to become great Scrum Masters and fostering communities that provide sustainability for Agile transformations... Read More →


Tuesday August 6, 2019 09:45 - 10:15
Chesapeake 7/8/9

10:45

Towards Agile Autonomous teams with Domain-Driven Design (Kenny Baas-Schwegler)
Limited Capacity filling up


Abstract:
I’ve been involved in several transformations over the years, from DevOps to Digital to Agile. These transformations typically focus on transitioning people into near-autonomous teams of no more than eight people who will work in an agile manner. Every company I’ve worked for asks the same questions at these transformations: How do we divide the current software between the teams, and how do we align these teams to our business architecture?
To address these questions, companies request my help to design microservices using a Domain-Driven Design (DDD) approach. This approach makes it easier to distribute the software between teams based on identified boundaries, called “bounded contexts.” While I believe enterprises involved in an Agile transformation need at least a Domain-Driven Design approach to create autonomous aligned teams with a loosely-coupled architecture, this process presents unique challenges. In this talk I will present my experience report, I share my experience over a period of six months using DDD to transition a financial enterprise towards Agile autonomous teams.
I mostly used what is already in my experience report and rewrote some words.

Lessons Learned from Your Experience:
  • .

Attachments:

Speakers
avatar for Kenny Baas-Schwegler

Kenny Baas-Schwegler

Strategic software delivery consultant, Xebia
A lot of knowledge is lost when designing and building software — lost because of hand-overs in a telephone game, confusing communication by not having a shared language, discussing complexity without visualisation and by not leveraging the full potential and wisdom of the people... Read More →


Tuesday August 6, 2019 10:45 - 11:15
Chesapeake 7/8/9

11:30

Enterprise Service Planning at Optimizely (Keith Nottonson)

Abstract:
Learn how one startup moved from chaos to scrum and beyond by implementing Enterprise Service Planning (ESP) and the seven cadences and visualizing it on an evolving fifty foot wall of work, resulting in an increase in our product velocity while decreasing our time to customer value across multiple products and delivery teams.
Over the past eight years, Optimizely grew from a single product company built by a handful of engineers and designers to a multi-product company built by many teams of engineers and designers. But its development processes didn't adapt fast enough to keep up with Optimizely's growth. Engineers had too many dependencies in flight, designers were added too late in the process to be effective, and the highest value work wasn't properly prioritized. In the last couple of years, we have improved that drastically.
Agenda:
0 - 3 Welcome and introduction to presenter, company, and situation
4 - 7 How we arrived in such a state (2010-2013) and what we did (2014 - 2016)
8 - 13 Implementing ESP and the Wall of Work (2017-2018)
14 - 18 Where we are doing today (2019)
19 - 23 Insights about the seven cadences and visible portfolio management
24 - 27 Key Learnings and Challenges
28 - 30 Questions & Thank you

Lessons Learned from Your Experience:
  • * Understanding that my company was an ecosystem of interdependent services by visually mapping it out and seeing the observed capability of each service
  • * By having a central physical visual information radiator, driving conversations, alignment and insights is much easier than arguing in electronic format
  • * Mapping the seven cadences to our existing workflow and then adjusting/adding feedback loops where necessary was a cinch when I knew where and what to look for

Attachments:

Speakers
avatar for Keith Nottonson

Keith Nottonson

Development, Senior Director, Optimizely


Tuesday August 6, 2019 11:30 - 12:00
Chesapeake 7/8/9
 
Wednesday, August 7
 

10:45

A Report on the State of Agile in India (Deepti Jain)
Limited Capacity seats available

Abstract:
The Indian subcontinent has not seen many successful Agile Transformations. In this report we share how a group of 30 Lean Agile Practitioners and thought leaders from industry came together to better understand why Agile Transformations have not achieved or sustained the results in India that we hoped for. This special report was shepherded by Agile Alliance (under Rebecca Wirfs-Brock), with the intention of bringing out key challenges and success factors for any attempted or possible Agile Transformation in Indian IT and Software Development Centers.

At gatherings all around India, the talk is about different tools, techniques and agile experiences. But many of the experiences are either not from India or only partially achieved here. Agile experiences in India invariably fall short of full-fledged organization-scale self-sustaining irreversible transformations. Most are about rather short-term limited-scale team-level externally-supported “agile adoptions” or about lower-order internal efficiency gains such as faster builds, or higher code coverage, lower tech debt, or quicker deployments. No doubt these accomplishments are important from a product development standpoint, i.e. “building the product right”, as well as a product management standpoint, i.e., “building the right product”.

However, in most cases, any objective assessment or quantitative demonstration of improved agility in terms of market-facing metrics (such as revenue impact, percentage of market share, number of paying customers, etc.) is conspicuously absent! Roles in functions such as product management or user-experience design have only begun to spring up in last few years. So the matter of fact is not many have seen real Agile Transformation in India, and those who have seen it, recognize that scaling it across the organization and sustaining it over a reasonable period of time is a wider and chronic problem.

On paper, it all looked familiar and appeared highly successful. However, given that most organizations were either IT outsourcing operations working per or alongside a client’s given process (often in a tight contract lest there be legal disputes around delivery not matching the specs or project plans), or the so-called GICs (the Global In-house Centers, i.e. the in-house delivery arm for MNCs typically headquartered overseas) working on derivative versions (as opposed to “1.0” problems) or smaller-scale problems (compared to their headquarters) or on “lights on” work, or the Startups that were predominantly in early phases of acquiring or post-product/market fit; it often stood out that the landscape looked very different from the US / West Europe (where the work flowed from, for the most part).

So, to bring out the real state of Agile in India in the open, we (Deepti Jain and Tathagat Varma) called for a Summit—a “Change Agents Summit,” to create an authentic account of the situation.

Lessons Learned from Your Experience:
1) Agile Transformation in India is a far fetched dream
2) Headquarters of these IDCs need to truly invest (and have intentions) to bring true agility
3) There is so much power in the people if they come forward authentically, and so it's important to create a social movement that bring out a real report on Agility and Agile Transformation in India.
4) One such gathering is not enough, but a recurring approach is needed. Hence we have set an yearly gathering called Change Agents Summit, which is also India's first Flip Conference that focuses on

Speakers
avatar for Deepti Jain

Deepti Jain

Agile Transformation Strategist, AgileVirgin
Deepti is an Agile practitioner, experienced in creating, leading, and managing an Agile team in a distributed setup. She is active in Agile community building in India via her initiatives and events. For the past 6 years, her primary focus is on Agile and its Scaling with Continuous... Read More →


Wednesday August 7, 2019 10:45 - 11:15
Chesapeake 7/8/9

11:30

How I tried Holacracy and Lived to Tell the Tale (Sandy Mamoli)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
This is the story of introducing Holacracy at a New Zealand tech company, whose CTO gave me a one-line instruction: “I’d like you to make it happen.”
Come along and learn from our successes and failures from our quest to create a truly self-organising organisation, learn what worked for us and what didn't and find out how we resolved the question of whether we had joined a cult or actually improved our business.

Lessons Learned from Your Experience:
  • 1) Holacracy will amplify the culture that's already in place. It won’t change or improve it!
  • 2) Holacracy, Agile and common sense will make a big difference to companies in the future
  • 3) It’s not about doing Holacracy but about being holacratic!

Attachments:

Speakers
avatar for Sandy Mamoli

Sandy Mamoli

Me, Nomad8
I'm a former Olympian, a geek, a gadget junkie, international speaker and author of "Creating Great Teams - How Self-Selection Lets People Excel". I have a masters degree in artificial intelligence and I know quite a lot about Agile.


Wednesday August 7, 2019 11:30 - 12:00
Chesapeake 7/8/9

14:00

Harvesting Mob Programming Patterns: Observing how we work (Michael Keeling, Joe Runde)
Limited Capacity filling up


Abstract:
We were huge advocates of pair programming and have directly experienced the many benefits of pairing, but when we first heard about mob programming with thought it sounded crazy! Perhaps... so crazy it might actually work. Mob programming is a software development practice in which the whole team works on the same code at the same time. In our experience, mob programming can be significantly better than programming alone. While mobbing, we've created some of the best code our team has ever written faster than the typical code review cycle. We've explored new domains and architectures quickly. We've helped individuals feel more confident in their ability to change the system and built strong bonds within the team. In addition to these huge wins, we've also experienced a few bitter failures. Mobbing can be a tremendous waste of time in some circumstances. Not all mobs can work on all problems. Sometimes people forget how to be a good teammate.
In this report we explore a set of mob programming patterns discovered by two different teams and two different companies -- LendingHome and IBM -- after more than a year of practice. Patterns we found include emergent roles in the mob such as the recorder, researcher, and facilitator, collaboration patterns such as create a punch list and form splinter groups, and driving patterns such as think out loud and asking the mob to tell me what to write. While the patterns themselves proved interesting and useful, we were surprised at how much our mob programming improved after even modest reflection regarding our practice. In addition to the mob programming patterns, some of which corroborate experiences shared by other teams, we discuss the benefits of pattern harvesting as a mechanism for supporting reflective practice and general process improvement.

Lessons Learned from Your Experience:
  • • In the report we explore about half a dozen mob programming patterns
  • • There are many ways "right" ways for a mob to organize and work together.
  • • Patterns can be harvested through story telling and used as a strong feedback loop to improve practice.
  • • We can use concrete examples of practice, such as a patterns catalog, to make it easier for the team to want to try a potentially controversial practice such as mob programming.

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 7, 2019 14:00 - 14:30
Chesapeake 7/8/9

14:45

Small Scale Scrum (Leigh Griffin, Arjay Hinek)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
What if you have less than 3 people available on a project? What if you want to or need to use Scrum? In Agile, Scale is a hot topic, but how does scaling work in the opposite direction? How do you scale down a process like Scrum for teams of 1-2 people and still make it deliver value?
This is a scenario facing a lot of people who want to follow Scrum but don't have a team around them. Take for example consultants working on per hour projects, where customer budget is finite and features over people are prioritised. College students working on final year projects or their thesis area which is a single person challenge. Open Source contributors building and maintaining projects that are powering the Fortune 500 are often 1-2 maintainers. These are some of the scenarios that we faced in Red Hat, all of which can follow an Agile way of work where Scrum’s principles and execution can be applied to small-scale teams; however, they’re often applied in a way that leads to something slipping. In our experience, that is quality. We set out to investigate whether we could maintain a high-level of quality and still have value driven output with a reduced team size. The result of this research is Small Scale Scrum, a long awaited and novel concept in Agile supporting planning, developing and delivering production quality software solutions for 1-2 person teams.
We will share the Small Scale Manifesto, the Small Scale Framework, results of our survey and share with you the successes of running this project in 10 real world projects and finally how we will crowdsource Version 2.0 of Small Scale Scrum by allowing you, the Agile community, to help us Inspect & Adapt the framework.

Lessons Learned from Your Experience:
  • * I realised that Scrum is becoming a de facto choice for running a project but small teams are not equipped to follow it. That this results in both a poor output and an unfair view of Scrum.
  • * Scrum was often used to try and 'get more work' out of a project that had finite budget and people. The biggest slippages were always Quality and Communication. Comms was to be expected but Quality was a surprise as developers are schooled on good practices such as TDD/BDD which were abandoned in small teams
  • * Having a daily standup as a single person brings much stronger reporting and risks or impediments were highlighted at stakeholder level much earlier than the usual approach of waiting several days to try fix it.
  • * Working in such small teams makes any team member much more mentally Agile
  • * I learned the power and value of having a framework to guide tough conversations about value in a time sensitive, resource limited environment.

Attachments:

Speakers
avatar for Leigh Griffin

Leigh Griffin

Engineering Manager, Red Hat, Inc.
Engineering Manager and Agile Coach for Red Hat Mobile
avatar for Arjay Hinek

Arjay Hinek

Agile Continuous Improvement Coach, RedHat
Arjay Hinek has been in project management since the '90s, helping teams, companies, and even individuals apply Agile as a culture rather than a process. While coaching teams, product owners, and management within small startups as well as large enterprises, Arjay has delivered workshops... Read More →


Wednesday August 7, 2019 14:45 - 15:15
Chesapeake 7/8/9

15:45

Building an effective ecosystem for women to excel (Archana Joshi)
Limited Capacity seats available


Abstract:
Globally women in IT are a minority and there is a focus to improve gender diversity at workplace. IT departments practicing agile are no exception to this. So, does agile help when your voice is one of the minority? What does the new momentum towards digital initiatives mean for women in Agile? This talk is my attempt to explore answers to these questions based on the experiences that I had over my 10-year journey as a woman agile practitioner in India. The talk will address 3 key problems across timezone, forums and skills that I have seen more prominently faced by women working in agile teams. Addressing these problems helps to create an ecosystem which will aid not only women but overall teams to excel and thrive:
1. Timezone: Uneven distribution of women in teams due to time zone issues
2. Forums: Insufficient avenues for women to express their views
3. Skills: Adapting the skills of women for the core engineering roles
The lessons learnt will help you deal with your teams - especially women from your teams in a better manner.

Lessons Learned from Your Experience:
  • Lesson 1: Need to create ecosystem where your company management and your clients work together and ensure that diversity is their joint concern. Many times it is seen that while your company may have diversity as top priority, clients may not be ready to do necessary changes to enable accessible work options. This may lead to a step back in your diversity efforts.
  • Lesson 2: You need to provide various avenues for teams to open up. Team members especially women may not voice out the true feelings in regular forums. You will have to explore different avenues like surveys or bringing in women facilitator for some duration to help team open up
  • Lesson 3: Today there are less women with STEM qualifications. To ensure the skills for the women who you have in your organization remain relevant in the future, you need to invest in upskilling programs.

Attachments:

Speakers
avatar for Archana Joshi

Archana Joshi

Head - Transformation, LTI
I have 19 years of industry experience across progressive roles in Software Engineering and IT Transformation. Past 10 years I have worked with organizations and team of varying sizes on bringing in New Ways of working using Agile & DevOps. I focus on the change that organizations... Read More →


Wednesday August 7, 2019 15:45 - 16:15
Chesapeake 7/8/9

16:30

When the Business Wants Waterfall: Adaption Strategies (Marjorie Farmer)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
This experience report will review how the Halliburton Wireline software team managed, successfully or sometimes not, to adopt agile while still complying with the corporate waterfall mandate. The report will cover:
  • What changes we made, with what worked (such as engaging users) and what didn't work so well (attempting the transition without coaching)
  • How we handled compliance with the waterfall process, especially given extensive changes to scope during development
  • How we managed communication with management
  • Agile coaching and what it did for us
  • How we restructured to cover the roles of an agile team, with the challenges and successes involved
  • How we handled integrating agile with the use of offshore resources

Lessons Learned from Your Experience:
  • Key Learnings from the team's experience include:
  • - It's useful to adopt the corporate language, so executives can understand and even sponsor software teams
  • - Find out what leadership means by 'waterfall', and what they consider critical. Check those boxes
  • - Executives aren't usually interested in implementation details. That can leave a lot of room for agile
  • - It's important to pass audits. Know what kind of audits are coming, and be prepared to pass them
  • - Successful delivery trumps everything. Leadership is reluctant to force process overhead such as extensive waterfall compliance on a functioning team

Attachments:

Speakers
avatar for Marjorie Farmer

Marjorie Farmer

Software Discipline Manager, Halliburton
I am giving the Experience Report 'When the Business Wants Waterfall: Implementing Agile in a Phase-Based Environment.' My background is in business process, especially in large, distributed organizations, and in project and program management. I am currently managing a development... Read More →


Wednesday August 7, 2019 16:30 - 17:00
Chesapeake 7/8/9
 
Thursday, August 8
 

09:00

The Sun Never Sets on the Problem Solving Workshop (Steve Adolph, Rochelle Tan)
Limited Capacity seats available


Abstract:
A fundamental agile principle is the team reflects at regular intervals how to become more effective. The SAFe Inspect and Adapt Problem Solving workshop is a wonderful opportunity for everyone on an Agile Release Train (ART) to reflect on becoming more effective. However, what happens when the ART teams are massively distributed, such that the Sun truly never sets on the ART? How do you provide everyone on the ART an opportunity to reflect and collaborate with others who have similar interests? How do you enable all to participate in the problem solving session, to raise and solve problems that are important to them, and not just the problems that are important and visible to "home base"? This is the situation we faced at a large multi-national petroleum company preparing to conduct their first SAFe problem solving workshop. This story describes the practices, the agenda, the tools, and the lessons learned from running an equitable problem solving workshop for a train on which the Sun never set.

Lessons Learned from Your Experience:
  • An agenda for conducting a globally distributed problem solving workshop that creates equal opportunity for all voices to be heard.
  • People do not mind staying up late to solve a problem if the problem is of interest to them and they have the option to participate or not to participate.
  • The problem causing the teams the most pain are often not what management thinks are the problems causing the most pain
  • Managing the logistics of a globally distributed workshop are easily an order of magnitude more time consuming and complex than running a local face to face workshop
  • Even primitive collaboration tools can help you run a distributed problem solving workshop
  • People require additional training ahead of time to run an effective distributed problem solving workshop

Attachments:

Speakers
avatar for Steve Adolph

Steve Adolph

yet another agile coach, cprime
Serial Entrepreneur and Yet Another Agile Coach...I start a company, it fails, I go back to coaching. [repeat]. I've been designing systems (telephone switches, railway signalling) and managing systems development since the days of Fortran and 5 micron CMOS. Over the years I learned... Read More →
avatar for Rochelle Tan

Rochelle Tan

Principal, RTculate LLC
As an Agile Evangelist, Rochelle Tan has over 20 years of experience in agile transformation with small to large organizations from various industries in North America and Asia: Oil and Gas, IT, Finance, Insurance, Government, and Publishing. Rochelle is an accomplished Agile Coach... Read More →


Thursday August 8, 2019 09:00 - 09:30
Chesapeake 7/8/9

09:45

The Rush of Coaching At A Distance - A Year of Remote Coaching for Accenture Learning (Joe Fecarotta)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
Millions of dollars are spent every year on training at Accenture to make our coaches and consultants world class. The name of the organization with this mission is called Accenture Learning, and nearly two years ago they embarked on the journey towards agility. They, like many large organizations, are at the intersections of scale: they have a heavily distributed team and want to be more Agile in their approach.
Co-location has been seen as by some as a litmus test for the seriousness of an Agile transformation, but is it? Can a coach enter the engagement with integrity, knowing that co-location is largely out of the question? I've coached many teams that have had remote aspects to them, so when faced with completely distributed, non-software teams, I jumped at the chance. I saw this as a unique opportunity to learn about remote work and advance my own company by influencing them in an Agile direction.

There are two questions at the heart of this engagement. One, what sort of benefits can a distributed organization expect from an Agile transformation? Second, how did I modify my approach (and continue to) in the year I've been there? I hope you rush to this session to find out!

Lessons Learned from Your Experience:
  • The approach I've taken has evolved and continues to. Normally my stance leans heavily on Facilitating, but with 100% distributed teams I had to rely more on a Teaching and Mentorship stance. Constant change was and continues to be a common theme during this engagement:
  • Travel budgets are always changing - Often remote implementations of agile come with some allocation of travel money, but its a mistake to assume all the budget will be there. Make alternative plans.
  • Your training material has to change - Don't try the same training material you used in class for a virtual training or you'll lose them fast.
  • Coach, your schedule will change - Supporting a global team from my home office has resulted in changes to my personal life.
  • Your approach has to change - Fully remote implementations of Agile require even more patience than co-located implementations. "Everything will be slower" was the advice that I got when entering the engagement.
  • Aggressive Pursuit of Connection - As an in-person coach it's easy to walk and visit the teams, attend their ceremonies, build relationships and gain trust.

Attachments:

Speakers
avatar for Joe Fecarotta

Joe Fecarotta

Sr. Agile Coach, Accenture
I'm currently researching and working in the remote space. How can we advance agility into teams that do not sit together? What enabling techniques can we apply that make for higher performing teams?


Thursday August 8, 2019 09:45 - 10:15
Chesapeake 7/8/9

10:45

Sharing techniques to continuously improve the XP Laboratory (Alfredo Goldman, Viviane Almeida Santos)
Limited Capacity seats available


Abstract:
Since Agile Methods formalization, the software engineering education has also been impacted with universities adapting their courses as a way to suit this new software processes. At the University of São Paulo (USP), there is a discipline called XP Laboratory. Although the name refers to eXtreme Programming, the discipline aims at teaching agile methods in practice, considering several elements that are crucial for providing the student with real knowledge and experience with agile methods. This discipline has provided extensive studies involving students, instructors, mentors, customers, professionals, and companies. In this experience report we intend to share agile techniques that helped us to continuously improve this discipline.

Lessons Learned from Your Experience:
  • We observed that learning is maximized when it occurs in practice with real situations, such as involving customers and its problems.
  • Also, we noticed that it is important to afford the needed infrastructure and offer a learning environment where students can learn from experience in practice and share their past and present experiences to others. Experts are especially involved to support this broad dissemination of - mainly tacit - knowledge to the students. As we do not push to explicit knowledge, we believe that the knowledge flows around the environment. Knowledge is not treated as something that must be always written down, however there is some specific knowledge that we guide the students to state in repositories, such as project and discipline wikis, but most knowledge is shared, though.
  • So, we have adopted practices to share knowledge inside and across teams using organizational learning techniques, such as rotation of team members across teams, mini-lectures at lunch, coding dojos, brainwriting, lightning talks, whole-class retrospectives in fishbowl format, retrospective starfish, etc. These techniques became essential to the discipline success.

Attachments:

Speakers
avatar for Alfredo Goldman

Alfredo Goldman

Associate Professor, University of São Paulo
I started teaching agile methods in 2001. I am responsible for the course Agile Methods Lab at USP. Some of my former students help to promote several agile methods conferences in Brazil.
avatar for Viviane Almeida Santos

Viviane Almeida Santos

Academic Coordinator, Federal University of Pará
I am currently the Academic Coordinator of the Federal University of Pará (UFPA), Campus Tucuruí (Period: April/2019 to March/2022). From November/2016 to March/2019 I acted as coordinator of the Postgraduate Program in Applied Computing (PPCA), research line Computer Systems Development... Read More →


Thursday August 8, 2019 10:45 - 11:15
Chesapeake 7/8/9

11:30

Retrospectives: 548 Days To Fix 1 Line of Code (Ryan Latta)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.


Abstract:
We kept having retrospectives, but nothing changed. A year-and-a-half of retrospectives gone by. Each one about the same problem that never gets fixed. Dates are missed, morale is low, and we’re ready to throw in the towel.
I was a software engineer fed up with all my hard work amounting to work that wasn’t shipping. I was at a conference when a lightbulb went off. The talk was about lean manufacturing and put me on a path of learning about work-in-progress limits and experimental learning. At the heart of this inspiration was a phrase I had read, “If you understand the problem well enough, the solution is obvious.”
I wanted to change our retrospectives. I wanted us to focus on only one problem until it was fixed. I wanted our retrospectives to focus on learning and experimentation instead of doing action items. I wanted us to focus on fixing our problem for real instead of guessing.
I brought these ideas to the scrum master. Eventually, the ideas took hold and our retrospectives changed. As they did we began to learn about the root of our problem.
After three months we found the source of our problem. We found the one line of code that had crippled the team’s ability to ship safely or on time.
Through this story, I’ll teach you how I influenced our team and scrum master to change how they used retrospectives. I’ll tell you about the retrospectives that we used to focus on one problem and how we came up with experiments instead of action items.

Lessons Learned from Your Experience:
  • - Mixing up retrospective activities shed light on different things
  • - Answering a question is sometimes better than an action item
  • - If the problem is understood well enough, the solution is obvious
  • - Focus on fixing one thing at a time

Attachments:

Speakers
avatar for Ryan Latta

Ryan Latta

Consultant/Agile Coach
My mission is to create teams that change the world.I began this mission as a software developer. I saw in myself and other teams a passion for creating products that people would use and love. I saw that same passion dashed over and over again when the products fell flat. I knew... Read More →


Thursday August 8, 2019 11:30 - 12:00
Chesapeake 7/8/9

14:00

Using Design Methods to Establish Healthy DevOps Practices (Aras Bilgen)
Limited Capacity seats available


Abstract:
I wish adopting DevOps was as easy as just ticking items off on a DevOps todo list. Or as easy as setting up Jenkins and Docker. The reality is very different. Successful DevOps transitions require changes in the technical stack, in the mindset, in practices, and in the organizational culture. Unfortunately, the key cultural elements that need to change are usually buried in apathy, shyness, and office politics.
To reveal these crucial yet hidden cultural elements, we borrowed methods from an unlikely discipline: Design. User experience designers have been using methods to better understand humans for more than 40 years now, producing digital experiences that transform many areas of our lives seamlessly. We brought a selection of user-centric design methods to the IT department to understand how our clients work and to hear their deep, unspoken needs.
In this talk, I will go over five fundamental principles we borrowed from the design domain to understand the work culture of our clients. These principles are not exclusive to anyone – everyone can learn them with the right mindset. Join us to learn about how you can gain a creative, user-centric perspective to understand technical organizations without prejudice, so that you can remain happy, strong, and motivated in your DevOps journey.

Lessons Learned from Your Experience:
  • Attendees of this talk will understand the fundamentals of human-centered design methods and use these principles at work to understand deeper cultural dynamics. In particular, the attendees will hear about these five principles:
  • Accepting abductive thinking: Sometimes designers deliberately add uncertainty to the problem at hand to see if there are more creative, more effective solutions out there, especially for strategic design. This is very different than our automatic reaction to reduce uncertainty. Abductive thinking allows us to see multiple futures and evaluate them concurrently.
  • Creating a safe, conducive space: The abductive approach creates many, many opportunities to be wrong, to look stupid and to hit dead ends. This is OK. Therefore, it is very important to create safe spaces that are conducive to collaboration and co-discovery.
  • Externalizing issues: Tough issues may end up team members to point fingers at each other. Design addresses this challenge by externalizing the issues, visualizing them, and turning them into models we can manipulate – like post-its on a wall, cute models or interactive prototypes. Organizations can also be expressed as models that we can fiddle with, without blaming anyone.
  • Working with actual users: Good designers work not only with product owners, but with the actual users who will end up using the designed product. We acknowledge the value of our sponsors too, but our work impacts people other than the ones signing the contract. We strive to include the actual people who will be impacted by our work, positively or negatively, so that they can be a part of the solution.
  • Prototyping solutions: Designers create prototypes for features that are hard to code, so that they can see how the feature will work without having to wait for the release. Cultural transformations take years to be successful. It is very important to experiment and try solutions in the leanest way possible to see what they entail. Coaching, roleplaying, pilot teams are excellent ways to prototype organizational changes.

Attachments:

Speakers
avatar for Aras Bilgen

Aras Bilgen

Digital Transition Consultant, kloia
Aras provides design training, coaching, and strategic consulting services for designers, business analysts, agile teams, managers, and executives. He is a speaker in international design conferences, and the products he worked on have reached more than 160 million users worldwide.Aras... Read More →


Thursday August 8, 2019 14:00 - 14:30
Chesapeake 7/8/9

14:45

Organization in Rank-conscious and Reserved East Asia on the Bumpy Track to Team Health (Sangtae Kim)

Abstract:
Agile started off from an interest in how to develop valuable software better in a small team, but has since evolved to encompass a specific culture of working in an organization. The most effective agile transformation might be a big-bang change, but this isn't the track taken for some companies which could be due to many reasons including hesitance to take a big leap of faith. Hence, often a few projects are selected to be the pilots without disrupting the overall structure of the organization.
Our organization has a specific working culture that has evolved over time influenced by the local cultural background. Characteristics include emphasis of rank-consciousness and functional roles, and hierarchical decision making process. In an attempt to look into different methods of working perhaps more effective in the rapidly changing and volatile contemporary software product market, we have initiated agile to selected software development teams of various caliber and domain across the organization to improve effectiveness of the teams.
As internal agile coaches, we set out to help the teams by guiding the team members on how to perform agile practices, organizing and facilitating activities, and helping build up a more egalitarian work ambience. We started off with operating Scrum practices as described in various guiding materials and made additions and tweaks as time went on based on what we deemed as beneficial to the team. What we learned was that training and trying to perform agile practices is one thing, but creating the right ambience is another.
While helping teams with agile, we ran into several difficulties not finely detailed in publications, arising from the culture setting being more rank-conscious and people being more reserved than what we assume are like in the pro-agile environments that agile seems to thrive in.
In the following sections, we will share our experiences of how we have selected the five factors in the Hackman model of team effectiveness to delineate the issues to improve and how we have utilized various agile practices, and the current results and lessons learned we have attained on the truly bumpy track that we are traveling.

Lessons Learned from Your Experience:
  • While outspokenness and discussions might come natural in an agile-friendly environment elsewhere, these turn out to be something that need to be worked on in a more reticent culture setting
  • Many people think that they are already doing the agile practices as they should be performed (but if you really take a look, not many teams are understanding and practicing the values)
  • People have different wants concerning agile and it is not easy to align the wants once actual implementation and operation kick in
  • Workshops to share product vision and activities to promote collaboration do help... but you need to get the people to want to participate
  • There are some benefits attainable in terms of communication & collaboration within the team even without disrupting the organizational structure and roles (however, to potentially attain additional benefits, more changes to structure/policies seem needed)
  • In a culture where 'following tradition' is considered virtuous, an external coach plays an important part in making changes to a team

Attachments:

Speakers
avatar for Sangtae Kim

Sangtae Kim

Samsung Electronics
Have been working in various Software Engineering methodologies including Agile software development.


Thursday August 8, 2019 14:45 - 15:15
Chesapeake 7/8/9

15:45

Speed-bumps and Potholes on the Road from Projects to Products (Mike Griffiths)

Abstract:
Transitioning from projects to products made perfect sense for my client. Much of the business was digital and their websites / online-services would not be “completing” or going away soon. Development was deliberately continuous, and executives embraced this as both inevitable and desirable. However, just because it was the logical thing to do, it did not mean it was easy.
Maybe if we did not have over 100 inflight projects executing simultaneously, we could have picked an easier starting time? Maybe if there were not so many dependencies between teams, work would have been easier to untangle? Maybe if they were not in the midst of transitioning to microservices and new hosting technology, the technology challenges would have been easier to resolve?
Most organizations considering the transition from projects to products have similar challenges. By definition, “transitioning” means doing things mid-process; otherwise it would be “starting fresh with product development” – and where’s the fun in that?
This experience report recounts the story and transformation from slick PowerPoint slides to people problems and development difficulties. We did survive the journey and arrived in the land of continuous digital delivery, but we took some detours and lost some paint along the way. If you are considering the switch from projects to product development, maybe we can help you avoid some potholes and speedbumps along the road. Being forewarned is to be forearmed, but each journey is different, and as they say, your mileage will vary.

Lessons Learned from Your Experience:
  • An initial lesson learned was that there is never a good time to switch from projects to products. The fact that you need a more product-focussed model indicates your applications and services are continuously evolving. Re-staffing teams for both development and sustainment will have to happen during some development effort, which forces the team to storm and norm again while deadlines still loom. Also, some of today’s technology trends, such as switching to a microservice architecture, can create new cross-team dependencies if you are not careful. For us, a newly formed microservice environment provisioning team became a bottleneck for many teams.
  • Finally, there is always a learning process and communication exercises required when rolling out changes to how we plan, approve and fund new work. Switching from annual budget cycles for projects to ongoing micro-funding based on results required a lot of education and change management. Even though people agree, smile and nod in meetings they often return to their desks and continue doing things as before. So we burned all their old desks – not really, we worked with them to take them through the new processes. It worked fine, but we underestimated the effort and frequency required to achieve lasting change.

Attachments:

Speakers
avatar for Mike Griffiths

Mike Griffiths

Leading Answers & RMCLS, Consultant
Mike is an agile author, speaker and trainer, who helped create the agile method DSDM in 1994. He served on the board of the Agile Alliance and the Steering Committee to create the PMI-ACP credential.


Thursday August 8, 2019 15:45 - 16:15
Chesapeake 7/8/9

16:30

Beyond Software: When Agile meets Defense Systems and Hardware (Warren Smith)
Limited Capacity filling up


Abstract:
Many defense systems are very complex and include hardware designed specifically for that system. As Government and Defense organizations embrace Agile development, one of the stickiest issues is how to integrate Systems Engineering and Hardware organizations into an Agile program. Since Agile assumes a low-cost-of-change, these disciplines struggle to be Agile in the face of significant analysis and long-lead times. This paper describes the experience launching an agile development project and adapting Systems Engineering and Hardware Design teams to this environment. The changes were widespread, from how work is planned, to how it is managed, measured and implemented. The importance of model-based engineering and design tools will be discussed. The paper will also suggest approaches for using Systems Engineering to deploy complex hardware to an architectural runway.

Lessons Learned from Your Experience:
  • Experiences, twists and turns in successfully establishing Agile Systems and Hardware Engineering teams.
  • The critical role model-based engineering plays in non-software agility.
  • The shift in mindset and detailed planning needed to develop Architecture in long-lead, future feature deployment.
  • Insights in prioritizing custom hardware development for architectural runways, while minimizing the impact of later changes.

Attachments:

Speakers
avatar for Warren Smith

Warren Smith

Sr. Principal Systems Engineer, General Dynamics
My passion is vastly increasing Engineering Productivity through Agile Systems Engineering, MBSE and Engineering Re-Use Libraries.Improvements over 300% have been measured using Re-Use libraries and Agile SE using MBSE. Warren B. Smith is a Sr. Principal Systems Engineer at General... Read More →


Thursday August 8, 2019 16:30 - 17:00
Chesapeake 7/8/9