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.

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.

Date driven behaviors are common in many pre-agile organizations. They are as bad as sin and produce bad outcomes when considered through a long range lens. This presentation targeted to managers and leaders in organizations in the early stages of agile transformation. Scott will lead an entertaining and provocative look at how classical date driven behaviors often produce outcomes that are the opposite of what those leaders ultimately desire. Scott will suggest an experiment to focus on the virtue of frequently delivering incremental value as an alternative to those date driven sins.

In this interactive workshop we will examine multiple examples of Antipatterns observed in real-world Kanban boards. In each case we will identify the issues and discuss ways to improve the situation. We will review a number of better alternatives and see how the improvements map to the core principles of Kanban such as visualization, managing flow, and making policies explicit. Brand new to Kanban? Learning by example is a great way to get started! A long-time Kanban veteran? Come to see how many antipatterns you recognize and help firm up our Kanban Antipattern taxonomy and nomenclature!

Kanban is an extremely versatile and effective Agile method that has seen significant growth in popularity over recent years. Kanban’s flexibility has led to widespread adoption to manage business processes in disparate contexts such as HR, loan processing, drug discovery, and insurance underwriting, in addition to Information Technology. Like snowflakes, no two Kanban boards are alike. The downside to this flexibility is there is no well-known and easily accessible library of patterns for designing effective Kanban boards. Like Apollo engineers, teams are expected to design their board starting from first principles. Unfortunately, sometimes teams get stuck with board designs that may not provide the visibility and insight into their workflow they hope to see. Worse, some designs actually may serve only to obscure the situation. Working within the limitations of an electronic board can exacerbate the problem even further. Is all hope lost? Certainly not!

Let’s learn more about effective Kanban system design by examining what to avoid and why. Learning by example is effective and fun!

DevSecOps uses application security practices that have been around for a while. The innovation of DevSecOps is incorporating security into the daily workflow of the team rather than leaving them to the end of a release like many legacy processes do. Shifting security left is made possible by the ability to automate many aspects of security testing and verification. DevSecOps leverages DevOps practices to make application security a first-class citizen in the practices of modern software product development. DevSecOps starts with a culture change mindset of cross-functional teams creating software through collaboration and fast feedback cycles.

The security in DevSecOps starts before the code is written by using techniques like threat modeling and risk analysis to help figure out who might want to attack you and how they might do that. This often ignored security practice can be enabled by following the DevSecOps practices of having a cross-functional team involved in the process from the beginning, including security professionals.

Next, DevSecOps maps application security practices into the build pipeline for a project in order to provide quick feedback about the security posture for any change made to the software. By using automation to allow the team to move quickly while maintaining confidence in the health of the code base, DevSecOps extends that health check to include application security checks. While automation can be used to make security data collection easier it is important to understand what security practices still require a human being.

This talk focuses on how, when, and where practices should be incorporated into a build pipeline to get the most value out of your security practices through automation. It explores what manual security work still needs to be done by a person and how to maximize value while minimizing the effort of human beings.

Have you ever worked with a Business Analyst (BA)? Is what a BA does on an agile project much different from what is done on a waterfall project? All analysts bring excellent communication, collaboration, and trust to their work on project teams. During this session we’ll review the roles a BA can play, a BA's responsibility on the development team, and the skills a good BA possesses. For fun, lets also talk about why an Analyst is part of the 3 Amigos and the complexity of communication channels. Generally speaking, let’s discuss how BAs participate in an agile project’s success and I’ll share some stories about my experience going from waterfall to agile, how I’ve interacted with the PO, and important things I think an Analyst should be involved in.

This session is not intended to offer an exhaustible list of metrics or instructions on how to improve all systems. Rather, the intent is to provide a framework on how to ensure the quantitative and qualitative metrics you use are measuring the right things and how to apply them to a system of continuous improvement. Attendees will have a repeatable framework they can apply after leaving the session.

The session is broken into two main parts.

• Part 1: Identify the right (quantitative and qualitative) metrics that will help people and teams meet outcomes or goals.
• Part 2: Create a cycle of learning and improvement that aligns people and teams to the outcomes or goals.

The Dojo movement is growing in popularity as an approach that helps enterprises transform into world-class product development organizations. Dojos represent a departure from the classic agile focus on delivery, bringing learning and a product mindset to the forefront.

We'll share the emerging Dojo model by way of specific examples and mini-case studies. You will see how Dojos have taken shape at Fannie Mae and other large companies in the last several years. Think of this as a tour of the Dojo for two, main audiences: teams and leaders. Attendees will leave understanding how Dojos can benefit their group, portfolio, and/or organization.

Summary

In this session, you’ll learn about one team’s struggle to improve collaboration and how they sought to shorten cycle time by carefully crafting an experiment with an Andon Cord. The Andon Cord is a Toyota innovation designed to empower front-line employees to recognize issues, initiate a stoppage of work, and work together as a team to quickly identify a path forward. The emergency cable strung above assembly lines became a symbol of the Toyota Way, and has widely been copied throughout the auto industry and beyond.

You’ll be introduced to metrics that show a surprising correlation between collaboration through Andon Cord pulls and Cycle Time!

“Evolution is a tinkerer.”, Francois Jacob, Nobel Price wining Biologist

To further enable Scrum Masters to mature specific capabilities, and achieve more consistent practice across the enterprise, Fannie Mae’s Agile Center of Excellence (CoE) embarked on series of evolutionary initiatives. While we would like to represent that these activities were premeditated and intentional, the reality was that the activities were emergent, evolving with, and in response to, the larger organizational transformation. During this session, we will detail the evolution of initiatives over the last several years intended to support the Scrum Master, the triggers that precipitated the initiative, the outcome of the initiative itself, as well as lessons learned given the benefit of hindsight.

Metrics are the bane of many organizations, getting fascinated on measurements that don’t matter or can drive improper behaviours. In this session, we walk through a simple grouping for metrics where the groupings not only call out the metrics, but their limits, and help guide to better metrics.

Are customers beating down your door before the product is even ready? Do you have an inexhaustible number of new ideas on the horizon? And are your teams cranking them out month after month? If you answered no to some or all of those questions, then... your employees are probably afraid of emotions, and it's standing in your way.

Yes, I did just say that emotions are the thing in your way.

And you're not alone. The Age of Reason brought us Scientific Discovery, which is vital to continued survival, for people and companies. It inspired the Industrial Revolution. We reached for the stars, and touched other planets. So we raised up idols like Mr. Spock from Star Trek, and phrases like, "It's not Rocket Science". The Toyota Lean Movement inspired additional data-driven revolutions like Agile and DevOps. We automated our factories, and our stock market transactions. We created machines that can learn, and cars that can drive themselves.

And... we tricked ourselves into thinking that WE also became logical in the process.

But we're still human beings. In 2002 the Nobel Prize was awarded to two economists for research that proved that the decision making part of our brain is not connected to the logical part of our brain. Decision making is still done with our emotional brain. The emotions of your customers prevent them from buying. The emotions of your managers prevent them from making the right decisions. The emotions of your employees prevent them from delivering great ideas. And you can't just remove emotions from the equation. You must understand them, embrace them, and journey through them, to get to the other side. And on that other side you will coincidentally find our old friend, Reason.

If you don't start embracing emotions, talking about them, and designing for them, then you will be left behind. It's what makes Apple and Amazon successful. (It's why Donald Trump got elected.) And it's why your products are failing.

Transformation programs usually happen periodically and years apart. They introduce new processes and require organizational restructuring, while they often do not create organizational behavior change. They often ignore the inherent behaviors that have led to the unsatisfying status quo in the first place. These programs separate “the work” from “how we improve the work”.

Rather than having transformation programs every few years, can we embrace change and experimentation as the daily way of work? We can, when managers act as coaches for their teams on experimentation as the way of work. Meaning, when teams experiment they enable delivery, improvements and innovation.

This is an activity-based session that demonstrates the non-ending organizational journey towards growth and innovation. We will follow transformation approach based on Kata Thinking Pattern(KTP) to explain how teams experimentally introduce improvements guided by a universal model.

With minimum lecturing and focus on doing, you would experience first hand the KTP mindset for on-going transformation where managers are coaches. We will use Improvement Cards that are based on industry case studies for digital transformation

We will be organized into teams each has 4-6 people.

This session can be relevant to you, if you are interested in Agile Transformation and Lean Management.

How do you grow a continuously learning organization? If certifications and wikis were enough, organizations would be crushing it. In this session we look at how we learn in complex domains - focusing on tacit vs explicit knowledge; context learning; and growing coaches and teachers.

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.

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.'

Unlike agile at the team level, enterprise agility requires cultural change throughout the organization to be successful. But, cultural change is far from easy. Much like the roots of a tree, culture runs deep, so it takes persistence and the right approach to achieve success.

In this talk, Donald Patti and David Bulkin will describe multiple successful plays, or approaches, to enterprise agile transformation, providing attendees with a number of practical ways to understand and change an organization's culture.

My team was asked to build an integration with an old legacy application which had no programming API whatsoever, and we were so excited. How did we tackle that challenge? Did we succeed? What happened next? Come and listen to find out. And I promise the ending will surprise and/or depress you.

The job of an IT Project Manager is a difficult one and traditional approaches to governance tended to make it even more difficult. In the best of times, these approaches employ Independent Verification and Validation (IV&V) as an impediment to project teams; in the worst of times, they set IV&V up as judge, jury, and executioner for projects.

But just because that’s the way things are often done doesn’t make it right. Oversight entities can be healthy enablers instead of adversarial obstacles.

Traditionally, the role of a governance framework is to enumerate statutory requirements, promote best practices, and reduce risk. The purpose of an IV&V team within this world is to ensure that appropriate elements of the framework are followed so as to mitigate risk. Larger projects typically present greater risks and require more controls; smaller projects less so.

The big challenge has always been in defining what is required for a given project.

Project sponsors want working solutions. The CFO wants tight budgets and lower costs. Project teams want happy sponsors. These stakeholders often oppose IV&V because the cost/benefit case for everything it promotes can be difficult to justify in comparison to business needs. Also, when these stakeholders do not pay directly for development costs they can have a very high tolerance for risk – but that’s an issue for another day.

What if we re-frame IV&V from risk mitigation to added value?

• What if, instead of requiring reams of documentation, IV&V identifies information it needs in the tools and processes already in use?
• What if, instead of forcing teams to follow so-called best practices in cookie-cutter fashion, IV&V provided the metrics and data they need to take specific action when it is most effective?
• What if, instead of reciting regulations to teams, IV&V worked hand-in-hand help teams meet them in the most efficient ways possible?
• What if, instead of looking for defects, IV&V asked teams how it could help and then provided the specific support they need, where and when they need it most?
• What if IV&V helped to onboard new teams and train them in specific skills and resources they will need to succeed?
• What if IV&V assessed team needs as they worked together and then developed training courses to address those needs?
• What if IV&V built project dashboards to present useful information from development tools that helped teams surface problems quickly?
• What if these and other steps help project teams deliver value while meeting regulations, reducing risk, trimming costs, and increasing quality all around?

What if? There is no what if. This works. It really does.

These are just some of the innovative governance strategies that our IV&V team at USCIS has employed and it has made all the difference.

Let us tell you more about them…