Failure is Inevitable But it Isn’t Permanent
Elevator Pitch:
Agile Transformation is harder than it needs to be because we often find ways to consciously or subconsciously sabotage our efforts if we can recognize this behavior it is possible to intervene and make a change for the positive.
Abstract:
Have you ever been on a project where it seems like team members are preventing the team from getting better? Why do they do that? I don’t know either- a psychologist might have to answer that. What I can tell you about is my experiences in seeing teams become their own worst enemies and unwittingly sabotaging the projects they are trying to make successful. My goal is to help you realize when you or those around you are behaving in a way that is going to lead the team plateauing or even failing. I have often found that many teams can get stuck, or plateau, at a certain point along the continuum of agile maturity. These teams can meander around without getting better or even changing anything for long stretches of time. I have also worked with teams that put so many hurdles in their own way that they had no option but to fail. They often fell back into old patterns and gave up hope that things can get better. As an Agile Coach, I have often felt that one of the most valuable things I can share with the people I coach are my failures. I have worked on Agile projects for a long time, and I have failed in many different ways. Having been through failure, I have learned that to keep getting better you have to recognize the things that you do that lead to plateaus and failures to overcome them. This talk is for coaches and team leads who want to make sure their team isn't getting stuck in a rut, or who are trying to get out of a rut with their health and sanity intact.
Failure signs and examples
No process is defined and followed
- ex. Projects that claim to be agile without any experience or training, or doesn’t have basic agile practices such as retrospectives, I.e. we are agile because we have hour long daily standup meetings.
Process practices are ignored or removed with no compensating practices
- ex. Agile practices hold each other together, supporting each other by the value they bring to the project, some teams decide to not do some practices without doing something else to get that value, for instance pair programming provides code review and knowledge transfer, many teams don’t pair program and don’t do code reviews and or knowledge transfer.
Automation is not valued or planned into work
- ex. We will automate tests later. Often that later never comes and the team is left with a code base that is hard to maintain and change because you don’t know what your changes break.
No stakeholder expectations management
- ex. The only way a project can negotiate scope and or schedule is to actively manage stakeholder expectations. An example of unmanaged expectations is the PO that never says no to a feature request or the executive that decides what must to delivered and when it must be delivered.
Quality and testing practices are an after thought or short changed on schedule
- ex. Teams that don’t complete sprint commitments because the testers get coded stories too late in a sprint to do all the required testing and the rest of the team isn’t held responsible to help test.
No negotiation allowed in deliverables and or schedule
- ex. Executives that dictate all of the terms of a project before a team is even selected.
The team doing the work didn’t estimate the work but are held to an estimate
- Many government projects have such a long procurement cycle that no one from the proposal team is put on the project.
Part time team members are in the critical path
- ex. Sometimes people with special skills are needed for a part of a project. If the person is part time but their work is in the critical path the project is in trouble.
Heavy team turn over
- ex. Heavy turn over is a sign of a project that isn’t on track, even if it hits its deadlines the quality and output will suffer.
Political motivations more important than team’s ability to do work
- ex. If the team is setup to fail for reasons outside the team, they will most likely fail.
Distraction from issues outside the work that needs to be done
- ex. Scrum Masters that don’t shield the team from issues outside the work that needs to be done during a sprint will end up with a team that doesn’t hit the mark.
Examples of what can be done to avoid failed projects:
Focus on shielding the team from outside influence
- Have the team focus on the things they can control and prevent outside issues from distracting the team.
Negotiate delivery with the team
- The team can develop an understanding of what it can deliver. Trying to make the team do more is going to lower quality and potentially make the project take longer.
Management of stakeholder expectations
- Stakeholders always want more, that is their job. Let them ask for anything but set their expectations on what is really going to happen.
Focus on technical excellence, quality, and automation
- If you want your teams to get better, have them focus internally on things they can control like technical aspects of the project including quality and automation.
Hire motivated team members and make it possible for them to work
- People who care about what they are doing will always be better than the cheapest people that don’t care. Hire people who care.
Maintain a progressive planning pace for getting requirements ready
- Agile requires planning at different levels, skipping a level for any reason means there are going to be disconnects between your stakeholders and the people doing the work. Disconnects means the project will not product the results you want.
Outline/Structure of the Talk
This talk is the culmination of over 15 years of Agile experience that has taken me from the depth of despair to the mountain of success, at least in my mind. Over that time, I have learned a lot about how teams of people work against their own best interests or the best interests of the project they work on. I have learned to recognize the signs of project breakdown and have come up with solutions that sometimes work. My goal with this presentation is to confess my project sins and share my experience, strength, and hope about projects with the audience.
I haven’t worked the timing out completely but I expect it to go something like this:
1. Introduction and expectations setting
2. Explanation of plateauing as it relates to Agile maturity
3. Signs that your team has plateaued
4. Examples of plateaued teams and how to get them improving again
5. Discussion of why projects fail even when the team really doesn’t want them to fail
6. Signs that your project is going to fail
7. What you can do prevent a project from failing
8. How to personally recover when your project has failed
Learning Outcome
Learn to spot when a team is headed toward failure and how to get them back on track.
Learn why teams plateau and how to motivate them out of that mindset.
Hear about all of the mistakes that I have made and what can be learned from failing that much.
Come to accept that you can only do what you can do and that a failed project doesn’t mean that you are incompetent or a bad person
Target Audience
People who have tried Agile, DevOps, or any other kind of a change and failed.
Links
I am an experienced speaker having presented at several national and regional conferences. I have also trained hundreds of students in a variety of classes and topics.
My speaking engagements include:
Better Software 2011, "Building Secure Applications"
Agile Dev 2012, "Signs Your Agile Adoption is Off Track (And How To Fix It)"
AgileDC 2012, "Secure Agile - How to make secure applications using Agile Methods"
DC Continuous Integration User Group 2013, "Integrating Security into Continuous Delivery"
Richmond Area Agile Users Group 2013, "Integrating Security into Continuous Delivery"
Agile Dev 2013, "Implementing Cloud-based DevOps for Distributed Agile Projects"
AgileDC 2013, "Overcoming Problems Implementing Cloud-Based DevOps for Distributed Agile Projects"
Coveros Webinar Series 2015, "How DevOps Impacts your Software Development Process"
STARWest 2016, "Agile Testing for Embedded Software Development"
schedule Submitted 2 years ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Cherie Silas - Power Coaching – Pushing the Boundaries to build better teams
45 Mins
Talk
Intermediate
Elevator Pitch
Sometimes teams need more than just questions. They need scrum masters and coaches who are courageous enough to have the hard conversations, challenge their decisions, push them to the next level. During this session we will introduce participants to some anti-patterns that have arisen in the scrum master and agile coaching communities and discuss ways to break free!
Description:
Coaching Agile Teams is all about asking questions and allowing them to self organize, right? Well, that's just part of the mission. During this session we will introduce participants to some anti-patterns that have arisen in the scrum master and agile coaching communities and discuss ways to break free!
Sometimes teams need more than just questions. They need scrum masters and coaches who are courageous enough to have the hard conversations, challenge their decisions, push them to the next level. However, sometimes we push our teams a bit too hard and create negative conflict. It's times like this when we need to demonstrate how to reach out and make the first move to repair the relationship. We will introduce the concept of repair bids to help in this area.
Lastly, we learn a model to put into practice to create a coaching alliance with teams so you can be in agreement on how you will work together for their best interest and improvement over a period of time.
The reason we chose to create this session is that over the past few years we have noticed that as people are learning more about coaching they are getting out of balance and believing that the only thing that coaches are allowed to do is ask questions. We've noticed that scrum masters lean so far in the direction of self organization that they no longer believe they can challenge teams to grow or to move beyond where the team decides to be. We believe that the root of the problem rests in the fact that people are learning a bit about coaching but not actually learning how to be a coach. We would like to introduce to the attendees the more direct coaching methods that are available for use such as 1) direct communication, 2) challenging, 3) courageous questions that push the edge of the comfort zone, etc.
Session is collaborative and includes interaction with the participants throughout. Also has collaborative exercises.
-
keyboard_arrow_down
Gene Gotimer - Building the Pipeline of My Dreams
45 Mins
Case Study
Beginner
I often suggest to teams that they should be using all sorts of tools in their pipelines- from simple static analysis checks and automated builds to security scans and performance testing. I've done presentations and talks at conferences. I've lobbied to clients. I've commiserated with my colleagues. But I've never put together my dream pipeline in one of my own projects.
There are always reasons that some tests and tools get left out- our policies won't allow them, they will take too long to get approved, we don't have time, we have bigger problems to deal with, it just isn't what the client is looking for right now. And I usually think, if only I were in charge, I'd make sure we were using those...
In late 2017 I took over maintenance on an open-source project. Now I have no restrictions. The sky's the limit. No one is around to tell me what I can't do. So why don't I have my dream pipeline in place yet?
I'll talk about the trade-offs and compromises I made when building out the pipeline. Why I decided to focus on some tools and tests but skipped others, and what I need to do or change to make this delivery process the pipeline I've always dreamed about, now that I have no one else to blame.
-
keyboard_arrow_down
Rick Austin - Portfolio Management In An Agile World
45 Mins
Talk
Intermediate
When organizations move to agile for software delivery, there is often tension with traditional portfolio management. This talk will illustrate how an organization can move from traditional portfolio management approaches to one that embraces agile software delivery. Doing so enables organizations to become predictable, improve the flow of value delivered, and pivot more quickly if necessary.
We will demonstrate the use of governance that allows a more adaptive portfolio management approach. We will cover topics that enable agile portfolio management including:
- Lean techniques for managing flow
- Effective prioritization techniques
- Long range road-mapping
- Demand management and planning
- Progressively elaborated business cases
- Validation of outcomes
- Support for audit and compliance needs
These topics will be illustrated by real-world examples of portfolio management that have been proven over the last five years with a wide range of clients.
-
keyboard_arrow_down
Mark Grove / Trent Hone - Kanban in Action: Thoughtfully Creating and Discussing Flow
45 Mins
Workshop
Intermediate
In our follow-up session to last year’s Kanban in Action: Thoughtfully Observing Flow, we are excited to bring our newest installment of the series: Kanban in Action: Thoughtfully Creating and Discussing Flow.
This session puts the attendee in the driver’s seat to create their own Kanban board configurations. We provide seven business scenario exercises and ask the attendees how they would go about configuring their Kanban board given the unique constraints of each scenario. Each team/table in the room will spend a few minutes discussing how they would configure their board using the provided flip charts, markers, and stickies. A debrief with the entire room follows as each team shares its concepts. The instructors will also share their own board configurations and ideas.
These exercises will increase your understanding of Kanban systems, give you practice interpreting and creating board configurations, present multiple implementable ideas for any given scenario, and provide you with approaches for meaningful engagement. They are great for aspiring coaches, managers, and leaders who want to have more valuable conversations with their teams and improve Kanban implementations.
-
keyboard_arrow_down
Richard Mills - DevOpsing Your Greenfield: Cultivating New Growth
45 Mins
Talk
Intermediate
You have a golden gem of an activity. There's a brand new project and your project sponsor says "I want to do some DevOps on our new Agile project!" Sigh. You respond with "Well, how about this? Let's BE Agile and adopt a DevOps approach to structuring our teams, designing our architecture, and leveraging automation to rapidly deliver value to our customers." There. At least we've set the mood.
Regardless, greenfield projects provide a unique opportunity for us as DevOps professionals. You don't have the established baggage of a legacy project. The project is probably open to modern tools and architectures. The project is trying to set up team structure that will have the right skill sets.
The problem is: where you do you actually start with greenfield projects? When we introduce DevOps to an existing project (brownfield) we have a unique set of challenges and we can prioritize where to start based on our biggest problems. What do you do when you have a blank page? "Do everything!" Well, what actually makes up "everything" and where do we start?
Putting a solid DevOps solution in place involves some key things. You can follow the religion of the "Three Ways of DevOps" (fast delivery, fast feedback, constant learning) made popular by Gene Kim, but you still have to start somewhere. In this talk, I'll provide a pragmatic formula to setting up well-integrated teams, establishing a DevOps platform, organically growing an initial DevOps pipeline with continuous integration and continuous delivery, establishing some (useful) standards, and guiding the system architecture to support rapid build, deployment, and testing. -
keyboard_arrow_down
Julie Wyman - Responding to Change over Following a Plan: Agile Lessons from Antarctica
10 Mins
Lightning Talk
Beginner
I spent January in Antarctica hanging out with penguins, whales, and seals. It was about as different from my day-to-day work as can be. And yet, on my long flight home, I couldn’t help but reflect on how well my trip aligned with one specific value of the Agile Manifesto: “Responding to change over following a plan.”
Antarctica is a place that truly drives home why we need both planning AND, even more importantly, the ability to respond to change. This trip helped me fully appreciate how true this value is - and not just in software development. And after being stuck in Antarctica six days longer than planned, it also built up my empathy for team members struggling with dynamic situations!
-
keyboard_arrow_down
Bryan Miles / Darren Hoevel - Adaptive Leadership...WTF is that?
Bryan MilesAgile CoachPliant SolutionsDarren HoevelAgile CoachPliant Solutionsschedule 2 years ago
45 Mins
Workshop
Beginner
“The single biggest failure of leadership is to treat adaptive challenges like technical problems.” -Ron Heifetz
We live and work in an increasingly interconnected and rapidly changing world. New business models are shifting duties to teams instead of individuals, which means people are now working more closely together. It also means leaders at all levels have to begin to adapt their leadership style to guide the intricacies of human dynamics and channel the collective knowledge of the groups they interact with.
In this workshop we will explore how leaders create environments that navigate the complexity of interpersonal relationships, overcome the human element of barriers to change, and support the growth and engagement of their employees. Attendees will walk out of the room with a clearer idea of their own leadership style and a list of action items they can use (tomorrow!) to move their teams one step closer to higher performance.
-
keyboard_arrow_down
Jolly Rajan - Measure It! - How You Can Drive Continuous Improvement With Simple Metrics
10 Mins
Lightning Talk
Intermediate
You don't need complex metrics that are onerous to track and analyze to drive continuous improvement. Lets look at 6 metrics that are easy for any team to use to accelerate their progress to being a high performing team.
-
keyboard_arrow_down
Joshua Seckel - Modern Agile 101 for Government
45 Mins
Talk
Beginner
In 2001, a group of software developers got together in Snowbird, UT, and created the Agile Manifesto. The Manifesto was a statement of core value and principles. The core values are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These four values are supplemented by 12 principles of agile software. The original 17 signatories were joined by thousands of additional people with the ability to sign cut off in 2016.
These principles are the foundation of much of the work in agile that has occurred in agile development, but have been mostly frozen as practices and agile has evolved.
Modern Agile has been created recently to update the underlying foundational values and to provide a focus beyond software delivery. Those four values are:
- Make People Awesome
- Deliver Value Continuously
- Make Safety a Prerequisite
- Experience and Learn Rapidly
This talk will walk through this reimagining of the agile values and what they mean for delivery within a government context. We will take each value and look at government cultural and technical challenges and opportunities to advance modern development practices.
-
keyboard_arrow_down
Todd Lankford - The Triple Track Method: Arrive at the Right Product by Connecting Agile Teams With Customers
45 Mins
Talk
Intermediate
The Triple Track Method
This talk is for Agile teams delivering using the Scrum framework
Who desire to put the customer as the central force in maximizing product value but struggle to do this in the midst of an intense focus solely on delivery of feature after feature
Unlike maximizing how many features are shipped by a certain date in a certain budget with limited customer engagement or having separate teams gather customer insights for the Agile delivery teams
The discussed approach focuses Agile teams on maximizing a positive customer behavior outcome and the resulting business impact through direct customer interaction throughout the delivery cycle
This results in moving the team towards a collective product ownership mindset, bringing the team and the customer together to achieve optimal outcomes.
-
keyboard_arrow_down
Arlen Bankston - Performance Management in the Age of Agility
45 Mins
Workshop
Intermediate
Agility is about adaptation, challenging the status quo, experimentation and learning. HR has historically hewed closer to compliance, but that has been changing rapidly.
Today's nimble teams and workers will no longer tolerate stifling, staid environments and management practices. The newly popular label "people operations" implies an emphasis on human engagement over bureaucracy and regulation, and indeed many organizations have been moving this way.
Be inspired by some of the most daring advances in human resources while also learning some practical approaches and techniques that can be applied to start leading your business down this path. We'll discuss new approaches in hiring, performance management, learning and development, and even the structure of HR groups and roles. Participants will also enjoy a few exercises that will illustrate some interesting techniques.
Prepare yourself for HR in the next generation.
-
keyboard_arrow_down
Dave Nicolette - Developer superpowers to effect positive change
45 Mins
Talk
Intermediate
Many software developers (especially in larger organizations) are unhappy in their jobs. They are in a never-ending spiral of increasing code cruft, and their management does not allow them time to remediate technical debt or keep the code base clean. They feel helpless, beaten-down, defeated. They can't imagine that improvement is even possible. They respond to any suggestion to improve the status quo with comments like, "In an ideal world, maybe," "That will never work here," "You don't live in the Real World®," etc. They don't know their own power. This session is meant to show them that power.
-
keyboard_arrow_down
Bob Duffy - Fannie Mae's SDLC Journey from Waterfall to Agile
10 Mins
Lightning Talk
Intermediate
A well-defined Software Development Life Cycle (SDLC) is a requirement for many government institutions. However, the typical SDLC process is very "Waterfallish" by nature of it's phase gates and documentation requirements. This talk will explain how the SDLC at Fannie Mae has evolved as the company has transformed from a Waterfall to a lean Agile organization in alignment with Agile best practices.
-
keyboard_arrow_down
Adrienne Rinaldi - Coach the Coach | The Coaching Backlog
45 Mins
Talk
Beginner
You’re a new coach. Now what? This session will help you get started on an agile transformation assignment with a coaching backlog. This session will inform new coaches on “where to start” as an Agile Coach. The session will begin agile transformation challenges followed by common agile impediments, conditions for success, an agile readiness checklist and a coaching backlog including Epics, Features and Stories.
-
keyboard_arrow_down
Gene Gotimer - Build a Better, Faster Pipeline for Software Delivery
45 Mins
Workshop
Beginner
The software delivery pipeline is the process of taking features from developers and getting them delivered to customers. The earliest tests should be the quickest and easiest to run, giving developers the fastest feedback. Successive rounds of testing should increase confidence that the code is a viable candidate for production and that more expensive tests—be it time, effort, cost—are justified. Manual testing should be performed toward the end of the pipeline, leaving computers to do as much work as possible before people get involved. Although it is tempting to arrange the delivery pipeline in phases (e.g., functional tests, then acceptance tests, then load and performance tests, then security tests), this can lead to problems progressing down the pipeline.
In this interactive workshop, we will discuss how to arrange your pipeline, automated or not, and so each round of tests provides just enough testing to give you confidence that the next set of tests is worth the investment. We'll explore how to get the right types of testing into your pipeline at the right points so that you can determine which builds are viable candidates for production.
-
keyboard_arrow_down
Gene Gotimer - A Definition of Done for DevSecOps
45 Mins
Talk
Intermediate
DevOps needs to consider many different aspects of software quality, including security. The term DevSecOps was developed to highlight that security is a focus of the pipeline, not a second-class citizen.
Fortunately, we can define done for our pipeline so that it includes security. Continuous integration can invoke static analysis tools to test for security errors and check if we are using components with known vulnerabilities. Automated deployments and virtualization make dynamic environments available for testing in a production-like setting. Regression tests can drive traffic through proxies for security analysis. From the code to the systems where we deploy the software, the process can be designed to make sure that we follow security best practices, and not produce insecure software.
Participants will learn how to construct a definition of done that focuses on security in a DevOps pipeline. They will see how to define security practices that build confidence that they are doing DevSecOps, and how those practices and criteria might mature over time.
-
keyboard_arrow_down
Glenn Buckholz - Failing Faster with Kubernetes and then Recovering
45 Mins
Case Study
Intermediate
Kubernetes is quickly gaining popularity, but does the technology deserve so many accolades. In this talk we learn what exactly kubernetes has to offer in the DevOps world. We see that as a service it can provide resources for your DevOps pipeline, automated tests, and the application you are trying to build. We visit an example implementation of such a pipeline and discuss some lessons learned about how to balance these three needs. Additionally, we look at what design considerations your application needs to make, you should consider for your automated testing infrastructure, and how all of this can be leveraged to keep consistent CM while deploying rapidly. Lastly, we explore how threading it all together can help you fail fast and recover quickly as well.
-
keyboard_arrow_down
Scott Schnier - Explore It: Risk based exploratory testing
45 Mins
Workshop
Intermediate
For many Agile teams when it comes to testing, it’s all about automation. In this session we’ll learn more about why it benefits teams to develop a non-automated complementary practice of risk-based exploratory testing. Dive into into some use cases where risk-based exploratory testing can provide the most value and discuss some patterns to make this a valuable experience. Take part in a mock exploratory testing planning session focused on testing some of the autonomous driving features available in late-model automobiles, and have a little fun learning by doing!
-
keyboard_arrow_down
John Tanner - Using Metrics for Good not Evil: or How I learned to Stop Worrying and Love the KPIs
45 Mins
Experience Report
Beginner
Using metrics for punitive reasons is a problem as old as time. In software, this is further complicated by the fact that people rarely agree on why we are collecting metrics in the first place. In this session we will explore how we can use metrics for good instead of evil.
By focusing on the goal of system improvement, rather than individual performance, we can begin leveraging data to make a positive difference in how we work while also delving into why we work the way we do.
This session will include real-world examples of problems that organizations create for themselves by using metrics for the wrong intent. We will also discuss examples of good metrics and how they can be used to make our lives better.
-
keyboard_arrow_down
Scott Schnier - Fake Agile : Finding Our Way Back to Agile Values Amidst a Fake Agile Explosion
45 Mins
Workshop
Executive
Now that Agile has “crossed the chasm,” according to the 2017 State of Scrum Report, and become mainstream, is it losing its way?
Join a provocative discussion on whether new Agile methods are starting to mirror the old project management dogma that helped fuel the Agile revolution in the first place. Bring your cell phone for interactive polling and help steer the discussion.We will discuss the following challenging scenarios and ways to respond that are consistent with "being agile."
- The impact of executive mandates for the use of Agile frameworks on all new projects. Does it work?
- Are some people not able to make the transition?
- Use cases of anti-agile behavior done in the name of agile transformation .
- Government contracts asking for offers to deliver 400 points for the lowest price.
Public Feedback