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.

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.

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.

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.

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 works great when working with one team or maybe two but coordination becomes very challenging and complicated when trying to apply Scrum at scale. In this session, I’ll share a personal experience of applying Large Scale Scrum (LeSS) to scale Scrum from 2 teams up to 6 teams. I’ll give an overview of LeSS, share why we picked LeSS, how the teams were organized, successes and challenges we faced and tips on avoiding pitfalls.

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. 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 using an iterative and incremental appraoch. 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 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.

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.

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.

"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.

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.

Are you working in a distributed team and feel like your retrospectives are failing to deliver meaningful results? Are you spending less and less time on them? Are your retrospectives becoming boring dull and uninspiring? Retrospectives are a key mechanism for continuous improvement. This is especially true with non-collocated teams that deal with additional impediments and barriers due to communication difficulties. Come to this session to reverse this trend and learn new tools and techniques to conduct distributed team wide retrospectives that keep everyone engaged and result in effective discussion and follow-up action items and continuous improvement.

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.

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.