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.

Many team challenges can be tracked back to cognitive biases: our judgement gets anchored, we think we're better than we are, and we are our own favorite reference point. And even though we're encouraged to "think outside the box," there are conditions where we have a bias against creativity. If that's not a recipe for a tough team environment, I don't know what is.

Improve your game by learning about bias! You'll leave this session with strategies for identifying and mitigating bias on your team. 

Retrospectives are the core of agility. And yet they are the scrum ceremony that is most frequently skipped. Many teams like the idea of the retrospective but find them boring, or worse ineffective.

This talk aims to re-energize retrospective facilitators and participants. Starting with the basics: "what's a retrospective and how do you run one?", this talk reveals 7 secrets that lead to more engaging, more effective retrospectives.

You'll learn:

* The best way to ensure your retrospectives lead to real change

* The "pledge" everyone on your team should take before participating

* How to know who to include in each retrospective

* The single most important thing you can do to keep your team engaged during the retro

* And much, much more!

We think we understand that awkward teenager.

Many experienced testers will claim exploratory testing expertise, but too few have ever written an exploratory testing charter, and even fewer have applied a heuristic in that charter. We think we understand exploratory testing just as we think we understand teenagers, because “we have been there”. However the reality is that many of the words currently used in exploratory testing are foreign to us and we feel awkward about our lack of knowledge. The goal of this talk is to give people experience writing and executing exploratory testing charters, creating mind maps, and applying exploratory testing heuristics.

The talk is intended to introduce people to the exploratory testing techniques described by Elisabeth Hendrickson in her book Explore It! with some added material from the work of Cem Kaner and James Bach.

Do you want to write great User Stories that provide the vehicle for conversation and confirmation that we build the right thing? Do you struggle with splitting stories so that they still provide business value but can be accomplished within a fraction of your iteration and be potentially shippable to production? We will do a quick refresher on User Story formatting to include Acceptance Criteria. Then we will dive into learning techniques for splitting stories in this interactive workshop. 

So why does pair programming (or any form of pairing really) work? Well rather than tell you why, let's experience it! 

This is a simple 3 round exercise that you can do with your teams and managers to demonstrate the benefits of pairing. It will show the linkage between having a shared mental model through collaboration and ease of integrating the resulting work.

Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Outcomes are the big picture that acts as an anchor for whole efforts and which is continuously broken down into more and more detailed backlogs. The onion metaphor that is popularly used in agile planning (Cohn’s Planning Onion) can be used to describe the evolution of backlogs. Building an initial backlog is much like peeling through the layers of an onion to get to the core. There are many mechanisms for developing and maintaining the detailed backlogs, including asking, observing, showing and all sorts of hybrids. Using the onion metaphor, techniques for developing and splitting user stories are the second layer of the onion. However, before getting to the center of the backlog evolution onion, composed of features, epics, and user stories, we need to understand the big picture. 

 Presentation:

Provide an overview of storytelling in a business context and a lean change canvas framework.

Exercise

The room will be broken into teams (aisles will be used if auditorium seating).  Each team will be seeded with a common product change scenario. Based on the scenario the teams will be asked to tell the story of the change and capture the story on a small change canvas.  The exercise and session will culminate in by sharing ideas and lessons learned.

(Note the longer workshop would break the changing canvas into epics and stories)

Software development culture has been dominated by the hero. Rock stars, ninjas, and 10Xers have been the center of attention, giving the skewed perception that great software is the result of a single amazing developer. But this couldn't be further from the truth.

In this talk, Andrea Goulet, the CEO of Corgibytes, will share her experiences using vulnerability and empathy as drivers for Agile adoption and culture building. 

 Training is often the first step in implementing an Agile transformation within an organization.  Often an agile coach will corral resistant staff members in a room and sell the virtues of Agile with disappointing results.  But at the United States Citizenship and Immigration Services, students are clamoring to voluntarily attend full day sessions and recommending classes to their colleagues.  The organization has successfully grown the Agile Training Program to include 10 courses taken by 2200+ attendees from 25+ federal agencies.  The training is not required on anyone’s mandatory curriculum, but instead is taken because students feel it provides real value enhancing their ability to work well in the organization.  Effective training doesn’t just educate, but instead changes behavior.  

The masterminds behind the USCIS Agile Training Program will unpack the secrets to their success.  Mash Eslami, USCIS Section Chief of Agile Training, and Melinda Solomon, USCIS Agile Training Lead explore 10 factors that make students receptive to learn.  Part Experience Report, part Case-Study, this session will explore:

• How to choose your initial audience
• What to do with resistant students
• How to structure a course that changes behavior
• Ways to grow the program
• And much more…

Warning, road closed use alternate route.

Has your agile transformation stalled? Are you treading water? Does it feel like your standups are just going through the motion?  Sounds like you need a Transformation bypass.

Any agile transformation is a challenge and can stall if it doesn't get the right amount of attention. Maybe you had a consulting firm come in to lay out a roadmap. Only after they left the anti-bodies rushed back in. Or your tried to kick it off internally, to find yourself never getting off the ground despite executive support?

This session provides a playbook for re-engaging (or engaging from the get go) an enterprise agile transformation. A week by week, play by play guide for enabling the change engine to get enough momentum to keep going despite the resistance.

This playbook is based on what we are doing right now in the AOL Platform's division. From day one hitting the ground to when and how you roll out common training, to what you do next, and next and next.

Agile cost money just like waterfall does. Your software labor costs will be all internal (no vendors), all external (only vendors) or a mix. Paying for software labor by the billable hour means no connection to delivered business value and if vendors are using fixed pricing methods, hidden premiums may unnecessarily inflate your costs.

 This 45 minute interactive discussion includes how two organizations focus on quantitative sizing analytics and estimation best practices and how their Enterprise Managers today manage & reduce costs, improve predictable delivery and quantify business value. These Enterprises are investing tens of millions of dollars in Agile implementations at scale and need non-relative (normalized) data that is meaningful instead of relative aggregation of team level measures. Learn how they are adopting program and portfolio level measures and metrics to have real conversation about business value delivered.

This talk is inspired by the book ‘The Confidence Code’ by Katty Kay and Claire Shipman.

What is confidence and how do you know you have it?   While confidence is partly influenced by genetics, it is not a fixed psychological state.  However, you won’t discover it thinking positive thoughts or by simply squaring your shoulders and faking it.  It requires work and choices: less focus on people pleasing and perfectionism and more action, risk taking and fast failures.  This is why it can seem harder for women because these behaviors aren’t typically the ‘norm’ for women but generally come naturally for men.

In this talk we will explore the roots of confidence and the gender gap between men and women.  To ground the learnings, we will also hear interview summaries from four great and diverse women in agile: 

 Lyssa Adkins, Esther Derby, Ellen Grove, and Kat Conner

Often, we will use the phrase agile acquisition when we really mean acquisition for agile. Both agile acquisition and acquisition for agile are necessary to deliver efficiently across government organizations. The processes within the federal government for doing acquisition means that we may spend a year or more to award a contract for work to begin. This creates a significant delay is beginning projects or programs that impedes the speed of delivery. Instead, we need to move toward a true agile acquisition process where we change how we execute acquisition so that we can begin delivery in much faster fashion.

This workshop will examine how to change our acquisition processes to become more agile and able to support the delivery of IT services in a much faster manner. We will look at both successes and failures in acquisition and determine what changes need to be made in order to meet the quickly changing needs of government. Both contractor and employee viewpoints will be considered and discussed. We will look specifically at ways that government is trying to make these changes in the DHS Procurement Innovation Lab, the Office of Federal Procurement Agile training, as well as others and how those activities may play into your organization and procurement activities.

Max Weber and Michel Crozier both got it right when they described the ideal bureaucracy which is the number one impediment to Agile efficiency in the Federal government.   Perhaps a grand re-organization, accompanied by lots of "systems analysis," “customer participation," "cooperative federalism," and "interdepartmental coordination " might lead to something getting done.   Merely to state this prospect is to deny it.   There is not one bureaucracy problem, there are several and the solution to each is in some degree incompatible with the solution to every other.  There are inherent limits to what can be accomplished by large hierarchical organizations.  this though proving session faces the issue and suggests meaningful methods to approach bureaucracy as an impediment and address procedural stagnation, attitudinal fixtures, rule-bounded-ness with interventional strategies.   By understanding ecology of agile governance, strategies can be designed to evolve a system with procedural innovativeness, attitudinal mobility, rule flexibility and wider interest.   A very complicated subject, but one that shouldn't be ignored because it is hard to solve and can't be fully addressed in 45 minutes.

As timelines on application development and delivery continue to shorten, it’s no longer enough just to ask folks to work faster. Many managers are stuck between missing deadlines or burning out their people.

This was just one of the challenges for Promontory Interfinancial Network when it chose to implement Agile Portfolio Management over three years ago to speed the deployment of new financial technology software in an IT division of over 80 employees. Since its implementation, the number successful projects has more than doubled and late-stage overload has essentially been eliminated. Along with improving productivity, project visibility, resource allocation, and clarity of prioritization, the process has also been a highlight in audits and examinations as it demonstrates management oversight and risk mitigation.

In this session, Simon Storm, Senior Director of Enterprise Applications at Promontory, and the project lead in implementing Agile Portfolio Management, shares learnings from the implementation by the IT Management Team. He discusses how to get management buy-in, tips for customizing the Agile process for your institution, and his insights of how spearheading the Agile process can significantly advance your career by putting yourself in the driver’s seat of improving your organization’s productivity and collaboration.

The talk covers three start up players who scaled quickly within the Indian food tech industry in the year 2015. It draws out a common factor between the marketing strategies of the three enterprises. This common factor is then fine tuned into a KPI as it is used to analyze and measure the strategies based on data. The entire process draws it’s inspiration from Agile methodologies and the respective ceremonies held as part of Agile. These include ceremonies like retrospects and just in time reviews. The talk focuses on how a product owner/manager can contribute to the marketing/sales department of a huge enterprise/product.

One the most significant ceremony of any Agile Team is Daily Standup where the team members get together and plan for their day. But quite often the daily standup turns into a zombie status update meeting where team members come together to blurt out their updates and walk away to their desk without ever maximizing the benefit of that meet up.

In this session I will share a case study of how we created a simple experiment that turned into Standup Poker and revolutionized our Daily Standup. This technique helped us uncover true insights of teams progress and got the team talking about strategic planning and plan to remove any impediments as a "team" on daily basis to accomplish their sprint goal and commitments.

We learnt that when team members started using this technique, hidden impediments and dependencies started to emerge and team members organically started to re-plan and prioritize their work to accomplish the Sprint Goal. Product Owner also found great value in this technique as this helped them see the teams true progress and engage with the team to re-prioritize user stories and even take a story out of the sprint if required. Scrum Masters started to observe a trend in the confidence level over the span of the sprint and brought that information to Sprint Retrospective to discuss and brainstorm ways to improve and keep the confidence levels high throughout the sprint. The discussions and observations due to Standup poker resulted in teams committing better and more confidently during Sprint Planning and got into the rhythm of always accomplishing their sprint goal, but more importantly they started improving everyday and got into "continuous improvement" mode.

The content, exercise and message of this session highlight the agile principles of individuals and interactions over process and tools and fostering the mindset of continuous improvement.

In this session we will share examples, stories and experiences from trying the Standup Poker and how this simple technique converted a bunch of individuals into a TEAM !!!

We've all heard it; the only constant is change. When an organization begins a journey for Agile Transformation, the changes piles up... Unfortunately most change management approaches focus on creating a project-oriented plan for this. Other approaches like Lean Change are more emergent, but aren't specifically designed to help people to cope with change itself, only to help make the steps smaller. Let's explore some complementary people-centric approaches:

• Transition Management to help people make the journey through the wilderness
• Appreciative Inquiry to build on the current strengths, and
• The Power of Habit, to help people unlearn what is unwittingly holding them back

As we talk through each of these, we'll focus on the role of leadership and how these techniques can help people become willing, as opposed to being coerced, partners. We'll close with a brief discussion on how to engage people creatively with storytelling and such approaches as Open Space, World Café, and other workshops. In thinking on techniques that complement change management approaches, we can improve the effectiveness and willingness of the people in the organization to join in.

We firmly believe that automated testing puts the "A" in "Agile". Without an effective suite of automated tests your ability to be truly agile (that is embrace change) can only be based on the hope that your latest change doesn't have unintended consequences. Additionally, without automated tests, you are missing a vital component in getting feedback into the development team's hands. In our travels, we have encountered many organizations that are struggling with automated testing. These organizations are successfully adopting many Agile techniques but are failing when it comes to automated testing. We frequently hear "Automated testing just doesn't work for us" (eerily reminiscent of the days when we would hear, "Agile just doesn't work for us"). From our experience addressing their challenges, we have identified anti-patterns common across these organizations. These anti-patterns look like they should work, but are in fact doing more harm than good.

This talk is about those anti-patterns. We have given those anti-patterns a name and a face to help organizations understand why they are not getting the benefits from automated testing that others are. We describe several anti-patterns, such as the "Ice Cream Cone", the "Monolith", the "Sunk Cost". We explain why these anti-patterns appear to be good solutions, what makes them attractive, and why they do more harm than good. We talk about the right approach and draw on our experiences helping organizations adopt a robust automated testing strategy that instills confidence and provides fast feedback to the development team. We explain what benefits from automated testing the anti-pattern is preventing.