Your in a predicament. The system needs re-architecture. There are a lot of bugs to stamp out. You need to turn it off, but you can't - it's mission critical to your business.

When most of us learn about Agile, the examples and stories we are told are from a Greenfield perspective; Greenfield meaning new development. Most organizations that aren't start-ups have many applications already in use; this pristine start just doesn't exist. Existing software needs to be maintained and continuity of operations is the highest priority; these are the circumstances of Brownfield development. This is essentially any application past its first release. Making this more difficult is that teams need to maintain legacy code and update antiquated architectures.

This session will cover techniques you can use at the team level to help this maintenance activity. We’ll specifically look at the use of the Mikado Method, Kanban, and some indicators you may want to use to analyze your application portfolio from a maintenance perspective.

Everyone wants to know which Agile metrics really count, and why. But a lot comes down to context: who's asking, what decisions are on the horizon, how you communicate, and so forth. Add scale, and you've got a major challenge.

David Bujard, Dante Vilardi and Nate Conroy have spent the last few years trying to figure how to make agility measurement effective at a big federal program. In this talk they will discuss lessons learned from numerous experiments -- those that produced results, and those that didn't.

David and Dante are Agile coaches who support a transformation program at USCIS.

Unfortunately, it’s often an organization’s “real managers” – those with ongoing accountability for people and outcomes – who get caught in the middle of today’s Agile transformations. This can disrupt their teams’ commitments, push hard-earned experience to the sidelines or – what’s worse – make real managers a scapegoat for the transformation errors of others.

This program offers an alternative: becoming indispensable, by using the tools uniquely available to today’s development, testing, business analysis, release, program and infrastructure managers to help fix Agile implementation problems. Surprisingly, this is not especially difficult or risky; it’s simply a matter of recognizing the signs of stalling agility, and using some simple but powerful organizational levers to move everyone – teams, coaches, even executives – closer to a solution.

Contrary to widely held belief, most teams cannot be merely coached or directed to lasting transformation. Success depends, just as much, on the Agile routines these real managers put in place. This can be a key to taking control of your career in the new Agile workplace.

If you see Agile teams struggling, coaches complaining, or believe your current contributions to Agile success are in question, this program is for you. We will review some unique sources of Agile leverage – advantages which you – but no coach or senior executive – possess: a wide-angle view of functional performance, knowledge of hidden barriers, and the authority to ask real people for improvement.

Most agile teams focus on following a delivery process and overlook finding ways to improve the process. The essence of agile is focused around the idea of continuous improvement via inspect and adapt. In this session, we will be providing insights around evolving your measurements using data in order to embrace a different mindset. A mindset that encourages more facts and less judgment. A mindset that encourages organizations to move from “performance” to decisions, behaviors, outcomes, external evaluation to “Let’s figure this out together”, proof to evidence, answers to questions, precision to speed and from objective to subjective (but with lots of facts!)

Some of the key aspects of successful Agility are slicing our work into small chunks, prioritizing this work, and having our people pull the work at a rate they can sustain.  How do we do that? What does limiting work in progress mean? Is it more beneficial to have people working across stories individually or swarming on stories? What is the effect when specialists have to work on specific stories due to their unique skill sets? Why do we slice stories? When we choose to not have people remove impediments, what impact can that have?

This session will immerse you in a simulation of what a team goes through when pulling work in an iterative approach such as XP or Scrum.  It was created in response to seeing teams make poor choices in what they optimizing; often choosing to optimize the utilization of resources as opposed to maximizing the effectiveness of the people.  This team also had chosen an architecture where specialized talent was hard to come by, limiting the overall effectiveness.  

We'll explore what prioritization does for us; how limiting work in progress and slicing stories helps in getting us to done. We'll introduce impediments and make choices whether to work on something else or work to remove them.  We'll introduce a specialist and see what the impact of that is.