Presentation Topics

Below are sample presentation topics to choose from:

General

A behind the scenes look at what happened at Snowbird back in 2001 during the writing of the Agile Manifesto. In addition to the skiing, hot tubs and beers, there were some passionate discussions on various light weight methods, approaches and techniques. Find out how the event came about, who initiated it and why, what were the objectives and agenda coming into the event, what were some of the heated discussions that occurred, and how the values and the principles came about, what was included and what was left out. Finally, looking back in retrospect, what would the authors want to change or add today?

Are you struggling with your Agile adoption? Have you been doing Scrum for a while but aren’t really seeing any of the benefits? Are you going through the Scrum motions, using new “cool” lingo with new roles and titles yet the overall work approach and results are still the same? Then the latest updates to the Scrum Guide might be just what you need!

Many of the updates in the Scrum Guide are due to common misconceptions and misunderstandings we have about Scrum. In fact, many teams and organizations are unknowingly and unintentionally taking certain actions that are Scrum smells or anti-patterns. These smells and anti-patterns maintain the status quo and impede their Agile transition and transformation. In this talk, I explain the updates and highlight the anti-patterns or smells that they are trying to address. I then show how the new language clarifies any misconceptions and puts us back on the right track.

Come to this talk for an overview of the most important updates to the Scrum Guide, and more importantly, a discussion on why they were made, the smells and anti-patterns that you might be unknowingly applying, and suggestions on how to overcome them.

Scrum is easy to understand but hard to implement. Many team members think of Scrum as a framework with roles, meetings and artifacts. They take a training class and come back to work and take on new roles, setup Sprint planning, standups, reviews, and retrospectives. They start working in Sprints using product backlogs, user stories, task boards, and burn down charts. Things start out well, however, soon difficulties arise and anti-patterns and smells emerge as teams start moving from Scrum to ScrumBut. You’ll often hear “We do Scrum but we don’t have an engaged Product Owner” or “We do Scrum but we don’t test within the Sprint”. In this interactive session we will tie elements of the Scrum Framework to the values and principles of the Agile manifesto to better understand the purpose behind the framework and it’s roles, meetings and artifacts. Come to this session to understand the reasons things are setup in a certain way so that you can assess the implications, risks and impacts of deviating from the basic framework.

Bizarro Scrum is like Bizarro world where everything appears to be the opposite of what it should be. It is about common day to day situations that a lot of Scrum teams experience when they transition to Scrum. In this talk, I’ll highlight statements that team members make via fun and amusing comic strips depicting team members at the task board, the water cooler, the cafeteria, the cubical or the conference room. Now, these statements are well-intentioned, and on the surface appear normal and innocent. However, when we dig deeper, we will uncover that these organizations and teams are unknowingly and unintentionally taking certain actions that are Scrum anti-patterns. These smells and anti-patterns maintain the status quo and impede their Agile transition and transformation. I’ll explain the anti-patterns or smells, implications, and how to overcome them.

Some examples include: “I’m taking a bio break. I’ll mark that down as 1 point!” or “I don’t have much to do. I’m still waiting on the BAs to finish writing the user stories.”

These teams are typically going through the Scrum motions, using new “cool” lingo with new roles and titles yet the overall work approach and results are still the same. These organizations and teams are doing Scrum but are not realizing the benefits of Scrum like faster ROI, reduced risk, increased visibility and improved adaptability. They are unable to continuously deliver valuable, high quality products and features that dazzle their customers. The reasons for this are myriad and include a misunderstanding of Scrum fundamentals, a failure to live by the Agile values and principles, and a lack of expertise in Agile Engineering practices.

Join this session as we walk through a series of comic strips and learn how to identify these Scrum anti-patterns or smells, understand their impact and know what corrective action to take.

More and more organizations and teams are adopting Agile, however most stay focused on just the development part. They maintain a Big Upfront Requirements/Design (BRUF) phase and still have a long test and deployment phase. This approach results in more of a mini-waterfall approach rather than an Agile approach where we actually place valuable products in our customers’ hands. The old risks and pain points are still there: are we building the right thing? Is it valuable and usable? Does it work? So the true benefits of an Agile approach in terms of quality valuable products and higher ROI is never achieved due to our long cycles and slow feedback loops. Come to this session to see how Lean Discovery and Agile Delivery combined with a DevOps mindset, can make actual delivery of customer value sustainable. We will look at how Lean Discovery replaces BRUF and ensures the team is constantly building the right thing. We will also see how applying Agile Engineering practices ensure that the team is building the thing right and how a DevOps mindset ensures that the product the team builds actually gets delivered to the customer early and often.

There are more to Agile metrics than velocity and sprint burn-down charts. However, most Agile teams just focus on velocity and target story points which leads to executives misusing the metric and teams gaming the system. Velocity should stay within the team and there are other metrics that can be shared with executives and others that are outside the team. These metrics provide a more holistic view of the project’s overall health. The Agile Dashboard collects such metrics and acts as an information radiator giving us real time project updates on value, performance, schedule, scope, cost, quality, and team spirit. Come learn what to measure and for how long. Learn how to read warning signs and what corrective actions to take. Learn to setup your own Agile dashboard to arm yourself with the right information and make careful and constant adjustments to ensure forward and safe progress towards your final deliverable.

A lot of organizations today are going through an agile transformation. They’ve sent everyone to training. They’ve introduced product owners and scrum masters. They’ve created product backlogs and are working in iterations. The teams have planning meetings, standups, reviews and retros. The result? Teams are just going through the motions and organizations have yet to see the benefits. Sounds familiar? Why is that? What role does leadership have to play? How about the team? You? Come to this session to uncover some of the most common impediments that derail an agile transformation. Learn a five step approach to overcome these obstacles at both the team level as well as the leadership level. Leave with a new tool for your toolbox that you can use with your organization to get them moving faster towards greater agility and better business outcomes.

“Customer collaboration over contract negotiation” is one of the 4 values of the Agile manifesto. However, this remains a challenging value to adopt in practice especially when dealing with a client/vendor relationship. Many organizations and contracting officers still rely on traditional contracting arrangements that directly conflict with the 4th value of “responding to change over following a plan”. Others adopt more creative Agile contracts that have their own pitfalls that may result in counterproductive behavior that negatively impacts collaboration. In this session we will look at such contracts. We will compare and contrast different types of contracts and learn how some lead to enhanced customer collaboration while others might destroy the client/vendor relationship. We will go over some examples of specific contract clauses and discuss the intent behind the clauses and compare expected team behavior vs. observed team behavior. Come to this session to learn about Agile contracts. Learn how to identify contract clauses that will result in anti-Agile and non-collaborative behavior. Learn what aspects encourage collaboration and how to structure contracts that results in a win-win for both client and vendor.

Can a federal agency’s PMO support Lean teams that are focused on delivering working software frequently? What about all the needed documentation, reviews, and sign-offs from a myriad of groups including systems engineering, privacy, PRA and cyber security? In this session we’ll look at a federal agency’s PMO processes and the concept of minimum viable bureaucracy. We’ll explore the roles and relationship between the PMO, PM,  and team. We’ll see how projects get initiated and the decision criteria needed to start or defer a project. We’ll walk through a lightweight gate review process and the activities and deliverables of each phase. We’ll also see how gate reviews can co-exists with a continuous delivery pipeline. We’ll share lessons learned and take a look at the challenges ahead. Come to this session to see how a lean PMO is operating in a Federal Agency.

Agilists employ user stories as a way to capture user requirements and drive the planning process for iterative and incremental delivery of software. Many with experience in “big requirements up front” often struggle with the brevity of user stories and how to best communicate requirements. In this presentation, Fadi explains the benefits of using user stories to represent customer requirements. After explaining the basic concepts, he quickly progresses to discuss attributes of a good user story along with the top 13 patterns for splitting user stories to keep them right sized and manageable. Come learn how to split and manage user stories and discover different boundaries to consider when refining stories. Learn how to decompose a story until it is ready for development. Leave with new insights on how to write effective user stories.

Simulations

In this session we will go through a complete Scrum simulation from concept to delivery by developing a project using Lego bricks.

The interactive Hard Choices game is a simulation of the software development cycle meant to communicate the concepts of uncertainty, risk, options, and technical debt.

In the quest to become market leader, players race to release a quality product to the marketplace. By the end of the game, everyone experiences the implications of investing effort to gain an advantage or of paying a price to take shortcuts, as you employ design strategies in the face of uncertainty.

Mars 2050 is a game illustrating the planning process in Agile software development. The games exposes participants to iteration planning, product backlogs, user stories, and estimation. Participants must regularly assess their progress, risks, bugs, technical debt and adjust their plans accordingly. In order to be successful, participants must meet critical deadlines, minimize defects, monitor their velocity and re-plan as they gain further insight into the evolving project.

Join us for a fun way to learn all about Agile release planning and product backlog prioritization!

Facilitation and Coaching

One of the 12 principles of the Agile manifesto states that “The best architecture, requirements, and designs emerge from self-organizing teams.” Why is that? and what exactly are self-organizing teams? How does a team become self-organizing? Teams that have always been used to command and control cannot suddenly become self-organizing overnight. Come to this session to learn what self-organizing really means. Understand the attributes of a self-organizing team and some of the challenges you face in getting your team there. Understand how to find the right balance between team learning and team empowerment vs. control? Leave with techniques to help you build and foster high performing self-organizing teams.

Retrospectives are a key mechanism for continuous improvement. However, retrospectives can quickly become routine and dull. In this workshop we will try different creative techniques to keep retrospectives interesting, effective engaging and fun.

Product Backlog

Are your Sprint planning meetings taking longer and longer each Sprint. Do you find yourself discussing new stories that the team is seeing for the very first time? Are some of the stories vague, complex, or very large? Is the priority unclear? These are all symptoms of ineffective Product Backlog Refinement which results in painful Sprint planning meetings. Team Product Backlog Refinement is an important activity that is frequently overlooked. The team is usually focused on delivering features for the current Sprint and devotes little time to work with the Product owner to prepare for the upcoming Sprints. Come to this session to understand the importance of Product Backlog Refinement, the different types of activities that are needed, when to perform each type, who should attend and how to make the most of everyone’s time. Understand the importance of having a Definition of Ready, learn how to do progressive elaboration on user stories and how to expand on your acceptance criteria. Leave with tips and technique for conducting effective Product Backlog Refinement before your very next Sprint planning meeting.

Agilists employ user stories as a way to capture user requirements and drive the planning process for iterative and incremental delivery of software. Traditionalists with experience in “big requirements up front” often struggle with the brevity of user stories and how to best communicate requirements. In this presentation, Fadi explains the benefits of using user stories to represent customer requirements. After explaining the basic concepts, he quickly progresses to discuss attributes of a good user story along with different techniques for user role modeling. Fadi shows you how to manage risk and dependencies by properly sizing user stories. Learn what size is the right size and how to deal with constraints, assumptions, and non-functional requirements. Understand the different criteria used to decide when to split or merge stories. Discover different boundaries for prioritizing stories. Leave with new insights on how to write effective user stories.

Agilists employ user stories as a way to capture user requirements and drive the planning process for iterative and incremental delivery of software. Traditionalists with experience in “big requirements up front” often struggle with the brevity of user stories and how to best communicate requirements. In this presentation, we will look at common anti-patterns and mistakes that teams unknowingly employ when writing user stories. Come learn how to identify and avoid these mistakes. Understand what size is the right size for a user story and how to properly split a user story. Discover different boundaries for prioritizing stories. Learn how to decompose a story until it is ready for development. Leave with new insights on how to write effective user stories.

Agilists employ user stories as a way to capture user requirements and drive the planning process for iterative and incremental delivery of software. Many with experience in “big requirements up front” often struggle with the brevity of user stories and how to best communicate requirements. In this presentation, Fadi explains the benefits of using user stories to represent customer requirements. After explaining the basic concepts, he quickly progresses to discuss attributes of a good user story along with the top 13 patterns for splitting user stories to keep them right sized and manageable. Come learn how to split and manage user stories and discover different boundaries to consider when refining stories. Learn how to decompose a story until it is ready for development. Leave with new insights on how to write effective user stories.

Agile Engineering

Some Agile teams fail to figure out or implement technical practices that are necessary for long term success. Practices like automated builds, automated tests, automated deployments, continuous integration, and continuous delivery are now considered essential for the success of any software development project. Join us for a tour of software engineering best practices. We’ll discuss what these practices are and their impact on scope, schedule, cost, resources and quality. We’ll also share some ideas on how to start adopting these practices and how to incrementally introduce them and gradually improve your team’s software development process.

“Continuous attention to technical excellence and good design enhances agility” is one of the twelve principles behind the Agile manifesto.

Are your teams practicing Test Driven Development, Automated Testing, Continuous Integration and Delivery? How about pairing, mobbing, and collective code ownership?

Agile Engineering Practices are key to succeeding with Scrum and realizing its many benefits like faster ROI, reduced risks, increased visibility, high quality, and improved adaptability. Yet many teams struggle with adopting these practices and end up just going through the motions of Planning meetings, Daily Scrums, Reviews, Retros and so forth. They use cool new lingo and tools; they have new roles and titles, yet the overall approach, technical practices, and results are still the same. Sprints usually end up being just for coding and finish with no shippable Product Increment. Teams go through several Sprints without delivering anything. Testing cycles and release cycles are still long, and the delivery of customer value is delayed. The final deliverable suffers from poor quality and does not meet the customer’s needs.

Come to this session to learn how to introduce essential Agile Engineering Practices to your team. We’ll discuss typical transitions teams go through in their Agile adoption along with the challenges, roadblocks and push back to these technical practices. Leave equipped with a continuous improvement action plan to overcome these challenges, make new behaviors stick, and get your teams on their way to technical excellence.

Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.

Many teams struggle with fitting in testing activities inside of a Sprint. They end up doing primarily development activities in a Sprint and push testing activities to run in dedicated testing Sprints following the coding Sprints or have a coding and testing Sprint running in parallel. However, in Scrum, the output of every Sprint is a potentially shippable product increment. This means the product increment should be well tested within the Sprint and ready to be delivered. Come to this presentation to learn how to tackle testing on an Agile team, what kind of tests to execute, what to automate and what not to automate, the different testing responsibilities, and when to run which tests. Leave with a testing strategy that you can start applying the next day to gradually get a team to start testing from day 1 of the Sprint and deliver a true product increment at the end of each Sprint.

A lot of Agile teams have now figured out how to build an application iteratively and incrementally. However, this is limited to the development process. Overall architecture design is still tackled using a big upfront design approach which leads to brittle systems and makes architecture changes over time extremely difficult. In this talk we’ll learn how to move away from static architectures and move toward evolutionary architectures and emergent design. We’ll take a tour of various architecture styles and analyze various characteristics to determine the architecture’s fit for agility and evolvability. We’ll also look at essentials for success and consider different approaches to getting started based on the current state of your architecture. Come to this talk to learn how to get started with building architectures that can support constant change.

Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development?

You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc… However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will look at the benefits of TDD, discuss the resistance to TDD and uncover some common difficulties along with misconceptions. We will then address these misunderstandings and explore different approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD and apply it with ease.

Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development?

You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc… However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will address the resistance to TDD as we uncover 10 myths and misconceptions about TDD. We will then explain these misunderstandings and explore better approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD.

A behind the scenes look at what happened at Snowbird back in 2001 during the writing of the Agile Manifesto. In addition to the skiing, hot tubs and beers, there were some passionate discussions on various light weight methods, approaches and techniques. Find out how the event came about, who initiated it and why, what were the objectives and agenda coming into the event, what were some of the heated discussions that occurred, and how the values and the principles came about, what was included and what was left out. Finally, looking back in retrospect, what would the authors want to change or add today?

Are you struggling with your Agile adoption? Have you been doing Scrum for a while but aren’t really seeing any of the benefits? Are you going through the Scrum motions, using new “cool” lingo with new roles and titles yet the overall work approach and results are still the same? Then the latest updates to the Scrum Guide might be just what you need!

Many of the updates in the Scrum Guide are due to common misconceptions and misunderstandings we have about Scrum. In fact, many teams and organizations are unknowingly and unintentionally taking certain actions that are Scrum smells or anti-patterns. These smells and anti-patterns maintain the status quo and impede their Agile transition and transformation. In this talk, I explain the updates and highlight the anti-patterns or smells that they are trying to address. I then show how the new language clarifies any misconceptions and puts us back on the right track.

Come to this talk for an overview of the most important updates to the Scrum Guide, and more importantly, a discussion on why they were made, the smells and anti-patterns that you might be unknowingly applying, and suggestions on how to overcome them.

Scrum is easy to understand but difficult to master. Many team members think of Scrum as a framework with roles, meetings and artifacts. They take a training class and come back to work and take on new roles. They setup Sprint planning, daily scrums, reviews, retrospectives, and grooming meetings. They create product backlogs and user stories, task boards, and burn down charts. They work in Sprints while building a product iteratively and incrementally. This starts out well but soon difficulties arise and anti-patterns and smells emerge as teams start moving from Scrum to ScrumBut. You’ll often hear “We do Scrum but we don’t have a Product Owner” or “We do Scrum but we don’t test within the Sprint”. In this interactive session we will tie elements of the Scrum Framework back to the values and principles of the Agile manifesto to better understand the purpose behind the framework and it’s roles, meetings and Artifacts. Come to this session to understand the reasons things are setup in a certain way so that you can assess the risks and impact of a deviation from the basic framework.

Scrum is easy to understand but hard to implement. Many team members think of Scrum as a framework with roles, meetings and artifacts. They take a training class and come back to work and take on new roles, setup Sprint planning, standups, reviews, and retrospectives. They start working in Sprints using product backlogs, user stories, task boards, and burn down charts. Things start out well, however, soon difficulties arise and anti-patterns and smells emerge as teams start moving from Scrum to ScrumBut. You’ll often hear “We do Scrum but we don’t have an engaged Product Owner” or “We do Scrum but we don’t test within the Sprint”. In this interactive session we will tie elements of the Scrum Framework to the values and principles of the Agile manifesto to better understand the purpose behind the framework and it’s roles, meetings and artifacts. Come to this session to understand the reasons things are setup in a certain way so that you can assess the implications, risks and impacts of deviating from the basic framework.

Bizarro Scrum is like Bizarro world where everything appears to be the opposite of what it should be. It is about common day to day situations that a lot of Scrum teams experience when they transition to Scrum. In this talk, I’ll highlight statements that team members make via fun and amusing comic strips depicting team members at the task board, the water cooler, the cafeteria, the cubical or the conference room. Now, these statements are well-intentioned, and on the surface appear normal and innocent. However, when we dig deeper, we will uncover that these organizations and teams are unknowingly and unintentionally taking certain actions that are Scrum anti-patterns. These smells and anti-patterns maintain the status quo and impede their Agile transition and transformation. I’ll explain the anti-patterns or smells, implications, and how to overcome them.

Some examples include: “I’m taking a bio break. I’ll mark that down as 1 point!” or “I don’t have much to do. I’m still waiting on the BAs to finish writing the user stories.”

These teams are typically going through the Scrum motions, using new “cool” lingo with new roles and titles yet the overall work approach and results are still the same. These organizations and teams are doing Scrum but are not realizing the benefits of Scrum like faster ROI, reduced risk, increased visibility and improved adaptability. They are unable to continuously deliver valuable, high quality products and features that dazzle their customers. The reasons for this are myriad and include a misunderstanding of Scrum fundamentals, a failure to live by the Agile values and principles, and a lack of expertise in Agile Engineering practices.

Join this session as we walk through a series of comic strips and learn how to identify these Scrum anti-patterns or smells, understand their impact and know what corrective action to take.

A lot of organizations today are going through an agile transformation. They’ve sent everyone to training. They’ve introduced product owners and scrum masters. They’ve created product backlogs and are working in iterations. The teams have planning meetings, standups, reviews and retros. The result? Teams are just going through the motions and organizations have yet to see the benefits. Sounds familiar? Why is that? What role does leadership have to play? How about the team? You? Come to this session to uncover some of the most common impediments that derail an agile transformation. Learn a five step approach to overcome these obstacles at both the team level as well as the leadership level. Leave with a new tool for your toolbox that you can use with your organization to get them moving faster towards greater agility and better business outcomes.

One of the 12 principles of the Agile manifesto states that “The best architecture, requirements, and designs emerge from self-organizing teams.” Why is that? and what exactly are self-organizing teams? How does a team become self-organizing? Teams that have always been used to command and control cannot suddenly become self-organizing overnight. Come to this session to learn what self-organizing really means. Understand the attributes of a self-organizing team and some of the challenges you face in getting your team there. Understand how to find the right balance between team learning and team empowerment vs. control? Leave with techniques to help you build and foster high performing self-organizing teams.

Some Agile teams fail to figure out or implement technical practices that are necessary for long term success. Practices like automated builds, automated tests, automated deployments, continuous integration, and continuous delivery are now considered essential for the success of any software development project. Join us for a tour of software engineering best practices. We’ll discuss what these practices are and their impact on scope, schedule, cost, resources and quality. We’ll also share some ideas on how to start adopting these practices and how to incrementally introduce them and gradually improve your team’s software development process.

More and more organizations and teams are adopting Agile, however most stay focused on just the development part. They maintain a Big Upfront Requirements/Design (BRUF) phase and still have a long test and deployment phase. This approach results in more of a mini-waterfall approach rather than an Agile approach where we actually place valuable products in our customers’ hands. The old risks and pain points are still there: are we building the right thing? Is it valuable and usable? Does it work? So the true benefits of an Agile approach in terms of quality valuable products and higher ROI is never achieved due to our long cycles and slow feedback loops. Come to this session to see how Lean Discovery and Agile Delivery combined with a DevOps mindset, can make actual delivery of customer value sustainable. We will look at how Lean Discovery replaces BRUF and ensures the team is constantly building the right thing. We will also see how applying Agile Engineering practices ensure that the team is building the thing right and how a DevOps mindset ensures that the product the team builds actually gets delivered to the customer early and often.

“Continuous attention to technical excellence and good design enhances agility” is one of the twelve principles behind the Agile manifesto.

Are your teams practicing Test Driven Development, Automated Testing, Continuous Integration and Delivery? How about pairing, mobbing, and collective code ownership?

Agile Engineering Practices are key to succeeding with Scrum and realizing its many benefits like faster ROI, reduced risks, increased visibility, high quality, and improved adaptability. Yet many teams struggle with adopting these practices and end up just going through the motions of Planning meetings, Daily Scrums, Reviews, Retros and so forth. They use cool new lingo and tools; they have new roles and titles, yet the overall approach, technical practices, and results are still the same. Sprints usually end up being just for coding and finish with no shippable Product Increment. Teams go through several Sprints without delivering anything. Testing cycles and release cycles are still long, and the delivery of customer value is delayed. The final deliverable suffers from poor quality and does not meet the customer’s needs.

Come to this session to learn how to introduce essential Agile Engineering Practices to your team. We’ll discuss typical transitions teams go through in their Agile adoption along with the challenges, roadblocks and push back to these technical practices. Leave equipped with a continuous improvement action plan to overcome these challenges, make new behaviors stick, and get your teams on their way to technical excellence.

Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.

Many teams struggle with fitting in testing activities inside of a Sprint. They end up doing primarily development activities in a Sprint and push testing activities to run in dedicated testing Sprints following the coding Sprints or have a coding and testing Sprint running in parallel. However, in Scrum, the output of every Sprint is a potentially shippable product increment. This means the product increment should be well tested within the Sprint and ready to be delivered. Come to this presentation to learn how to tackle testing on an Agile team, what kind of tests to execute, what to automate and what not to automate, the different testing responsibilities, and when to run which tests. Leave with a testing strategy that you can start applying the next day to gradually get a team to start testing from day 1 of the Sprint and deliver a true product increment at the end of each Sprint.

A lot of Agile teams have now figured out how to build an application iteratively and incrementally. However, this is limited to the development process. Overall architecture design is still tackled using a big upfront design approach which leads to brittle systems and makes architecture changes over time extremely difficult. In this talk we’ll learn how to move away from static architectures and move toward evolutionary architectures and emergent design. We’ll take a tour of various architecture styles and analyze various characteristics to determine the architecture’s fit for agility and evolvability. We’ll also look at essentials for success and consider different approaches to getting started based on the current state of your architecture. Come to this talk to learn how to get started with building architectures that can support constant change.

Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development?

You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc… However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will look at the benefits of TDD, discuss the resistance to TDD and uncover some common difficulties along with misconceptions. We will then address these misunderstandings and explore different approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD and apply it with ease.

Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development?

You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc… However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will address the resistance to TDD as we uncover 10 myths and misconceptions about TDD. We will then explain these misunderstandings and explore better approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD.

Many UX designers struggle to work within a Scrum environment and see Scrum as a framework mainly for developers. Working in time-boxed Sprints and delivering small pieces iteratively and incrementally might force designers to focus on a single story at a time. This in turn can lead to tunnel vision, losing focus of the big picture and resulting in a fragmented user experience. Come to this presentation to learn where design fits in Scrum and how to apply design principles in Agile environments and work effectively with Scrum teams to produce a great user experience.

“Customer collaboration over contract negotiation” is one of the 4 values of the Agile manifesto. However, this remains a challenging value to adopt in practice especially when dealing with a client/vendor relationship. Many organizations and contracting officers still rely on traditional contracting arrangements that directly conflict with the 4th value of “responding to change over following a plan”. Others adopt more creative Agile contracts that have their own pitfalls that may result in counterproductive behavior that negatively impacts collaboration. In this session we will look at such contracts. We will compare and contrast different types of contracts and learn how some lead to enhanced customer collaboration while others might destroy the client/vendor relationship. We will go over some examples of specific contract clauses and discuss the intent behind the clauses and compare expected team behavior vs. observed team behavior. Come to this session to learn about Agile contracts. Learn how to identify contract clauses that will result in anti-Agile and non-collaborative behavior. Learn what aspects encourage collaboration and how to structure contracts that results in a win-win for both client and vendor.

Can a federal agency’s PMO support Lean teams that are focused on delivering working software frequently? What about all the needed documentation, reviews, and sign-offs from a myriad of groups including systems engineering, privacy, PRA and cyber security? In this session we’ll look at a federal agency’s PMO processes and the concept of minimum viable bureaucracy. We’ll explore the roles and relationship between the PMO, PM,  and team. We’ll see how projects get initiated and the decision criteria needed to start or defer a project. We’ll walk through a lightweight gate review process and the activities and deliverables of each phase. We’ll also see how gate reviews can co-exists with a continuous delivery pipeline. We’ll share lessons learned and take a look at the challenges ahead. Come to this session to see how a lean PMO is operating in a Federal Agency.

There are more to Agile metrics than velocity and sprint burn-down charts. However, most Agile teams just focus on velocity and target story points which leads to executives misusing the metric and teams gaming the system. Velocity should stay within the team and there are other metrics that can be shared with executives and others that are outside the team. These metrics provide a more holistic view of the project’s overall health. The Agile Dashboard collects such metrics and acts as an information radiator giving us real time project updates on value, performance, schedule, scope, cost, quality, and team spirit. Come learn what to measure and for how long. Learn how to read warning signs and what corrective actions to take. Learn to setup your own Agile dashboard to arm yourself with the right information and make careful and constant adjustments to ensure forward and safe progress towards your final deliverable.

Are your Sprint planning meetings taking longer and longer each Sprint. Do you find yourself discussing new stories that the team is seeing for the very first time? Are some of the stories vague, complex, or very large? Is the priority unclear? These are all symptoms of ineffective Product Backlog Refinement which results in painful Sprint planning meetings. Team Product Backlog Refinement is an important activity that is frequently overlooked. The team is usually focused on delivering features for the current Sprint and devotes little time to work with the Product owner to prepare for the upcoming Sprints. Come to this session to understand the importance of Product Backlog Refinement, the different types of activities that are needed, when to perform each type, who should attend and how to make the most of everyone’s time. Understand the importance of having a Definition of Ready, learn how to do progressive elaboration on user stories and how to expand on your acceptance criteria. Leave with tips and technique for conducting effective Product Backlog Refinement before your very next Sprint planning meeting.

Agilists employ user stories as a way to capture user requirements and drive the planning process for iterative and incremental delivery of software. Traditionalists with experience in “big requirements up front” often struggle with the brevity of user stories and how to best communicate requirements. In this presentation, we will look at common anti-patterns and mistakes that teams unknowingly employ when writing user stories. Come learn how to identify and avoid these mistakes. Understand what size is the right size for a user story and how to properly split a user story. Discover different boundaries for prioritizing stories. Learn how to decompose a story until it is ready for development. Leave with new insights on how to write effective user stories.

Agilists employ user stories as a way to capture user requirements and drive the planning process for iterative and incremental delivery of software. Traditionalists with experience in “big requirements up front” often struggle with the brevity of user stories and how to best communicate requirements. In this presentation, Fadi explains the benefits of using user stories to represent customer requirements. After explaining the basic concepts, he quickly progresses to discuss attributes of a good user story along with different techniques for user role modeling. Fadi shows you how to manage risk and dependencies by properly sizing user stories. Learn what size is the right size and how to deal with constraints, assumptions, and non-functional requirements. Understand the different criteria used to decide when to split or merge stories. Discover different boundaries for prioritizing stories. Leave with new insights on how to write effective user stories.

Retrospectives are a key mechanism for continuous improvement. However, retrospectives can quickly become routine and dull. In this workshop we will try different creative techniques to keep retrospectives interesting, effective engaging and fun.

In this session we will go through a complete Scrum simulation from concept to delivery by developing a project using Lego bricks.