Most of us have heard the mantra, "Slice your User Stories as thin as possible!" In my travels as a coach since the early 2000's, however, I've rarely seen stories that truly are thin. What are these rare creatures? Why don't I see more of them? Having good User Stories is crucial to the success of teams using them as the means for determining what needs to be built to fulfill a customer's need. Having thinly sliced stories is even more important!

This workshop provides a level set on what stories are and explores why slicing stories very thin is important, what benefits thin slicing provides, and how to do it. Through a combination of examples and practical application in the workshop, you'll leave with slicing techniques that you can apply at your next planning session.

This workshop shows how Test-Driven Development (TDD) is used to enable emergent design. Using a simple but representative example in Java, the presenter will demonstrate how a low-level design naturally emerges when using the TDD cycle of test/code/refactor. The audience will be involved by suggesting the next steps and also by pairing with the presenter.

Note that the goal of the session isn't necessarily to have a complete working example at the end, but to illustrate the process of low-level design through TDD.

You may have heard about the #NoEstimates movement, and even #NoProjects. Both of those concepts challenge the assumptions behind two key aspects of delivering software. But what about the process itself? Do we even need approaches like Scrum, Kanban or XP - let alone SAFe, LESS, NEXUS, DAD - in order to be successful? Is following a pre-defined process helpful at all? Is there a simpler way to be effective?

This session examines the two key principles common to all successful software delivery approaches and builds out based on the experience of the participants. Like #NoEstimates and #NoProjects, the name doesn’t really mean to eliminate process altogether, but rather to build a process that works for your team, in your business domain, with your technology stack.

Most of us have heard the mantra, "Slice your User Stories as thin as possible!" In my travels as a coach since the early 2000's, however, I've rarely seen stories that truly are thin. What are these rare creatures? Why don't I see more of them? Having good User Stories is crucial to the success of teams using them as the means for determining what needs to be built to fulfill a customer's need. Having thinly sliced stories is even more important!

This workshop provides a level set on what stories are and explores why slicing stories very thin is important, what benefits thin slicing provides, and how to do it. Through a combination of examples and practical application in the workshop, you'll leave with slicing techniques that you can apply at your next planning session.

Remember the Healtcare.gov fiasco? Well, up in the Great White North of Canada we had our own version of that débâcle when the federal government attempted to replace and consolidate the compensation systems across the public sector.

When the Phoenix Pay system for the Canadian federal government was released in April 2016, it had severe problems affecting some 70% of the roughly 300,000 people who the system was intended to pay. It has been fraught with issues ever since resulting in under and overpayments of those employees, and in some cases no payments at all. Hundreds of millions of dollars have been and will be spent to correct the pay issues and update the system. The people working in the consolidated pay centre in New Brunswick have been overwhelmed to the point that retired compensation workers have been recalled to deal with the crisis. This was yet another example of the ineffectiveness of the antiquated approach that the government used to deliver Phoenix.

When the 2018 budget was tabled, nearly half a billion dollars was allocated to fixing Phoenix! What seemed like a footnote to that was $16 million over two years to study how to build the replacement system.

Study. That’s what finally broke me. I had been grumbling at the stories of Phoenix for years, but this finally triggered me to do something. I began tweeting to government officials, and the Prime Minister himself, that they were going to end up taking the same approach and making the same mistakes again. I wrote a series of blog posts detailing the approach that I’d take, and given my 30+ years of experience - over 15 of which were building systems small & large in the public sector - this was anything but armchair quarterbacking.

This session is about what I believe the government should have done to replace Phoenix, and what has happened since my 2018 Budget Day tweetstorm and subsequent blog posts. Ideas from the audience will be solicited and we’ll discuss how we would leverage the collective experiences of the group to deal with building a system as large and complicated as one that needed to pay some 300,000 people from 40 departments and agencies and a number of unions. These experiences can then be transferred to any large public sector initiative to reduce risk and cost while actually delivering what's needed.

You may have heard about the #NoEstimates movement, and even #NoProjects. Both of those concepts challenge the assumptions behind two key aspects of delivering software. But what about the process itself? Do we even need approaches like Scrum, Kanban or XP - let alone SAFe, LESS, NEXUS, DAD - in order to be successful? Is following a pre-defined process helpful at all? Is there a simpler way to be effective?

This session examines the two key principles common to all successful software delivery approaches and builds out based on the experience of the participants. Like #NoEstimates and #NoProjects, the name doesn’t really mean to eliminate process altogether, but rather to build a process that works for your team, in your business domain, with your technology stack.

Most of us have heard the mantra, "Slice your User Stories as thin as possible!" In my travels as a coach since the early 2000's, however, I've rarely seen stories that truly are thin. What are these rare creatures? Why don't I see more of them? Having good User Stories is crucial to the success of teams using them as the means for determining what needs to be built to fulfill a customer's need. Having thinly sliced stories is even more important!

This workshop provides a level set on what stories are and explores why slicing stories very thin is important, what benefits thin slicing provides, and how to do it. Through a combination of examples and practical application in the workshop, you'll leave with slicing techniques that you can apply at your next planning session.

In 2015, I became a Software Development Manager at You.i TV. In doing so I landed in the role that was quite often the target of the Agile coaching I had been doing for many years. It was time to eat my own dog food!

This talk reviews the ups and downs of the last year, with advice that I took, advice that I threw away, and advice that I modified.

You may have heard about the #NoEstimates movement, and even #NoProjects. Both of those are keen to examine the assumptions behind two key aspects of delivering software. But what about the process itself? Do we even need approaches like Scrum, Kanban, SAFe, or Extreme Programming? This session will start with two key principles common to all successful software delivery approaches, and build out from there based on the experience of the participants.

Like #NoEstimates and #NoProjects, the name doesn't really mean to eliminate process altogether, but rather to build a process that works for your team in your business domain with your technology stack.

In August 2015, I became a Software Development Manager at You.i TV. In doing so I landed in the role that was quite often the target of the Agile coaching I had been doing for many years. It was time to eat my own dog food!

This talk reviews the ups and downs of the last year, with advice that I took, advice that I threw away, and advice that I modified.

Most of us have heard the mantra, "Slice your User Stories as thin as possible!" In my travels as a coach since the early 2000's, however, I've rarely seen stories that truly are thin. What are these rare creatures? Why don't I see more of them? Having good User Stories is crucial to the success of teams using them as the means for determining what needs to be built to fulfill a customer's need. Having thinly sliced stories is even more important!

This workshop provides a level set on what stories are and explores why slicing stories very thin is important, what benefits thin slicing provides, and how to do it. Through a combination of examples and practical application in the workshop, you'll leave with slicing techniques that you can apply at your next planning session.

Whether it's a minor typo on a page, a major failure causing a severe outage of a system or anything in between, the software industry is fertile ground for examining problems and their causes. From the problems that plagued HealthCare.gov to defects that allowed some lucky people to purchase airline tickets for almost nothing from United airlines, we hear a constant stream of issues with software systems.

With our society becoming increasingly dependent on software, we need to "up our game" with respect to tracking down problems with they happen, ensuring that defects are caught before entering the wild, and are prevented from occurring in the first place.

Root Cause Analysis is a process that enables this form of continuous improvement and uses techniques borrowed from other engineering disciplines. The aviation industry, for example, constantly seeks to improve due to the dire consequences of any failures in that domain.

This interactive workshop will explain when and how to use Root Cause Analysis (RCA) to investigate problems and determine actions that will ensure that those problems can never happen again. Using real world examples the attendees will explore simple, lightweight RCA practices as well as a more involved example using fault tree analysis.

This workshop shows how Test-Driven Development (TDD) is used to enable emergent design. Using a simple but representative example in Java, the presenter will demonstrate how a low-level design naturally emerges when using the TDD cycle of test/code/refactor. The audience will be involved by suggesting the next steps and also by pairing with the presenter.

Note that the goal of the session isn't necessarily to have a complete working example at the end, but to illustrate the process of low-level design through TDD.

This workshop shows how Test-Driven Development (TDD) is used to enable emergent design. Using a simple but representative example in Java, the presenter will demonstrate how a low-level design naturally emerges when using the TDD cycle of test/code/refactor. The audience will be involved by suggesting the next steps and also by pairing with the presenter.

Note that the goal of the session isn't necessarily to have a complete working example at the end, but to illustrate the process of low-level design through TDD.

Whether it's a minor typo on a page, a major failure causing a severe outage of a system or anything in between, the software industry is fertile ground for examining problems and their causes. From the problems that plagued HealthCare.gov to defects that allowed some lucky people to purchase airline tickets for almost nothing from United airlines, we hear a constant stream of issues with software systems.

With our society becoming increasingly dependent on software, we need to "up our game" with respect to tracking down problems with they happen, ensuring that defects are caught before entering the wild, and are prevented from occurring in the first place.

Root Cause Analysis is a process that enables this form of continuous improvement and uses techniques borrowed from other engineering disciplines. The aviation industry, for example, constantly seeks to improve due to the dire consequences of any failures in that domain.

This interactive workshop will explain when and how to use Root Cause Analysis (RCA) to investigate problems and determine actions that will ensure that those problems can never happen again. Using real world examples the attendees will explore simple, lightweight RCA practices as well as a more involved example using fault tree analysis.

Whether it's a minor typo on a page, a major failure causing a severe outage of a system or anything in between, the software industry is fertile ground for examining problems and their causes. From the problems that plagued HealthCare.gov to defects that allowed some lucky people to purchase airline tickets for almost nothing from United airlines, we hear a constant stream of issues with software systems.

With our society becoming increasingly dependent on software, we need to "up our game" with respect to tracking down problems with they happen, ensuring that defects are caught before entering the wild, and are prevented from occurring in the first place.

Root Cause Analysis is a process that enables this form of continuous improvement and uses techniques borrowed from other engineering disciplines. The aviation industry, for example, constantly seeks to improve due to the dire consequences of any failures in that domain.

This interactive workshop will explain when and how to use Root Cause Analysis (RCA) to investigate problems and determine actions that will ensure that those problems can never happen again. Using real world examples the attendees will explore simple, lightweight RCA practices as well as a more involved example using fault tree analysis.

Whether it's a minor typo on a page, a major failure causing a severe outage of a system or anything in between, the software industry is fertile ground for examining problems and their causes. From the problems that plagued HealthCare.gov to defects that allowed some lucky people to purchase airline tickets for almost nothing from United airlines, we hear a constant stream of issues with software systems.

With our society becoming increasingly dependent on software, we need to "up our game" with respect to tracking down problems with they happen, ensuring that defects are caught before entering the wild, and are prevented from occurring in the first place.

Root Cause Analysis is a process that enables this form of continuous improvement and uses techniques borrowed from other engineering disciplines. The aviation industry, for example, constantly seeks to improve due to the dire consequences of any failures in that domain.

This interactive workshop will explain when and how to use Root Cause Analysis (RCA) to investigate problems and determine actions that will ensure that those problems can never happen again. Using real world examples the attendees will explore simple, lightweight RCA practices as well as a more involved example using fault tree analysis.

Automated business dashboards provide instant visibility into the performance of your business.  You can leverage your existing systems and tools as data sources, giving a real-time view of business health, performance against KPIs and opportunities for improvement.

The Dashing framework is a Ruby and CoffeeScript-based framework that is simple & lightweight with a minimal footprint, and can be easily deployed internally or to external cloud services such as Heroku.

This hands-on tutorial session explores the creation of a dashboard from zero to deployed in less than an hour!