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.

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!

The federal government loves modernizing software systems and it isn't wrong: stale, decaying software leads to major headaches and eventual catastrophe. Modernization efforts, however, have big risks and big failures.

There is an alternative: software renovation. That is improving, updating, and upgrading the software system one piece at a time while it continues to operate.

Dane has participated deeply in three US government modernization projects. Each project followed a pattern of pitfalls, scary "go-live" transitions, and unpleasant trade-offs.

Renovating legacy software is frequently a better option. The software system continues to gain functionality at the same time that its design and performance are improved.

Agile at the team level fosters self-organization by leveraging constraints. Timeboxes, Work in Progress (WIP) Limits, and clear operational definitions are excellent examples of the kinds of constraints teams regularly employ to deliver reliably. Are you familiar and comfortable with these ideas, but uncertain how to apply them at larger scales? Are you looking for techniques that will allow you to harness the creativity of your teams to enable self-organization at scale? If so, this session is for you.

I’m passionate about applying concepts from Complex Systems Theory (as developed by Dave Snowden, Alicia Juarrero, Bob Artigiani, etc.) to the work of software teams. My colleagues and I at Excella have been exploiting these ideas by using a variety of patterns borrowed from different theories and frameworks to allow our teams to grow like healthy plants in a garden. From Large-Scale Scrum (LeSS) we leverage the concepts of a single product backlog and a shared cadence. Kanban principles of visualizing the work and limiting WIP help align the teams and foster greater collaboration. Dave Snowden’s emphasis on Homo Narrans—the human as storyteller—has provided a framework for clarifying and promulgating common values, which are essential for decentralized decision-making. Collectively, these mental models created an environment that helped us scale one of our engagements from three teams to eight over the course of a single year.

Shipping code is hard and it is rough! It doesn't have to be. Using Docker, Heroku and CircleCI you can set up a world-class Continuous Integration and Continuous Deployment pipeline in an hour with advanced functionality like Heroku preview apps, provisioning servers on-demand for to scale and containers that leverage layering to enforce Enterprise requirements, while giving developers access, flexibility and speed to get their work done. With duluca/minimal-node-web-server docker image and how you can tailor it to build your micro-services or web servers in a matter of minutes using Docker and deploy your web app on the cloud.

Customers weren’t satisfied! The process took too long! The end product didn’t perform to specifications! Does this sound familiar?

A century ago, the U.S. Navy’s ship design process had serious problems, ones we would recognize and understand today. Come learn how these problems were solved in a large, real-world, organization through minor changes in structure and process. These changes illustrate the importance of:

• Gathering early feedback
• Rapidly iterating to expose unknowns
• Using multi-disciplinary problem-solving
• Employing Agile techniques outside of IT

Are you excited by the idea of Business Agility, but unsure how to create it? Learn new techniques by looking back. In the early 20th century, the U.S. Navy successfully leveraged Agile approaches to harness new technologies, encourage organizational learning, and develop a sustained pace of innovation, all key aspects of Business Agility. Find out how!

I’ll describe what the Navy achieved, explain why it worked, and illustrate how similar approaches can be used today to create greater Agility in our businesses and organizations. Some specifics include:

• Fostering innovation by the use of regular feedback.
• Employing safe-to-fail experimentation.
• Promoting evolvability through loose coupling and bounded autonomy.
• Balancing exploration and exploitation to identify and harness new ideas.

Does your Scrum team start all its stories on Day 1 of the Sprint? Do stories sometime carry over into the next Sprint? Or perhaps testing always gets crammed in on the last day of the Sprint? If any of these sound familiar, your team may benefit from improving its flow.

Flow metrics are common with Kanban, but can provide tremendous value to any team, including those using Scrum. In this session, we’ll start by exploring the value of achieving a smooth flow of work (versus simply achieving maximum utilization) and give simple ways for your team to measure its flow. We’ll look at examples of metrics including lead and cycle time, throughput, and the cumulative flow diagram (CFD), reviewing what each represents, easy ways to collect them, and how they can be used in both a Kanban and Scrum context. You’ll leave the session knowing how to interpret and capture all these valuable metrics, so your agile team can measure and improve its flow.

Story point is an arbitrary relative measure used by Scrum/agile teams to define the effort required to implement a story or feature. This is a metric to measure the cost related to the implementation of story points. This metric is called Story Point Cost. It should allow to track development costs and also make the Scrum team aware about the budget issues of their project and for product owners to easier compare cost to gained value.

Agile is an incremental and iterative approach to delivering value to our customers. But too often we assume it’s really all about ways to slice work into smaller batch sizes and that both approaches are fundamentally equivalent. However, there is a crucial difference and this lack of awareness is a major contributor to projects and teams that are AINO (Agile In Name Only)!

In this session, we will discuss how to differentiate between incremental and iterative approaches, their strengths and weaknesses, and why you really need both. We will explore the many ways in which iteration shapes the core of Agile practices, how it supports and enables the benefits of agility, and how understanding its awesome power is a key step in moving from “doing” Agile to truly being agile. In addition, we will take a close look at the practical implications of when to use each approach by discussing real world scenarios, highlighting common Agile anti-patterns and (re)examining familiar story slicing patterns.

You will walk away with both a better understanding of one of the most important underlying principles of agility and immediately applicable insights for your daily work!

Losing good people during your transformation? Getting more resistance than you expected? You may be producing unwanted reactions in the way you are leading your people through change.

If you want your Agile transformation firing on all cylinders without the harmful side-effects, managers at all levels should focus on becoming Catalysts. Much like a chemical catalyst, your job is to help boost organizational performance by creating a healthy environment and providing the needed support.

In this interactive presentation-tutorial, we’ll explore how you can do that through some simple techniques that anyone can do; extracted from Fearless Change and Liberating Structures. We'll relate these techniques to how trust works and give you some powerful ways to improve your organizational trust.

Agile encourages us to eliminate activities that don’t add value and find the simplest solution possible to solve our business needs. For many teams, that can lead to a state where collaborative design no longer happens or is discussed on a whiteboard that gets erased after the conversation.

How then, can you share the knowledge with team members who don’t work on that feature, or join the team after the feature is built? What about distributed teams, are they unable to have collaborative design because they don't have a whiteboard?

I had those same questions in 2012, when Ron Garton of the Agile Coaching Network showed me a lightweight solution and we stopped creating traditional design documents. Ron provided me permission to bring that solution to the agile community through sessions like these.

This solution helps everyone on the team understand what they will create or change in the current systems before it’s built, which can also be retained to increase the domain knowledge for that system later. Though the template itself can be helpful, like many agile tools, it’s the conversation that it starts that’s truly powerful.

Have you ever been in a technical interview, stuck at a whiteboard or solving a brainteaser, and thought “there must be a better way”? Good news: there very much is.

Agility and adaptability are crucial for a development team's success, but how often do we target for agility when considering who to bring into our team? And how do we set expectations for agility from the first time this potential new hire begins evaluating our team?

In this talk, I walk through my philosophy & provide practical tips for running technical interviews that are primed for success.

Sure, we would like everyone to have an agile mindset and focus on continuous improvement, but sometimes as Agilists we need to work with stakeholders who don’t agree with our priorities or our methods. When you need to get something done in a bureaucracy, how do you adapt? Every place you operate has a unique combination of people, processes, and problems. We'll discuss general principles that will help you navigate successfully.

Over the last 5 years, Agile approaches have seen widespread adoption across the US Federal Government. Where real commitment is given to proven Agile frameworks and techniques, programs do see significant improvement in value delivery and speed. But unfortunately often, ‘Agile’ nomenclature is used while perpetuating behaviors that make real improvement impossible, and may actually make the lived experience worse for participants or stakeholders. And where Agile approaches fail, they add to a narrative that real methods won’t work in this environment. Many of the anti-patterns I’ve seen working as a Coach in the Public Sector are rooted in decision-makers clinging to 5 myths about Agile in Government. This talk will explore these 5 myths, where they come from, and some ways out of them.

It’s hard to overstate Benjamin Franklin’s contributions to the world. A true polymath, Franklin is best known for his statesmanship and diplomacy, his scientific insight, and his creation of the Scrum software development methodology.

Wait, what?

Okay, Franklin was ahead of his time, but he wasn’t telling us how to build software more than 200 years ago. Yet like the founders of Scrum, Franklin was obsessed with finding better ways to work and shared his productivity strategy in his autobiography. His to-do list is one of the first in the historical record, but the way he used it anticipates Scrum – and Agile principles in general – in many ways.

Limiting work-in-progress, or WIP, is a core principle of Kanban, and is a common recommendation to teams using Scrum or other frameworks as well. Yet the idea that working on less can lead you to get more done seems to defy common sense. Even those who understand the reasons for limiting WIP can struggle with resistance from team members or leaders when putting the theory to practice. This talk will review the concept of WIP and explore in depth the reasons for limiting WIP: enhancing focus, reducing cycle time, optimizing flow and making bottlenecks visible. We will give strategies for starting out with WIP limits and suggestions for what to do when a limit is reached. Attendees will also participate in a short simulation that will illustrate the concepts in practice, and that attendees can use on their own projects to help overcome skepticism of WIP limits in their organizations.

Attempting to deliver a project and maintain an agile mindset at the same time can feel fraught with peril. Unforeseen circumstances, the challenges of working in team of actual human beings, and organizational inertia act like riptide currents, pulling you away from your delivery, your team's commitment to agile principles, or both.

All is not lost! In this talk, I'll describe some symptoms of agile dysfunction and their antidotes. We'll explore some lessons I've learned as a technical lead working with agile and "agile" teams, holding it together with duct tape and a little help from my friends.