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.

Are you frustrated by the many trivial examples that show up when you google "refactor legacy code"? How do you translate these examples to your real-world code base? Sometimes it's just easier to give up on the refactoring and increased test coverage, reserving these techniques for the ever elusive greenfield project. To help you with this dilemma, Nayan will walk through a real legacy Java code base, and perform some safe refactorings required to bring the code under test. All of this will be done under the guidance of the Four Rules of Simple Design (Pass the tests, DRY, Reveal intent, Minimize moving parts).

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

Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.

Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.

But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?

I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that's the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can't logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.

This session will speak to the specifics of the whats and whys.

Organizations are embracing Continuous Delivery (CD) for many reasons nowadays, including:

• better throughput and stability of systems built and managed
• better effectiveness of the organization, resulting in better financial outcomes for the organization
• better job satisfaction for members of the organization
• a desire to play with shiny new things and engage in resume driven development

When we take a deeper look at what the goals are, and talk about how we accomplish those goals, many times the discussion starts to devolve into a discussion of tools and tool capability. And many times, the deciding factors of one tool versus another tool speak to the capabilities of the tools to work in the existing organizational structure.

But this approach is flawed. If we view CD as an organization change to achieve the goals stated before, then we should expect that the organizational structure, as well as the organization’s guiding principles will have to change as well.

This talk will center around the premise that the changes that are needed to accomplish CD, and subsequently achieve the benefits associated with that involve the use of new tools (potentially bright and shiny, as well as resume enhancing). But the tools are merely necessary but not sufficient in attaining the organizational’s CD goals. True teamwork both from both a technical team perspective as well as inter-team collaboration as required to truly get to full positive outcomes for DevOps based CD. We’ll speak to some tools, but mostly talk about good teams and the top quality software that they need to produce, and how they need to go about that.