There is growing interest in learning more about Agile HR and its impact on individuals, teams and organizations.

It is important to separate fact from fiction: What are the real threats and opportunities of bringing Lean | Agile values, principles, and practices to HR? What can we expect in the future? Through anecdotal evidence and case studies, the session will explore the potential of Agile HR as well as provide guidance on how to approach the transformation.

 Issues covered in the presentation include: information on how to embrace the new talent contract, create inspiring, engaging, and fun places of work, shift to an iterative performance flow, take the issue of money off the table, support growth within an Agile enterprise.

Having a clear purpose in both life and work is essential to happiness. And, science and business support this view. Companies with a clear purpose perform better than companies without. Purpose is increasingly seen as the key to navigate the volatile and complex world we live in. And, people with a purpose in their live longer and are healthier. However, finding your purpose, your personal and companies purpose, is not an easy task. In this workshop we discuss what purpose means and key elements of a sustainable and meaningful purpose. We elaborate the four steps to identify the company purpose and how to build your business around it.

Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders. This is an evolutionary step beyond pair programming and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.

Mob Programming can be a highly effective approach to software development. There are numerous teams doing Mob Programming all over the world, including distributed teams, and there has been a great deal of positive reports of success. Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we've faced.

[Update based on the panel review]

Inspired by Martin Fowler's introduction to micro services (https://www.youtube.com/watch?v=wgdBVIX9ifA);

The demo will introduce the "ABC"s of the transition to micro services. We will refer to the Hadoop Distributed File System open source and demonstrate to (re)design the NameNode module as a micro service. This will introduce the three primary challenges and their possible solutions as in;

1. Componentize using Services instead of the conventional componentization using the design

2. Data segregation using an event driven framework to separate the centralized data across services

3. Accessing a micro service as a web service instead of an orchestrated access; the delegate & facade patterns will be demoed to loosely couple the interfaces

The demo will conclude with a listing of the next steps in transition, which need to be considered after the primary challenges are addressed.

"The higher you go in an organization, the more your suggestions become interpreted as orders." - Marshall Goldsmith

An Architect garners a high level of authority by being an expert. People will follow their lead. But what if the Architect is wrong? They will follow right off a cliff.

How do we get people to think like the Architect? Use the principles of Intent-Based Leadership to decouple the success of your project from the personality of the architect. By creating clarity around architectural goals and by engaging people in problem solving rather than defining rules and standards we can divest control and create an organization of leaders.

In his book “Understanding the Four Rules of Simple Design”, Corey Haines lays out the basics for getting people together for a day and practice coding better. Unhappily, many of us have to deal with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. J. B. Rainsberger has started a variation on on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to extend that pattern and have retreat for those of us who work legacy code in Java often.

We will learn and practice the classic Michael Feathers dance of

1. Identify change points
2. Find an inflection point
3. Cover the inflection point (break external dependencies, break internal dependencies, write tests)
4. Make changes
5. Refactor the covered code.

By the end of the day, in addition to being tired and completely ready to put away our laptops forever, we will have gained valuable insights and practical experience with a topic no one likes to talk about - getting better working with legacy code!

People in organizations that are learning Kanban quickly understand the relationship of WIP, Cycle Time and Throughput. However, when teams start doing things like Pair Programming, they tend to hold fast to the idea that “you’d get more done if you worked separately!”

High performing software teams use a variety of modern technical practices including Test Driven Development, Pair/Mob Programming, Refactoring, Evolutionary Design, and Continuous Integration & Delivery.

How do these practices fit into the Kanban context? Whether through improving collaboratively, evolving experimentally, or implementing feedback loops, learn how these technical practices are supported by Kanban's four Foundational Principles and six Core Practices, which in turn make Kanban more powerful.