Sometimes you eat the bear, and sometimes… well….the bear eats you.

We tried our best. We worked hard trying to transform the way human services were delivered. Our mandate was clear—we needed to deliver new systems in weeks, not years. We needed to modernize our legacy systems. We needed to make our systems user friendly, so the social workers didn’t have to work across four different applications just to help someone apply for food stamps. In short, we knew we needed to change just about everything. Sounds familiar? Maybe you are undergoing a similar radical change at your organization.

Come join us for a deep dive into the lessons learned regarding an unsuccessful large-scale agile transformation at a $20B agency with a 500+ person IT department. What went wrong? We will peel away all the layers of the onion to start at the core, and examine each aspect to find out!

We will start by thinking about culture. What kind of organization are we talking about, and what implications does that have for where and how we should start our transformation?

We will look at transformation strategies. Should we start top-down? Bottom-up? In the middle, then spreading out? We will talk about what we did, where it went wrong, and implications for future transformation efforts. We will introduce the concept of flight levels and see how that may help us clarify and communicate a strategy.

We will continue on, to ultimately examine every aspect of transformation including training, engagement, communication, tooling, software architectures, metrics, and more. I hope that our lessons learned can help you make your large-scale agile transformation a success!

Why should IT have all the fun? This interactive workshop will explore how non-IT organizations are leveraging Lean and Agile principles to improve the way they work. We will explore how Kanban boards are being used in surprising and innovative ways to track things like insurance underwriting, sales funnels, and HR team workflows. First, we will review a few examples as a group. Then things really get interesting as you will be given a business scenario outline and asked to try your hand at designing a Kanban board to visualize the given workflow. Managing a drug discovery process? Preparing legal cases for trial? Managing a large portfolio? Kanban is a perfect fit! By reviewing and analysing different examples across multiple disciplines, and developing your own alternatives, we hope to generate new insights and deepen our understanding of how to leverage the power of visualization in your own organizations.

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!

Is it possible to deliver software improvements faster and with better quality in a highly regulated environment? What if the organization only uses off-the-shelf commercial packages like SAP rather than custom software? Oh, and much of the team is still learning the ropes? And by the way, our business users are unavailable during monthly and quarterly close, and to top it all off whole divisions go off-line for weeks or months at a time during refinery “turnaround” events? How can we improve cycle times, if it sometimes takes us months just to figure out how to design a solution for a single request?

In this session, we will examine a case study at an energy company that needed to increase their speed of delivery and their level of quality, while at the same time controlling costs. They started to adopt Kanban a year ago, by visualizing their waterfall process on a board and holding a daily stand-up. However, cycle times were still unacceptably long, and the board did not change much day-by-day. Worse, the business was getting more impatient and the backlog of urgent requests was growing longer. The team was ready to take the next step and deepen their kanban implementation.

We will examine a number of improvements that were made and the impact of each one of them. Larger work items were broken down into user stories, enabling progress to be tracked at a more granular level and helping the team to break down difficult problems into smaller, bite-sized chunks. Defects were captured individually on the board so large items did not appear to “stall” for no reason. Time-boxed “Spikes” could be created to capture efforts required to identify alternatives and reduce risk in design or implementation. The kanban boards went through multiple iterations as we updated them to better reflect our new process.

Hand-in-hand with these improvements came training and practice. How do we create properly formed user stories? When is it appropriate to create a Spike? How can we make process policies explicit—especially the Definition of Ready and Definition of Done?

Perhaps the biggest change for any team moving away from waterfall is the difference in the way team members interact with each other. Analysts and developers used to formal, defined handoffs gradually learned to work together more closely during all phases of a work item—from cradle to grave. Introducing this new way of working together exposed many concerns and biases, most of which have roots in the very different ways that analysts and developers think and see the world. We will review this phenomenon and talk about different techniques and approaches to help mitigate concerns and move forward.

Come join us for a stimulating, thoughtful conversation about one Fortune 200 company’s journey towards a deeper and more complete implementation of Kanban. Perhaps the “alternative path to agility” is right for your organization?

Software development is hard.  For all our talk about “sprints,” anyone who has been involved in a major software development effort will agree it is more of a marathon.  Well, if we have to run a marathon, wouldn’t it be nice to start on mile marker 2?  Some inline skates would be nice, as well! 

In this talk we will describe a new technique for jump-starting application development, with software seeds and generators.  

A seed project pre-integrates a set of technologies, with a minimal working set of services and screens, a set of example automated tests and a fully tricked-out DevOps pipeline.    Like an erector set (or a Raspberry Pi Maker Kit—to use a more up-to-date analogy), a seed is designed to be used for building larger projects.

A generator can be used to generate a new project (by customizing seed templates, for example), and, later on, to generate new software components from blueprints as they are needed.  Like a casting mold for molten metal, a generator helps ensure new components follow naming, testing, and design conventions.

A properly configured set of seed and generator projects can provide a number of important benefits:

• new project team members can explore and learn using a project small-enough to get their arms around.
• New insights, components, and design patterns can be quickly promulgated and shared within and across organizations

Of course, all this does not come for free.  Seeds and generators must be regularly maintained, and they require senior expertise to build and maintain them.  However, even a junior team can derive benefit from downloading a pre-existing example from one of the many online sources such as yeoman.io. 

In this talk we will explore the process for building and maintaining seeds and generators using a case study of three seed projects developed for a NYC municipal agency using Ruby on Rails, Microsoft C# .NET Core, and AngularJS 4, technologies.  We will talk about the lessons learned, commonalities and differences between technology stacks and what it takes to maintain the seeds and generators long-term.   We will also talk about our experiences using the seeds and generators to build production applications and helping other groups to do the same.  We will discuss the issue of achieving buy-in, even from development groups that did not participate in the initial seed development.    Finally, we will explore next steps and speculate on where the next major leaps in software development productivity may come from.

NOTE: This talk can be delivered at the intermediate or advanced level, depending on the audience

A deeper insight in how and why agile works is the pre-requisite for business agility and the agile organization. Flow thinking has proven to be foundational. But the concept of flow is not an easy concept to master for people that have not experienced it. Rational explanations of flow only go so far. Without intuitive understanding based on experience it may not be easy to mobilize a team or organization into action.  By visualizing work, reducing multi-tasking, and removing obstacles, lead times may be drastically reduced leading to better outcomes.

Introducing the Okaloa Flowlab board game-- an exciting new approach to learning how to think about flow through practice and simulation.  With Okaloa Flowlab we will perform a series of experiments through board-play style simulations that reflect real work environments.  This session provides a quick introduction into what is typically a three-hour interactive class.  In order to fit into the 45-minute timeframe, we will provide a “before” vs “after” game play rather than introducing agile policies incrementally, but the end result will be the same.

We first simulate a conventional work environment that reflects a “mechanistic” mindset characterized by a focus on resource efficiency, command and control, and specialist workers, so that participants will viscerally experience which roadblocks need to be overcome.  We will then implement a number of agile policies and practices (including pull of work, peer collaboration and limiting the amount of work in process) and observe the results.

This learning session enables attendees to experience first-hand the effect of adopting agile processes in a safe-to-fail simulated environment. 

Each team consists of 3-5 people seated around a table with the board (ideally 4 people and 1 person taking up the role of project coordinator).

Participants will discover the power of visualization, limiting work in process and collaboration, and understand the fundamental difference between resource efficiency and flow efficiency.

Come check out this exciting and innovative new way to learn about agility!

You are adopting Agile practices throughout your organization, and you set up a shiny new set of tools to support it.  All of your teams have captured their backlog and are running their Sprints (Scrum) or continuous-flow (Kanban) process.  Great!  There is only one problem.  How can management see at a glance what is going on in each effort?

• How do we know if each effort is “on track” or headed for disaster?
• How do we know when we have capacity to take on new initiatives?
• If a new high priority/urgent initiative is proposed, how can we quickly see if it would impact other efforts at the same or higher business priority?
• If a new high priority/urgent initiative must be undertaken, how can we quickly analyze resources and schedules for what is happening currently, so we can do an impact analysis?
• How can we avoid getting bogged down in the day-to-day minutiae of user stories, story points, and bugs and quickly identify important blockers, major risks, or emerging trends that could have ripple effects?

Through a case study involving a $1B municipal government agency, we will describe the process of configuring a set of tools to feed a one-page dashboard displaying current and proposed initiatives – enabling management decision-making.  The tools include Atlassian JIRA, BitBucket, Bamboo, and LeanKit, but the lessons may be applied to other similar toolchains.   We analyze both the technical work involved, as well as the important process and cultural changes we had to make in order for this to happen.   All changes automatically roll up from the team level to the portfolio level, so that progress, blockages, and risks are always visible.   Senior management can drill down to get details if needed.

Perhaps “Agile PMO” is not an oxymoron, after all.

Behavior Driven Development / Acceptance Test Driven Development (BDD/ATDD) is a new, exciting approach to developing software that has been shown to reduce rework and increase customer satisfaction. While other testing tools focus primarily on “are we building the thing right?”, BDD tools such as Cucumber and SpecFlow attack the problem of software directly at its source: “are we building the right thing?” By retaining all the benefits of automated unit testing, while extending them upstream to cover requirements, we cut the Gordian knot of risk and complexity to unleash hyper-productivity. 

Why is BDD so effective?

• As a form of Test driven design, BDD helps produce frugal, effective and testable software.
• As a development tool, BDD frameworks like SpecFlow provide many convenience functions and are pre-integrated with powerful libraries like Nunit and selenium to make writing tests a snap.
• As a collaboration tool, BDD helps ensure the “three amigos” (tester, analyst and developer) sync up – ahead of time.
• As a facilitation technique, BDD enables product owners to efficiently provide the team with concrete examples that clarify the true intent of a user story and define the boundaries.
• As a reporting tool, BDD captures functional coverage, mapping features to their acceptance criteria to their test results, in an attractive hierarchical presentation.

Want functional documentation? How about documentation that is guaranteed to be correct, because every feature maps to its test results? Witness the holy grail of traceability – executable specifications.

We will spend a few minutes talking about the context and pre-requisites, so attendees have an idea of where BDD fits in, and what type of investment they are signing their teams up for. We will see that in return for a modest amount of investment in tools and training, very significant benefits can be realized, and the benefits compound over time.

This workshop then dives right in to Gherkin, the structured English language technique used to capture BDD specifications. We will spend the better part of the session learning the tricks and techniques that make for robust and maintainable gherkin specifications. We will review and critique lots of examples, both good and bad.

We will review several examples of reports generated from BDD tools, to provide context and to immediately highlight the bottom line business value that makes an investment in BDD so worthwhile.

Come and learn why Behavior driven design is taking the software world by storm!

At a Federal Agency or a large commercial company you may get a chance to work on a major program that makes a real difference in people’s lives.   But the (legacy) software behind such programs is often large and complex, and therein lie some challenges.  Here are some of the challenges we faced on a major 15+ year old legacy system comprised of 2M lines of source code:

• maintenance costs were escalating
• It seemed like every time an issue was fixed, it caused two more
• Lengthy delays between major software releases
• New releases suffered from high priority bugs that had to be hot-fixed immediately
• The software was taking longer and longer to be fully tested; in fact, it became practically impossible to test every feature.

When looking to implement agile practices on a legacy program, it is hard to know where to begin.  Innovative Silicon Valley companies like Etsy leverage DevOps and Continuous Delivery practices to achieve new levels of automation and agility, shrinking development lead times and deploying to production many times each day.  However, it can be a struggle to implement these practices for legacy systems that run our core businesses.  To make matters worse, the agile community offers relatively little practical guidance for implementing DevOps practices in legacy environments.  Fortunately, the Kanban Method provides a practical way to gradually evolve these core systems towards achieving DevOps cost savings and efficiencies, even if you don’t have a massive budget.

Through a case study involving a criminal justice system for a US government agency, we will examine how the Kanban method helped us identify and remove the barriers that prevented us from implementing DevOps automation for legacy systems.  Just as importantly, Kanban provided the means to measure the efficacy of our efforts, prompting us to course-correct when necessary. We will review some interesting examples using the Microsoft technology stack, but these lessons apply equally to Java, LAMP, MEAN, or any other set of technologies.  The end result was better quality and collaboration and faster delivery of value to our stakeholders.  Perhaps it is possible to teach an old dog new tricks, after all.

Agile software development methods are now well established in many commercial organizations, and are starting to make inroads into government contexts. There are reports of software development projects using Agile methods that achieve significantly higher levels of productivity and quality compared with projects that used traditional methods. When it comes to brand new “start from scratch” software projects, a wealth of information, advice, training, and literature exists to help guide practitioners and speed them along the path to agility. Unfortunately, most such publicly available resources have relatively little to say when it comes to legacy systems. However, there is a small but growing amount of evidence that agile practices can yield compelling benefits for legacy projects—even those that have been previously successful using traditional methods. Our experience suggests that agile practices need to be customized and introduced in a different order into a legacy project. This presentation provides an analysis of the differences between legacy projects and new software development and the implications for the adoption of agile methods.

Many Federal government agencies are implementing Agile methods in addition to or in lieu of traditional waterfall lifecycle models.  However, comprehensive documentation is often still required by Federal IT governance, legal, regulatory, or statutory frameworks, or to meet outside audit or “watchdog “ requirements.   The Agile Manifesto values “working software over comprehensive documentation,” but that does not mean that Agile teams cannot or should not produce valuable documentation.  Although there are some well-publicized Agile success stories in the federal space, some agile federal projects are receiving criticism for failing to meet applicable standards when it comes to documentation deliverables.  With Agile’s emphasis on small, lean teams and intensive technical practices such as pair programming, meeting documentation requirements set forth by Federal IT governance poses challenges for Agile teams in the Federal space.  This session will review the documentation that is typically required in a heavily regulated environment, and discuss specific techniques for reducing, replacing, generating, or “slimming” the document deliverables.  Specific tools, techniques and best practices will be reviewed and analyzed with “before” and “after” snapshots and a look at cost versus benefit.    Documentation generation is an area of intensive activity with some very exciting new developments that can change the game significantly for the better!  Tune in to share insights and discuss strategies for breaking down one of the last big barriers to significant agile adoption in the federal space.

Using tools like TDD and ATDD, Agile provides the means to be confident that your brand new software is well tested-- even for life critical situations such as criminal justice software.  But hold on a minute!  It is a rare mission critical system that is built completely from scratch.  There are always legacy components your team didn't build or doesn't control.  Maybe the previous contractor built it-- but now they are gone and it is your problem.  How can you be certain that everything functions properly in such a situation?  How much testing is enough?  How can you know whether a system has been tested?  These are the questions that standards such as CMMI and PMBOK seek to answer with traceability.

The debate about traceability has been raging for a long time, with passionate advocates on both sides of the argument.   Projects following traditional waterfall methods, and projects that conform to PMBOK or CMMI standards often create and maintain a requirements traceability matrix, or RTM, a document that traces “shall” requirements to functional capabilities and testcases.  Some Agilists argue that the RTM is rarely consulted in practice, so the significant efforts required to maintain such a document are “waste.”  Others point out that agile practices such as TDD provide all the traceability that may be needed. This talk will explore the underlying reasons why traceability may be important and worthwhile in many Federal government contexts, and review exciting new technologies that may provide an “agile answer” to this conundrum.