Trying to figure out Agile Release Planning?  We've done it and we've done it well.  Twelve teams - done! Twenty teams - done! Forty teams - done!  If your organiztion needs to tackle the enterprise release planning beast, you should attend this session.  Whether you are struggling with planning a large agile release planning event or simply trying to figure out how to improve your current agile release planning events, this session will provide nuggets of learning from planning teams with hundreds of people spread around the globe.  Many organizations have tried to conduct enterprise agile release planning and gave up because they could not overcome some of the basic obstacles like who to invite, where to hold the event, and how to keep everyone engaged.  

If you are trying to figure out how to coordinate two teams or dozens of teams, this session will provide insights into what works and what doesn't.  You will gain expereince by practicing actual agile release planning exercises to help you prepare for your orgainzations next agile RP event.  The learning expereince starts with a presentation on the key steps to consider as you launch a large agile program.

With TDD (Test Driven Development) a coder writes a small test, and then just enough code to make the test pass, cleaning up the code along the way.  Imagine applying the same concepts to the business case.  Now stop imagining and use HDD (Hypothesis Driven Development) to test your business case and refactor it for success.

Our hands on session will cover the basics of ATDD (Acceptance Test Driven Development) and BDD (Behavior Driven Development) to specify by example, so all stakeholders get on the same conceptual page, developers build what the business really wants, and testers can prove it. 

But building what we want it not enough, so we will go further and use HDD to validate, or invalidate, business outcomes, focusing us on value instead of on adherence to specification.

This is a hands on session, so come with pen, paper and a readiness to learn by doing!

1. Many federal government organizations have a requirement to perform independent verification and validation (IV&V) of software development projects for purposes of risk identification and compliance
2. As more federal agencies move towards agile, they will need to devise agile-appropriate methods for evaulating agile teams and contractors for process performance and project risk identification
3. Traditional approaches to IV&V are heavily biased towards waterfall, gate reviews, and traditional SDLC artifacts and hence, do not work well within an agile envrionment
4. Agile programs have their own process-specific risks and issues that need to be evaluated uniquely.  The document-centric approach that has traditionally been used is innapropriate and ineffective for agile teams as it does not find the right risks and does not find them early enough in the development process.
5. We at DHS/CIS have developed a unique, agile-appropriate IV&V model for a large agile transformation effort within DHS
6. The model is used to discover process risks, design risks, code risks, and testing risks in real-time for agile teams
7. The model serves as actionable and real-time feedback to teams, contractors, and federal managers that can be used for process improvement, vendor evaluation, and as a means to find and elevate delivery risks on agile projects
8. Positive results, challenges, and recommendations related to the development, roll-out, and execution of this agile-appropriate IV&V model will  be shared

There once was a myth that developers and testers should passively consume product backlog items created by the Product Owner. After all, the Product Owner is continually grooming the backlog.

Great product backlogs, just like great code-bases, and products, are created by the continual effort of many over a long period of time. In this session, we will look at real world strategies for working across role to look ahead and actively prepare our user stories for upcoming iterations.

We will review continual backlog refinement, based on various organizations situations, comparing large teams, small teams, simple domains, complex domains, etc. The session will start with a case study, move on to general knowledge sharing about readiness, and then we will have a hands-on workshop where you the attendees will present and discuss alternative to address different organizational issues (e.g. you will define what backlog refinement approach fits your situation).

In almost every project environment, misconceptions about the value and feasibility of usability testing oftentimes make it the first activity to get cut when deadlines loom.  In an Agile context, these misconceptions are heightened by the perceived pace and cadence of the project.  Design debt is not talked about along side technical debt, even though it can have the same volatile effect on a project.  In this talk, Dr. Jason Snook will talk about what usability testing is (and isn't) and provide practical recommendations that make these activities feasible without sacrificing the science the makes them so value to a project.