Nine levels of Agile Hell... and how to get out!

Government Agile transformations can feel like overwhelming efforts – but do not abandon hope! This interactive, audience-driven presentation reviews how government and large organizations ESCAPE common Agile adoption challenges.
You - the audience - will prioritize your pain points; we’ll focus on the five Agile hells most highly prioritized. We will discuss real examples of “escaping” out of each Agile hell, with pro tips and success patterns you can apply.
The Agile hells we've escaped include:

  • No Transformation hell - A federal program or department wants to change but can’t start or can’t finish
  • Too Fast hell - Newly Agile federal programs sometimes respond TOO rapidly, too often changing priorities.
  • Technical hell - Programs can become bogged down in technical debt and manual processes.
  • No Trust hell - Government delivery can be slowed by lack of trust between contractors and feds, between business and IT, or between compliance and delivery groups.
  • Product Owners hell - Government Product Owners can be unavailable, think they are managers, aren’t empowered to provide vision, or struggle with prioritization
  • Too Big hell- A frequent pattern in federal Agile! Large batches produce slow progress, low visibility and high complexity, seen in big programs, big deployments, and big contracts.
  • Collaboration hell - Government teams can struggle with collaboration within the same organization across roles and across the fed-contractor divide.
  • Stove-piped hell - Government organizations can struggle to collaborate across contractual or organizational boundaries within the same enterprise
  • Leadership hell - An organization can only be as agile as its leadership. In the government, how can you work with leaders who aren't ready to be agile?

For each Agile hell, we focus on successful techniques to escape from these common dynamics. Unlike other presentations, we won't be doing a deep dive, but we will cover the most important challenges our audience face.

 
 

Outline/Structure of the Talk

  1. Here are the nine Agile Hells (4 min)
    1. describe the nine levels (1-2 sentences each)
    2. POLL EVERYWHERE:of these nine hells - what do you want to hear about?
  2. INTRODUCTION (2 min)
    1. I’m Dave - an Agile Coach, Geek, Dad
    2. I’m also Dave - an Agile Coach, Geek, Dad
  3. ESCAPES FROM HELLS
    (We'll discuss the top five based on poll, offering additional examples and nuance for the top two) (34 min)
    1. Transformation hell
      • Real example of a program which just went through the motions of Scrum but never progressed
      • The solution: coach worked with a number of teams in turn, leading with why and training a agile advocate within each team
    2. Too Fast hell
      • Real example of a program trying to pivot too fast, always breaking sprints with the "emergency" of the day.
      • The solution: coach worked with both customer and team to make visibile the trade offs involved in interrupting flow to address emerging priorities
    3. Technical issue hell
      • (we'll provide examples and solutions for each remaining hell; see the presentation to hear them!)
    4. No Trust hell
    5. P’Owners hell
    6. Too Big hell
    7. Collaboration hell
    8. Stove-piped hell
    9. Leadership hell
  4. SUMMARY (5 minutes)

FOR THE PROGRAM COMMITTEE:

Your feedback in 2018 helped shape our talk as presented at Southern Fried Agile, Agile+DevOps West, and as accepted at Agile 2019.

We put a high value on prioritization and fast feedback loops - and we model this in the presentation itself. When we give the Agile Hell presentation, prior to actually introducing ourselves, we spend about 5 minutes explaining our Nine levels of Agile Hell. The Audience then prioritizes the Hells using the Poll Everywhere app - because we want to do everything on our backlog but we commit to the things that provide highest value. We the discuss each hell in a lean coffee style with time increments based on the available time. During each Hell, the audience creates a heat map of topics so that we can deliver higher value by responding to the audience

There is a lot to cover - and this will be a relatively fast paced event and will be responsive to audience interests via instant polling. Dave and Dave have given this presentation a half dozen times to audiences up to 120 - each time following our Agile mantra of highest value for the audience. That can be achieved because the Dave's draw upon (combined) experience of four decades in IT and two decades with Agile teams - all within Government projects.

We have given the Agile Hell enough times (in public and practice), to be very confident in Poll Everywhere (PollEv). Nevertheless, we recognize there is a risk since PollEv is a significant catalyst for our interaction with the audience. In the unlikely event that we cannot make use of PollEv, we have a pre-defined order in which to convey topics and will use the 1-2-4-all method to respond to the attendee insights (http://www.liberatingstructures.com/1-1-2-4-all/).

We share escapes government programs have used to avoid these agile hells, citing the program and speaking from our (combined) 40 years experience with IT in federal government. While we are not committing to speak on the following escapes, because we adapt Agile Hell to the audience in real time, examples we’ve used before include:

  • No Transformation hell - At [FEDERAL AGENCY] a cadre of coaches embedded with teams to build pockets of agility, then trained successors within each project to continue the transformation long term.
  • Too Fast hell - At USCIS ICAM, coaches used DHS ALMSS (JIRA) to make tradeoffs visible to product owners and business stakeholders who kept demanding rapid pivots before delivery had progressed.
  • No Trust hell: The only currency that buys trust is delivery. If your trust budget is small, make small, low risk deliveries. USCIS Transformation addressed a lack of trust about background check integration by taking stakeholders’ concerns seriously, meeting with them on a regular cadence, and bringing data by cross-checking thousands of background checks - at first through a manual sample, then by building automation. USCIS Avant built trust by asking customer subject matter experts be the ones leading a monthly system demo. The SMEs trust in the team deepened as they realized they were part of the team and jointly responsible for success. The SMEs built up significant trust from their stakeholders by demonstrating working software and speaking to how it will be used.
  • Product Owners hell - At TSA TAS, the contract’s technical monitor offered a “product owner agreement” as a non-binding document signed by the PO’s reviewer. Even though it is non-binding, the document empowers the PO, clarifies scope of the PO, and helps keep other responsibilities at bay.
  • Too Big hell- Contracts can be too large. The FADS II contract found that vendors could bring on four or five development teams, but performance declined sharply for the eighth, ninth and tenth team from the same vendor. One vendor escaped this by staffing slowly, one team every two months. Deliveries can be too big. Some years ago a delivery for USCIS Field Operations Division required over 400 user stories and nine months of development before it could be operationally test. We learned we needed to break up the functionality into smaller deliveries for low risk, end-to-end testing. We started field tests instead where as soon as feasible we’d run a few cases through the system, then ramp up as the system was tuned and proven out.
  • Collaboration hell - While in the US Army, Sergeant Fogel led team members who were weak and strong in different areas. When the team ‘formed up’ they would sound off “GOOD ENOUGH” - which was a daily reminder to focus on helping team members over excelling in a specialty. The chain of command heard this and supported the idea of team success over individual excellence. Similarly, USCIS D-QATS measures the agile health of DevOps programs by tracking which team members lead deployments. Programs with a log “bus factor” depend on person heroics, while programs with high rotation reduce risk through rich collaboration.

We have similar examples from government projects for the other hells (Technical, Stove-Piped, and Leadership) - we are prepared to discuss further if the program committee is interested.

Learning Outcome

  • Audience will get an appreciation of some aspects of Agile that are known to be difficult impediments.
  • More important: the audience will have specific actionable solutions to their concerns.

Target Audience

Anyone in an Agile transformation, particularly for Government and other large organizations

Prerequisites for Attendees

No prerequisite! Please bring a smart phone for interactive questions.

schedule Submitted 1 month ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Jeff Dalton
    keyboard_arrow_down

    Jeff Dalton - Big Agile is Coming: Will Technology Leaders Blow it?

    Jeff Dalton
    Jeff Dalton
    Chief Evangelist
    Agile CxO
    schedule 1 month ago
    Sold Out!
    45 Mins
    Keynote
    Executive

    2019 will be the year of Big Agile, where large adopters like General Motors, the Department of Defense, the State of Michigan, Lockheed Martin, and others, who have combined IT budgets exceeding 100 Billion dollars, have all announced their desire to “go agile” at a scale not yet seen in our community. Are technology leaders who cut their teeth in a low-trust, command-and-control, high-documentation environment prepared to make a successful transformation? What will Big Agile look like, and how will it affect the rest of the community?

    This will be our industry’s biggest challenge, and I've been studying it for years. As the large adopters in the federal government and corporate sector begin to adopt agile, they’ll bring their habits, culture, and bureaucracies with them, and they need to get in front of the wave.

  • Liked Mathias Eifert
    keyboard_arrow_down

    Mathias Eifert - Complexity is the Enemy! How Agile Practices Allow Us to Operate in a VUCA World

    45 Mins
    Talk
    Intermediate

    One of the key advantages of Agile over plan-driven approaches is that an Agile mindset acknowledges our ever-diminishing ability to usefully predict the future and focuses our efforts on managing change instead of trying to suppress it. This “new reality” has become pervasive enough to drive its own buzz word – VUCA, which stands for Volatility, Uncertainty, Complexity, Ambiguity. But beyond the hype lies a truth that Agile leaders need to understand and embrace – that certain problems really do respond differently to our attempts to manage and solve them. Why does this matter? Because problem contexts that defy straightforward cause-and-effect expectations significantly impact productivity while simultaneously presenting much higher risks to success. Even worse, applying leadership approaches that aren’t matched to the problem context dramatically increases the danger of catastrophic failure.

    In this session, we’ll examine how the Cynefin framework helps us make sense of what kinds of problems we’re dealing with and how we should approach them. We will then look at ten ways in which Agile frameworks, approaches and technical practices help us manage or even reduce complexity and one where they fall short. You will walk away with a deeper understanding of how - and why - the things we do as agilists increase stability and reduce risks for our teams.

  • 45 Mins
    Workshop/Game
    Beginner

    How do you get people to agree on priorities when they may have different objectives? You may be facing an issue now where stakeholders are pushing against each other in order to get their work done first. What would happen if we could create an open dialog among stakeholders and have them understand different perspectives and focus on the goals of the greater good instead of just their own? Let’s face it, proper prioritization is the difference between writing code and developing valuable solutions.

    In this simulation style workshop, you’ll learn practical methods for bringing stakeholders together and openly discuss their different priorities to agree on what’s most important overall. You will see first hand how a combining group discussion with proven prioritization methods such as Weighted-Shortest Job First and (WSJF) and Must Have, Should Have, Could Have and Won’t Have (MoSCoW) work.

  • 45 Mins
    Talk
    Beginner

    Have you tidied up your personal life with Marie Kondo and are now wondering how to achieve the same effect in your work life? Do you have the feeling that the most valuable product backlog items (PBIs) are getting lost under a mountain of old stories, bugs, and tasks? Maybe you know a change is needed, but feel completely overwhelmed about where to start? If so, join us to learn how to make your product better through the life changing magic of tidying up your backlog.

    We’ll start by exploring the costs of a large, cluttered product backlog and share a short quiz you can use to gauge the current state of your own backlog. Next, we’ll cover how we’ve adapted the KonMari method and introduce five easy steps you can take to get started in your tidying process. We'll share real-life examples along the way, calling out potential pitfalls to avoid (don’t become a storage expert!), and illustrating how story mapping may be the magical backlog equivalent to Kondo’s “vertical folding” technique. By the end of the session, you’ll know the specific next steps to take so that you too can realize the many benefits of a tidied-up product backlog: improved visibility, increased self-organization, and easier decision-making.

  • 45 Mins
    Talk
    Beginner

    On average Agile transformations get into trouble at about 14 months from the time they start. Have you ever wondered why?

    Is it because you started from 'the bottom up?" Or is it because you spend time, money, resources and people creating great teams and didn't pay attention to having a professional, empowered Product Owner organization?

    Agile transformations that target department level and not the organization have a very low success rate and you end up with an agile department enveloped by a traditional organization. That leads to dark work, decision delay and dysfunction.

    So, what can you do?

    Come and learn some of what I learned the "hard way" over 7 transformations.

  • Liked Dave Witkin
    keyboard_arrow_down

    Dave Witkin - Go Big Without Blowing It: How Does Scrum@Scale Help?

    Dave Witkin
    Dave Witkin
    Principal
    Packaged Agile
    schedule 1 week ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Do you work on programs requiring collaboration of 30 people or more? Have you heard of Scrum@Scale? While many people have heard of SAFe, far fewer are familiar with Scrum@Scale. Did you know Scrum@Scale was built by Jeff Sutherland, the co-creator of Scrum? And that the very first scaled Scrum project began in 1983?

    Come learn about Scrum@Scale, where it is being used, and why it may be a better fit for your organization than other scaling methodologies. I am both a SAFe and Scrum@Scale practitioner and trainer, and will provide a balanced comparison with pros / cons.

  • Liked Glenn Buckholz
    keyboard_arrow_down

    Glenn Buckholz - Moving Your Pipeline to Kubernetes, Things I Wish People Had Told Me

    Glenn Buckholz
    Glenn Buckholz
    Technical Manager
    Coveros
    schedule 1 month ago
    Sold Out!
    45 Mins
    Case Study
    Intermediate

    Kubernetes married with a cloud provider elastic, highly available infrastructure. Many CI engines today (Jenkins, Bamboo, Gitlab, CircleCI), provide native integration with kubernetes so that your build and deploy workload can be elastically executed. This allows your pipeline to meet the needs of your schedule, be it the 4pm pile on to commit code before going home, the mad rush to get a hot fix to production, or the surge of an unexpected customer ask. Gone are the days of the build queue growing and you CI engine collapsing under the weight of a hundred build requests. In order for a pipeline to leverage this capacity changes must be made to the pipeline architecture. Tools must be dockerized, the ephemeral nature of running docker must be considered, kubernetes specifications or helm charts must be generated for the application, automated testing must be adapted to work in the new architecture, and then there is the database. Each one of these issues, plus many others I’ve missed contained unfortunate, unforeseen pitfalls that translated in schedule delays. Join Glenn as he helps you short circuit the pitfalls of migrating to kubernetes off of your static in-elastic virtual infrastructure.

  • Liked Mark Grove
    keyboard_arrow_down

    Mark Grove / Julie Wyman - What’s REALLY Going On? An Observational Skills Workshop

    Mark Grove
    Mark Grove
    Excella Consulting
    Julie Wyman
    Julie Wyman
    -
    -
    schedule 1 month ago
    Sold Out!
    45 Mins
    Workshop/Game
    Beginner

    Imagine you are asked to sit in on a team’s sprint review and retrospective. The team has been having difficulty forming and the Scrum Master has asked you to observe the team dynamics during these two sessions. Are you simply going to watch what’s going on or is there more you can do? Perhaps you are seeing interactions and team dynamics at play without truly realizing what you are observing. And when you do observe, are you injecting your own biases into those observations? Observation is a powerful tool, but one which we may not take advantage of to its true potential. After all, what exactly should we be observing, anyway?

    By learning how to expand our observational skills in a non-biased and non-judgmental manner, we can gain a deeper understanding of team dynamics and interactions allowing us to offer more meaningful and impactful support, coaching, and empathy. Because there are many observational aspects that pass us by, the best way to become more observant is through deliberate practice. So, let’s practice together with a group exercise in a fun and safe setting!

    In this highly interactive workshop, we’ll start by sharing tools and tips to make you a better observer. Then we’ll ask for a small group of volunteers (“builders”) to be observed performing a brief task. The remaining attendees will practice applying the observation techniques, and, after the builders finish, will share their observations in small groups. We’ll conclude with a full-group debrief and discussion of the key takeaways and opportunities to improve our effectiveness and observations.

    If you’re looking for new ways to connect with your team, to enhance your agilist toolkit, or simply participate in an informative and interactive workshop, this session is for you!

  • Liked Dane Weber
    keyboard_arrow_down

    Dane Weber - Undercover Scrum Master

    Dane Weber
    Dane Weber
    Sr. Consultant
    Excella
    schedule 1 week ago
    Sold Out!
    45 Mins
    Experience Report
    Intermediate

    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.

  • Liked Katrina Tanner
    keyboard_arrow_down

    Katrina Tanner - Playdoh...play on!

    Katrina Tanner
    Katrina Tanner
    Scrum Master
    Cvent
    schedule 1 month ago
    Sold Out!
    10 Mins
    Lightning Talk
    Beginner

    What happens when 25 product owners, developers, and quality engineers reflect on their previous sprint through the eyes of a child?

    Playdoh took my teams, remote and collocated, from showing up to an obligatory meeting on their calendar to intentional interpersonal and intrapersonal dialogue.

    Between the carpet and the sticky fingers, adults are usually cleaning up more Playdoh than playing with it themselves. Even to my own surprise, in this “Play Retro,” our team members connected, not only on a professional, but also on a personal level in ways they had not done before.

    This session will give an overview of our experience using a “Play Retro” and leave you with tips and things to consider planning a retrospective.

  • Liked David W Kane
    keyboard_arrow_down

    David W Kane - Hang Out with the DevOps Folks!

    10 Mins
    Lightning Talk
    Intermediate

    One of the things I like about AgileDC is that I see a lot of familiar faces. Not just familiar from previous AgileDC events, but from other Agile events in town, other conferences, Meetups and such. I also go to local DevOps events, and I see familiar faces there too, but I don't observe much overlap between the two. In this talk I will discuss whether this division is real, or perhaps just a figment of my imagination, whether we as an Agile community should care, and what we should do about it.

  • Liked Richard Cheng
    keyboard_arrow_down

    Richard Cheng - How to REALLY use the Agile values and principles!!

    Richard Cheng
    Richard Cheng
    Principal
    Excella Consulting
    schedule 5 days ago
    Sold Out!
    45 Mins
    Workshop/Game
    Beginner
    Your organization is doing Agile, which great, but what does that really mean? Perhaps they are implementing Scrum, or Kanban, or one of the other Agile methods, but are they really being Agile? Does it feel like you are you are doing Scrum, but you’re team isn’t really Agile? There's difference between doing Agile and being Agile and this session explores that concept.

    In this session, we’ll understand what Agile really means and how that relates to the way we implement our Agile methods within our organizations. We'll identify how we effectively use the Manifesto value points so that we can maximize the value of our products while still ensuring that we have quality and governance built into our process. This session will also explore the use of Agile principles to guide our strategic and day to day decisions.

    This sessions is great not only for beginners, but for anyone who wants to get past simply implementing Scrum or Kanban by the book, but really understand how to use Agile values and principles to build better products and organizations.
  • Liked Mark Grove
    keyboard_arrow_down

    Mark Grove - Authority and Trust: Finding the Scrum Master Balance

    Mark Grove
    Mark Grove
    Excella Consulting
    schedule 3 weeks ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Have you ever seen the term “process authority” used to describe the role of a Scrum Master? You don’t have to look too hard to find this description. In my experience, it has caused a lot of confusion and misunderstanding on project teams. So why is it even used? And should it?

    I worked on a new Scrum project where management informed the project teams that the Scrum Master role was given process authority over the team. There was a lot of confusion and unease about this. Questions started popping up such as “I already have a manager – is the Scrum Master now my boss,” “What does process authority mean,” and “Do we really have to do what she says?” As a result, the teams were becoming hostile to the Scrum Master role, untrusting of the Scrum Master’s responsibility, and concerned Scrum Masters had authority to tell the teams what to do. I was the project’s agile coach and needed to diffuse the confusion and better the working environment as quickly as possible. This did not happen overnight, but our journey started with this interactive discussion which we used as a foundation for the project moving forward.

    In this interactive presentation, we explore the concept of “process authority” and consider the various directions it takes us. To do that, this discussion goes far beyond a typical “the role of a Scrum Master” presentation; It explores…

    • What it should (and should not) mean when/if “process authority” is used to describe the Scrum Master role
    • How the responsibility and expectations of a Scrum Master are different than that of team members
    • How different leadership styles play into understanding the role of the Scrum Master
    • The importance of trust in a Scrum Master/team relationship

    The presentation uses real-time audience feedback to further explore these topics. Audience members will provide answers to questions given throughout the presentation, so we can explore members’ thoughts, opinions, and experiences they have had with the Scrum Master role.

  • Liked Dr. Patrick McConnell
    keyboard_arrow_down

    Dr. Patrick McConnell - The Velocity Trap: Learning to Value Enterprise Outcomes over Team Output

    45 Mins
    Tutorial
    Beginner

    Behind the creation of every Agile Framework was the intention to improve the Return on Investment for creative work, primarily through faster and richer feedback. But as team-level frameworks like Scrum are internalized by large organizations, that message gets mistranslated. Instead of, “Get better outcomes, sooner,” the drive instead becomes, “Just do more, faster.”

    A common expression of this problem is the confusion of Velocity for Value, where teams are directly managed based on their Output, but the connection between Output and Outcome is lost or ignored. This plays out in all kinds of ways that distract from achieving tangible results, and often incentivizes internal competition over collaboration. This problem can be especially tenacious in organizations with significant institutional ‘status-ing’ behaviors, where leadership struggles to translate common Agile methods like Relative Estimating into existing artifacts like Executive Dashboards or Earned-Value Management.

    In this tutorial, participants will explore the 'Velocity Trap', and will be shown how to setup a results-driven framework that prioritizes 'Maximizing Outcomes while Minimizing Output.'

  • Liked Dane Weber
    keyboard_arrow_down

    Dane Weber - Continuous Modernization

    Dane Weber
    Dane Weber
    Sr. Consultant
    Excella
    schedule 6 days ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Rather than engaging in an intense modernization effort followed by years of minimal maintenance, a better alternative often is modernizing a system continuously, balancing operations, maintenance, and renovation. Ideally you can improve, update, and upgrade the software system one piece at a time while it continues to operate, avoiding feature freezes and scary cut-overs.

    There are always trade-offs to be made, but some approaches better fit IT systems with long-lived missions. At a certain point, a whole-sale rewrite is the best option for replacing stale, decaying software before it leads to major headaches and eventual catastrophe. Big rewrites have big risks and big failures, however. Because of the stability and enduring mandates of some software systems, long-term investments in IT systems pay off and give room for smart maintenance strategies.

  • Liked Toby V. Rao
    keyboard_arrow_down

    Toby V. Rao - Why is my Agile Talent leaving? How can I stop that?

    45 Mins
    Talk
    Intermediate

    More and more organizations are embracing Agility and are transforming. According to 13th State of Agile Report - as many as 97% of organizations state that they practice agile development methods. This rapid change and the strong US economy has resulted in a surge in demand for talented Agile Coaches, Developers, Scrum Masters, DevOps Engineers, Full Stack Developers etc. The problem is that the demand far exceeds the supply of good agile talent. This imbalance has resulted in turbulence in the job market and consequently causing a heavy movement of agile talent.

    If your organization is affected by the movement of agile talent, you should pay attention!

    • How is your organization reacting to these changes?
    • Want to understand why agile talent make the choice to stay or leave organizations?
    • Would you like to learn about 5 pragmatic actions you can take immediately to help reduce attrition?

    Join Toby Rao for an interactive discussion that will not only change your paradigm but also help you and your organization to take simple steps to control attrition.

  • Liked Toby V. Rao
    keyboard_arrow_down

    Toby V. Rao - The Prioritization Conundrum...and how to come out of it!

    45 Mins
    Talk
    Intermediate

    Let’s face it – we work in a time constrained and fast paced work environment. The plethora of urgent, and often competing priorities not only make it difficult to decide what takes precedence, but also add a lot of complexity and stress to the teams.

    We already know that proper prioritization can help resolve these challenges. But most often the bigger challenge is to be able to prioritize effectively and accurately to achieve the right output.

    If you would like to learn about effective prioritization techniques – Please join Toby Rao for a fun, interactive and informative discussion.

  • Joshua Seckel
    Joshua Seckel
    Specialist Leader
    Deloitte
    schedule 4 weeks ago
    Sold Out!
    45 Mins
    Case Study
    Advanced

    Many agile talks are about the benefits of cross-functional teams and integrating them with your business and changing their structure to better align to the value delivery. And amazing things happen with you get all of this stuff working together. There are industries and organizations that can't do this. Not because they don't want to or that they are not interested in the modern ways of working, but because they don't have the skills in-house and the cost of bringing all of those skills into the organization are inhibited by constraints of one sort or another.

    The use of contractors and outsourcing of IT development was a major push for many years as businesses focused on their core capabilities. Industries like government couldn't compete with the marketplace for IT skills and so turned to contractors to fill the needs in many organizations. Now, these same organizations feel they need to bring the modern agile ways of working to their organizations. So how do they actually get the benefits of modern agile ways of working and delivering products while continuing to use contractors for most of the work?

    This talk will focus on 3 areas of achieving most of the benefits of modern agile work while continuing to use contracted work. First, how to decide what to outsource. The decision of which pieces or work to use contractors for is the most important. Second, how to actually hire contractors. The procurement process can be evolved to be more agile and to encourage finding contractors that will drive toward the desired collaboration. Finally, how to manage and work with contractors. The day to day grind of working where real delivery will be accomplished.

    Getting benefits from an agile framework and delivery is important and can still be achieved when some of the work is outsourced and the importance of defining and finding the right contractor are vital to achieving the desired success.

  • Liked Megan Windle
    keyboard_arrow_down

    Megan Windle - The Art of Agile: The Art of War Interpreted with an Agile Lens

    45 Mins
    Talk
    Beginner

    What do Agile and War have in common? More than you might think. When you think of war, think of it as a problem to be solved. Now, think about Agile. Agile is a way of working and thinking to collaboratively solve problems and figure things out you go.

    Sun Tzu’s “The Art of War” is a book of wisdom and strategy for warriors. But don’t be fooled. The book contains lessons that go far beyond the battlefield. Lessons for Agilists can be found within the text, when interpreting the words with an Agile mindset. The importance of planning, self-governance, and just-in-time information are a few examples of lessons that apply to both War and Agile.

    If you want to discover the golden nuggets of Agile wisdom found in this ancient text, bring your agile mindset and join me to interpret “The Art of War” through an agile lens.

  • Liked Raj Indugula
    keyboard_arrow_down

    Raj Indugula / George Lively - Being Test-driven: It's Not Really About Testing

    45 Mins
    Talk
    Beginner

    Good news: Test-driven practices have jumped the chasm to general acceptance! The bad news, though, is that while TDD, BDD, and ATDD are prominent buzzwords in the industry today, they are rife with misconceptions, with many people incorrectly assuming that being test-driven is all about testing.

    In this talk, learners will leave with a clearer understanding of Test-Driven Development (TDD), Behavior Driven-Development (BDD), and Acceptance Test-Driven Development (ATDD), and gain practical insights into how these practices can help teams develop better software. We will gain an appreciation for TDD as being primarily a specification and design technique, and how to get the whole team involved earlier in the delivery cycle using a BDD approach.