It can be difficult for developers to find the motivation to write automated unit tests.  This workshop introduces a simulation that can demonstrate the value of automated unit tests to identify and localize defects.  In the simulation, participants will play the roles of programs and tests.  We will discuss barriers to creating and maintaining unit tests, and how this simulation addresses those barriers.

Theme: Games for Learning, Code and Test

  (We have not published slides for this workshop.  "Slides" link below is to representative slides from other presentations.)

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.

A few years ago everyone wanted to know how to convince their executives to go agile. Today's executives are asking their teams how they'll get them there. While we have made significant progress changing the hearts and minds of senior leadership, executives have a fiduciary responsibility to the performance of their organizations. They demand a greater level of assurance that what you plan to do is actually going to work. Executives are sick and tired of being told to trust the team and that everything will be okay. Better than anyone, executives see the dysfunction in their organizations. They want line of sight to how agile is going to help them make things better. 

This talk is going to explore a safe, pragmatic, and repeatable formula for leading change in large organizations. The Holy Grail for an executive is to tie dollars spent and activities performed, to internal improvement metrics and ultimately improved business performance.

In the simplest of terms, software development decisions for commercial organizations can be reduced to a calculation of whether the cost of developing the software will be outweighed by the estimated revenue generated or costs saved by the software.  However, as Mark Schwartz points out in his book, “The Art of Business Value Paperback” this simple explanation is insufficient for commercial organizations, and not applicable for government and other non-commercial organizations for whom the impact of software isn’t primarily measured in terms of revenue.  

In this session participants will experience a simulation that has been created to explore these question of how to make decisions about investments to deliver mission and business value by examining the impact of these decisions on the performance of organizations in changing environments.

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.

How do you create excited, engaged, happy, and effective teams? Start them off right by letting your engineers choose their own teams and projects! Through a proven technique called self-selection, Opower was able to turn a tribe of 40 engineers, many of whom were unexcited about continuing to work on the same old products, into six high-performing teams with engineers who were excited to embark on a new adventure, acquire new skills, and ship awesome code.

In this session we will cover the self-selection process: what it is, generating buy-in & excitement, preparing your teams, running a self-selection event, dealing with concerns throughout the process, and measuring the success of your process. This talk is for anyone who wants to create better teams including Agile Coaches, Release Train Engineers, Program Managers, individual contributors, and other organizational change leaders.

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. 

A team can’t “become agile” in a vacuum. The “contract” that management and the surrounding organization makes with the team needs to become agile as well in order for the team to be effective. There are 10 commitments that a team's management/stakeholders frequently fail to support fully , even now that agile approaches have arguably become predominant in software development. This presentation enumerates those 10 commitments, and contrasts them with the cheats that organizations typically try to substitute in place of true commitment.

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.

The Agile Manifesto says, "Individuals and Interactions over Processes and Tools," but what I increasingly see in practice is "Tools are the Process, mediating all Interactions between Individuals."  Two years ago, I pointed out the dangers of letting planning tools take over your planning meetings.  I didn't realize that they could take over standups and even intra-team communication as well!

This talk will show how to get out of the Wholly Tool-Focused trap by (1) clarifying the questions your team should be asking about your process and tools and (2) presenting alternative physical tools with a proven track record.

Something amazing is happening right now.  All around the world, a new culture is beginning to emerge.  People who are bringing more beauty into the world, more love to our human family, and more wholeness to lives. It's a culture of people who are creating an entirely new vision of who we are and where we are going.  The Integral movement is ground zero for this emerging culture.  Integral Agile is the application of this amazing emergence scoped to our Agile delivery in the business and IT world.

This session will provide an overview of why Integral Agile is so important to embrace if we are to truly be successful in our endeavors and deliver effectively.  It will share an understanding of what Integral Agile is, with a focus on its core components of Integral Theory and Spiral Dynamics.  You will also learn how to apply the All Quadrants All Levels (AQAL) “lens” to “see” your customer or organization where they “are at” so that you can choose tools, delivery practices, and communication means that resonate and align with them.

While Integral is an all-encompassing movement that would be too expansive for an Agile conference and rather hard to squeeze into a 45-minute session, a focused brief on Integral Agile fits very well.  No matter if you are a delivery coach, project manager, development team member, or engineer, you can deliver more effectively through using the lens provided by Integral Agile.  This talk will describe how to apply Agile tools, practices, and process based on this awareness of “where they are” so that you will be more effective in reaching “them,” and no longer need to wonder why your best laid plans are falling short of success.

This presentation is about leadership agility, and how that translates to effective leadership. What is leadership agility? Where am I on the leadership development continuum? How do I improve my leadership agility? When do I know I am an effective leader?

This talk includes an abbreviated leadership styles improvisation!

Servant Leadership; Lessons Learned from the Military

Abstract:

More companies are adopting the Scrum methodology of Agile software development. They jump in and start learning about the three roles – Product Owner, self-directed development team and Scrum Master. They may even bring an Agile Coach in to help them learn Scrum. The roles and responsibilities of Product Owner seem straight forward and understandable. The roles and responsibilities of the development team are known and understood. Although there are some questions around the “self-directed” part. And then there is the Scrum Master. Issues arise about the nature of the role. Is the Scrum Master really just another name for project manager? And issues arise over who should fill the role of Scrum Master. Is it really a full-time job? Should the Product Owner and Scrum Master be the same person?

Key expectations of the Scrum Master include, in no particular order:

The Scrum Master is a facilitator

The Scrum Master is a coach

The Scrum Master is custodian of the framework

The Scrum Master foresees, heads-off or removes impediments from the team

The Scrum Master uses a Servant Leadership style.

That last bullet, Servant Leadership is a concerning one. Some managers think Servant Leadership is too lose. The supposition is no one is really in charge. Again – who is the project manager? Who is developing the development team into a self-directed team? To counter concerns, ten lessons learned from the military‘s experience with “Servant Leadership” will be shared.

There has not been a lot of discussion of “Servant Leadership” in the military until just recently. And there has never been only one style of “military” leadership. However “Principled Leadership” as taught at the United States Military Academy at West Point has a long, successful history in the military.  

To use the military experiences we will first discuss and compare Servant Leadership and Principled Leadership to establish a parallel between the two.

We will define and discuss Servant Leadership by going back to, what is widely acknowledged as, the modern genesis of Servant Leadership – Robert Greenleaf’s 1970 seminal essay, “The Servant as Leader”.

Then we will define and discuss Principled Leadership as taught at West Point and detailed in Larry Donnithorne’s book, “The West Point Way of Leadership”.

Having established the similarity between Servant Leadership and Principled Leadership, we will look at Lessons Learned from the military.

While there are many examples of Agile  methodologies being used in government, the number of agencies realizing success from it is much lower. A recent survey of Federal CIOs shows that while over 90 percent of respondents reported some form of Agile adoption, 50 percent believe they are ineffective at implementing Agile.

So why the gap? If agencies can stand it up, why are they stumbling to realize the promises of Agile?

Understanding this gap and the reasons causing agencies to stumble will help you to recognize similar issues impeding Agile adoption, understand ways to address those challenges, and reflect on your own journey transitioning to Agile. 

This presentation will address these questions by telling the story of ongoing Agile adoption within the IRS around a large-scale IT modernization project. It will describe the organizational characteristics that challenged Agile adoption and integration, and share lessons learned through our Agile journey to date.

Let us admit it. Agile team often lives under a fast pace to deliver working software in a very short cycle. Some team members could not adopt agility and finally burst out that they started to dislike Agile. As a leader or an Agile coach, the major factor to success is to help teams keep a balance for maximum grow so team can engage in delivering software as expected.

The basic idea to maximize growth is to keep balanced amount of challenge and support as appropriate for your team. Just like when you are a little child, your parent give you challenge (”Here, kid, lace ‘em up!”) or support (”let me tie them for you…”). The imbalance could impact your team’s performance.  Too much support, your team will never really learn what they need to grow and develop, on the other hand, too much challenge, and the team will become frustrated and possibly quit trying. It is important for leaders and coaches to understand that team will accept challenge when they are ready. For example, introducing pair programming to your team when they are not ready to adopt the technique, the action would become a burden or an artificial for your team. They may just fake it out.

How does all of this relate to the Agile practices? The Agile experience is one of the greatest experiments of growth in testing team’s collaboration. For that growth to occur, each team member needs to be challenged (and supported) appropriately through a variety of experiences, both inside and out of the team environment. Some of these experiences may be unpleasant, like fixing your own defects. Challenge and support does not imply that the team member will never experience failure or negative consequences, but what it does imply is that when those consequences take place, there will be individuals and processes in place to support the team member as they learn from the Agile experience. Support comes from a lot of places, including management, organization, Agile coach, CEO, or colleagues. However, a major component of that support comes from the encouragement we all give to the team to keep trying and to ask for help with each other.

There's a lot of hype around failure in the business world, "Fail fast, fail often". It's true that most significant accomplishments come after hundreds of mistakes and failures. As a competitive rock climber and coach, I have integrated extreme failure safely into my process for progression in the sport. How can a software development organization embrace failure in an intelligent way? This presentation will illustrate Lean, Agile, and Extreme Leadership concepts related to failure, rapid proto-typing, and feedback loops through the metaphor of professional rock climbing and with real-life case studies from IT projects.

"You can't do agile until you have the technical practices down"

"Just start with Scrum, everything else will follow"

"We have to change the mindset here first!"

Do any of these sound familiar? Where does an agile transformation need to begin? In this workshop, participants will play "Wheel of Agile Transformation" where they will spin a wheel and develop their own story on how an agile transformation within their organization is rooted in focusing on either technical practices, process, culture, or other areas! 

Have you ever imagined how our ancestors built Stonehenge, the Great Wall of China and the Pyramids without the tools and technology that are available to us today? Now imagine today’s world without the internet, smart phones and technology. What do you see? I see that there have been generations before us and there will be generations after us which will develop ways to survive, excel, and perish. One thing that is constant is change. Most of the organizations today acknowledge that change is good and have discussed it in great detail; however, but fall short in realizing the change.

Change is an absolute truth. No one can agree with this more than organizations in today’s cut-throat competition, where constant change is the norm for their survival. Organizations which are slow to respond to change or resist change are on the verge of being obsolete. They need to change for various reasons such as external competition, market pressure, performance issues, changing workplace demographics, globalization etc. Organizations which invest in proactively responding to change are more likely to not only survive or but also emerge as leaders, creating new markets which never existed before. When organizations are successful, they become complacent and continue to do what worked, but in doing so you keep getting what you were getting; where is the growth in that? The main reason for organizations to resist change is in their mindset; change is perceived as negative or with skepticism. How many times have we heard the phrase “if it ain't broke, don't fix it.” Many organizations have fallen victim to this mindset and have become extinct.