27 years ago I published “Why Functional Programming Matters”, a manifesto for FP–but the subject is much older than that! In this talk I’ll take a deep dive into its history, highlighting some of the classic papers of the subject, personal favourites, and some of my own work. At the end of the day, four themes emerge that characterize what I love about the subject.

CMMI and agile haven't shared many beers at the bar over the years. But there is no reason they shouldn’t be best of friends. They both long for continuous improvement, creating learning organizations that strive to reduce risk and increase quality. I believe that a major cause of dissonance is the lack of perceived value in the way the CMMI models have been applied and appraisals performed in the past.

So, what would it look like to implement CMMI and prepare for an appraisal focusing all of our effort into creating value and removing waste, instead of adding it? That was the question we tackled this past year and are seeing a completely different practice and outcome given our approach, including enthusiasm and appreciation from the project teams for this approach as opposed to the more typical dread.

Participants in this presentation will hear from both a CMMI Lead Appraiser and an agilest who lead this value-driven approach to CMMI. They will learn how agile mindset, practices, and tools can be used to apply the CMMI model to our delivery, with intentional focus on creating an ever-maturing practice that reduces risk and increases quality. Participants will also hear how agile was used in the appraisal preparation, enabling continuous improvement across the organization and even reducing the amount of time and effort needed for the SCAMPI A appraisal.

Changing the practices, behaviors, and beliefs of people and teams is hard; and organizations are many multiples harder. As agilest, we are educated to seek and deliver value. But that is one of the first big issues. What are the chances that we can know what is truly valuable for the people within the team or organization, both individually and collectively?

Another big issue is that most agilists are well-educated in frameworks, practices, and tools, but our training doesn’t generally prepare us for the other aspects imperative to implementing lasting agility and change. There is little focus in our standard training on the impact of systems and structures, and even less on internal aspects such as morals/ethics, ego, psychology, and culture.

I would like to present to you two models which opened my eyes over the past 6 years to a much larger awareness and understanding of how to approach agile transformation for impactful lasting change, and show you how to apply them to your work efforts. Seeing people, teams, and organizations through the lens of these models has greatly changed my understanding and approach and I believe has strongly benefited the outcomes of my efforts.

Spiral Dynamics Integral (SDi) is a bio-psycho-social developmental model showing itself through color bands representing levels of increasing inclusive evolution. AQAL – All Quadrants, All Levels [All Lines] – models a set of quadrants depicting our internal and external, individual and collective attributes and aspects. Woah! Don’t be thrown by that crazy-sounding stuff. Stick with me.

While those models might not sound very applicable to decreasing your cycle time to deliver your latest microservices through your fully-automated DevSecOps pipeline, without awareness of these models, you may never actually lead your team(s) to the point of decreasing cycle times, much less get your organization to the point of benefiting from DevSecOps practices.

Please join us for this session as we explore how these models allow us to be more successful in our work as Scrum Masters, Coaches, and/or Leaders. Benefit from learning new ways to see your system, avoiding and removing challenges and impediments you face in your sluggish, stuck, or failing agile journeys. Begin to see the world in a whole new way, not just at work, but in all aspects of life.

We all know the story of how the Agile ‘Software Development’ Manifesto emerged out of Snowbird in February of 2001. And we all know that Agile is still the current best practice for software development. What remains to be fully realized is that Agile has evolved to a best practice for business in general; a way of life for that matter.

I had the privilege of bringing Agile into business over the last couple years. In that time, I introduced my executive leadership team to Business Agility. After getting executive participation in the inaugural Business Agility conference in Feb 2017, we partnered together to seek the benefits of a comprehensive Business Agility adoption.

Using our corporation’s strategic planning and execution effort to exemplify, I will share with you how the Agile mindset and practices apply to business and drive the highest impact possible towards the most valuable goals and initiatives. Modern leadership and business practices such as those under the Business Agility umbrella bring a value-driven, data-driven, efficient focus on impactful delivery.

• Revenue and growth accelerate as we focus the company’s resources on delivering in the most valuable way
• Corporate processes lean out as we remove wasteful bottlenecks, saving money, time, and providing competitive advantage
• Employees are more capable as corporate practices are more meaningful and less taxing
• Back-office tools and data are integrated into a unified experience allowing real-time awareness and predictive analytics, increasing effective decision-making and enabling empowerment at lower levels
• Employees are happier. Customers are happier. The corporate bottom-line reflects this happiness.

I am enthusiastic about the spread of Agile beyond IT. And as such, I am excited to illustrate the brilliance of Business Agility to session participants, adding examples from my most recent corporate transformation effort to exemplify the mindset and practices presented. It is my interest that participants come away with an understanding of how Agile mindset and practices benefit the corporate back office as much as they do software delivery, and how their companies can begin to benefit too by applying what they learn from this presentation.

Why do we talk? How useful is it?
Let's work together in small teams to make products in complete silence, experiencing how talking both benefits and stifles collaboration.
What does collaboration really mean? How can this experience improve your collaboration?

In this experience, which is modeled after experiments run by Dr. Sallyann Freudenberg and Katherine Kirk, participants will experience a
* 90 minute period of complete silence while working together to build prosthetic hands for charity, noting down each time they have the urge to speak
* 45 minute review period where our facilitators will help us look at what we wanted to say and what happened instead, along with summarizing the outcomes we experienced through silent collaboration so that participants can take back with them these enlightenments.

We will pay particular attention to re-evaluating our model of collaboration and deep diving on the things people still felt like they wanted to say -- Did they really need to? What happened when they couldn't? How did that affect the outcome? We were moved by this experience when we participated in it at Agile2017, and are excited to provide the same experiential learning and awareness of silent collaboration to our community back in DC.

“Hey John, we don’t just want to help our customers be Agile, we want our firm to be Agile too.”

These words from our CEO kicked off our journey to transform Sevatec into an Agile company.  Business Agility is still a new idea for companies to embrace and as such, few companies have yet to align with the Agile principles, mindset, and practices.

Agile companies have happier employees, create greater value, make more immediate impact, operate efficiently, continuously improve, and provide a work environment that is motivating and allows employees to feel trusted, empowered, safe, and whole.

This session will include our experience with some of the practices we employed such as Impact mapping • work visualization • experiments • fast feedback loops • continuous improvement • cross-functionality • ChatOps • Communities of Practice • Lean Coffee • value-driven • data-driven • empowerment • and Organizational Change supported by Integral Theory/AQAL, Design Thinking, and Neuroleadership.

Through this session, you will understand what Business Agility is and learn approaches, practices, and tools that provide immediate benefit as well as cultivate the seeds for cultural change.  You will hear stories and see examples of our journey to Business Agility delivered firsthand by members of our business teams such as HR, Finance, Contracts, etc.

Our roadmaps and backlogs are usually littered with pet projects, squeaky wheels, and recent ad hoc items that gain priority simply because they are the latest shot across our bow. Impact mapping is a powerful practice that helps us identify and align our work to the most valuable business goals and mission objectives and avoid many of the common challenges that arise from an unfocused set of work priorities.

Impact maps help us visualize quantifiable benefits that deliverables should produce towards our business objectives. They allow us to focus our work on those deliverables that move the needle the most, not just deliver features. The practice is a great way to communicate assumptions, create plans, and align stakeholders as well as aid in strategic planning, roadmap management, and defining measures of success and quality.

This workshop will provide an appreciation for the power of impact mapping by walking you through building your own impact maps and the facilitation process for doing so in your own organization. You will leave the workshop having participated in a tangible example of the technique, and having gained an understanding of best-practices for facilitation with a focus on an impact map’s outputs and how they lead into the creation of actionable user stories when completed. Hands-on collaboration with your fellow attendees will help encourage your own application of this technique in your real world road-mapping and backlog refinement activities.

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.

Impact mapping is a powerful practice that ensures we are delivering work that directly impacts our business goals and mission objectives.  Our roadmaps and backlogs are usually littered with pet projects, squeaky wheels, and recent ad hoc items that gain priority just because they are the latest shot across our bow.  With a tool such as impact mapping, we can stand firm knowing our real priorities, and fend off these common challengers.

Impact maps visualize quantifiable benefit that deliverables should produce towards our business objectives.  They allow us to focus our work on those deliverables that move the needle the most, not just deliver features.  The practice is a great way to communicate assumptions, create plans, and align stakeholders as well as aid in strategic planning, roadmap management, and defining quality.  Happily, it is also significantly less bureaucratic and much easier to apply than many alternatives.

This workshop will provide an appreciation for the power of Impact Mapping and walk you through building your own Impact Maps.  You will learn techniques for creating Impact Maps as well as facilitating an Impact Mapping session.  You will leave the workshop with a usable Impact Map of your current project, or other of your liking, that can bring immediate value to your road-mapping, backlog grooming, and software delivery.

What do the commercial world and Federal government share in common? Agile success! Yes, it is true that agile grew from the commercial world and has been a shining story of success there, but the Federal government has been adopting agile’s brilliant ways more recently and has success stories of its own to share.

In getting to the point of successful agile delivery, especially at the organizational level, the Federal government has had to clear many hurdles and transform the way it works. This hasn’t been an easy task and is still in its infancy. The commercial world has cleared its share as well and has many war stories along with their success stories.

This session will be delivered as a moderated panel discussion. Two panelists from progressive Federal programs join two shining examples of agility from the commercial space – and entertaining fellows to boot.  Panelists will discuss topics that provide insight into their organizations and the work they did to implement agile successfully on their teams, across their programs, and throughout their organizations.

• Alastair Thomson is the Chief Information Officer for NIH’s National Heart, Lung, and Blood Institute
• Joshua Seckel is the Applied Technology Division Chief at the USCIS Office of Information Technology
• Nate McMahon is a Vice President of People and Technology at The Motley Fool
• Bob Payne is the Vice President of Enterprise Agile Consulting at LitheSpeed

Ever wonder if a major Federal program has been able to achieve Continuous Delivery or implement a Zero Defects strategy? How have the commercial companies been able to increase their output so well while decreasing risk at the same time? What can Federal organizations learn from the commercial world about agile contracting and procurements? How did commercial companies have to change to enable self-forming teams and could our Federal government, with its myriad contractors and its layers of separation, benefit from the same? What can the commercial world learn from Federal agile success? Do successful agile approaches differ between products and services? What do the Feds see as their next agile conquest on the horizon? What is hot for commercial companies to tackle now?

You will leave this session understanding some of what the commercial world has done to achieve great success with agile. You will also hear about agile success in the Federal government, bureaucracy busting moves, and what the government had to do in order to achieve those feats. Both sides will share their stories, describing the impediments they faced, the benefits they have seen, and even the areas they have not been able to conquer just yet, attempting to drive agile throughout their organizations and into every aspect of their delivery. Panelists will also discuss topics and answer questions the session participants have for them to ensure everyone has an opportunity to take back valuable and pertinent knowledge afforded by these experienced agilists.

Your effective agile program can go downhill fast even in the most progressive Federal organization if executive leadership begins to think that the answers they used to get in the "Waterfall world" are no longer available to them in an agile world. Federal Executives have elevated reporting responsibilities and need to answer to the public, sometimes even to Congress itself, therefore pressures are high for proper communication flow. Don’t let your program get to the point where “agile just doesn’t work for us.”

Requirements such as the OMB Exhibit 300 which updates the Federal IT Dashboard and Earned Value Management which is required for larger IT efforts put pressure on Federal executives. They understood how to request the information they needed before going agile, and their teams knew how to get it to them. Agile teams typically no longer create fully resourced project schedules, Gantt charts, and comprehensive requirements documents. Leadership gets frustrated when they can’t get a “straight answer” to questions they are used to having answered such as “what is the project schedule’s critical path showing,” or “are we staffed properly to complete all the remaining requirements by the end of the contract.”

The answers are still there and the information is still available but the tools and methods by which we produce this information are now different. We need to be able to translate the questions being asked and help Federal executives understand how to better ask the questions to get what they are really looking for. Learn how to extract the necessary information from our agile toolset (Roadmaps, Story Maps, Backlogs, Velocity/Cycle Time, Burn charts, Journey Lines, User Stories, etc.) to give our Federal executives what they need to be successful meeting the myriad requirements applied to Federal IT programs.

The goal for this session is to provide you the tools you need to continue giving your Federal executives what they need to manage and report on their programs effectively. You will gain insight into what is required of Federal IT programs and therefore what is really being asked, and to help your leadership better ask the questions “in an agile way” so that you may deliver impactful answers derived from our agile tools. You will understand how our agile tools are used and combined to provide the same answers the "Waterfall tools" used to provide Federal organizations. You will return, able to save your agile project from potential doom in the hands of executives under pressure to report against practices they no longer understand.

Ever solve a jigsaw puzzle?  Do you typically design and document all your pieces before assembling the puzzle or know anything about the kind of picture formed by the puzzle?  Hardly.  Usually, the specifics of the puzzle, as they emerge through the process of solving that puzzle, affect our tactics for solving it.  

This analogy is at the heart of Exploratory Testing (ET) - a fun, focused and powerful approach to testing that has been gaining in popularity in recent years.  While not a new idea, it is often misconstrued as being a random, flailing at the keyboard approach to uncovering problems.  Not quite.  ET is a disciplined practice that involves simultaneously learning about the software under test while designing and executing tests, using feedback from the last test to design the next.  It leverages traditional test design analysis techniques and heuristics, but design and execution become a single inseparable activity.  Within the agile context, there is a need for agile teams to augment their scripted automated tests with a manual testing practice that is adaptable, and ET provides the right fit.

In this session oriented towards beginning explorers, we will gain a deeper understanding of what ET is, what it isn't, and discuss the essential elements of the practice with practical tips and techniques for: learning the system under test and capturing our understanding to design tests; designing tests on the fly using heuristics; executing tests and observing results; and finally, integrating ET into the cadence of an agile process.

Testing sprints? Hardening sprints? Why do so many of us have these and other ways to get around completing all our required testing inside our defined timeboxes? Isn’t our goal to produce deployable features at the end of every Sprint?

During our session, we will examine why it’s so hard to accomplish all necessary testing inside the iteration and show how to complete these tests within your timebox. Through interactive discussion and real world examples, we will provide insights on foreseeing, overcoming, and avoiding your hurdles and send you home with both long term methods and short term actions that will yield tangible results in achieving your goal.

Our session will:
• Illustrate the value of completing all of your testing inside your timebox
• Identify the challenges in completing all these tests in such as seemingly short period of time
• Discuss ideas and options to successfully overcome these challenges
• Explore how to enable your organization and environment for efficient, rapid testing
• Discuss real world examples of enablement and how we navigated the pain points of enabling testing processes that allow complete testing within an iteration
• Explore DevOpsSec and how achieving testing within your timebox is a precursor to DevOpsSec
• Provide short term tactics and actions to immediately improve your ability to complete your testing
• Allow you to voice your concerns and challenges and discuss potential solutions to these impediments

Most of us implement agile to reduce the time to deliver valuable working software and to increase the frequency of delivery with high quality through increased and earlier collaboration, shorter feedback loops, and reduced risk. While you can show improvement over Waterfall by performing typical agile methods, you cannot really live the dream without optimizing your agile execution.

You will leave this session armed with the right knowledge to improve delivery on your current project or start your new projects properly so that you or your clients can reap the benefits of efficient process and high-quality software capable of achieving continuous deployment of fully-tested code at the end of each iteration.

Your progressive and efficient agile program can go downhill fast, and agile can get a bad rap, if upper management begins to think that the answers they used to get in the "Waterfall world" are no longer available to them in an agile world. Executives assume the team is managed poorly if they can’t produce artifacts they are used to seeing like fully resourced project schedules. They get frustrated when they can’t get a “straight answer” to questions they are used to having answered like “what is the project schedule’s critical path showing,” or “are we staffed properly to complete all the remaining requirements by the end of the contract.” They become unhappy with the team and possibly even start to see that “agile doesn’t work for our program” if they are told that they can’t get that information anymore in agile, or it isn’t clearly explained to them how to ask for the information they are really trying to understand.

The answers are still there though the tools and methods are likely different. We need to be able to translate the questions being asked and help upper management understand how to better ask the questions to get what they are really looking for. Executives are responsible for ensuring the health of the program, that sufficient progress is being made, the program is within budget, the contractual requirements are being met, etc. Agile methods can leave executives uneasy because answers to questions regarding these can be “squishy” since user stories can be added and removed, they can use relative sizing techniques for estimation instead of specific hours, priorities can shift, and the customer’s needs drive much of the process decisions. By understanding what upper management really needs in order to be successful themselves, and how to extract that information using our agile toolset, we will be able to give them the data they need to continue managing the program and communicating its health to their leadership and customer counterparts. The goal for this session is to provide you insight into what is really being asked, to help your leadership better ask the questions “in an agile way,” and to deliver impactful answers derived from our agile toolset that allows for strong communication of the health of your program.

“Being agile” is a mindset change.  You can’t “be agile” just by following agile processes.  Agile practices have intended benefit which you likely will not achieve if you just “do agile.”  Assessing the processes and practices to understand why they have been put in place, and what they are trying to achieve, will help you start to see how you can produce the intended value agile is meant to bring.  When you and your team can see the intended value of the practices then you can perform better as a team, deliver more accurately and more frequently, and please your customer and users much more consistently.

We will explore agile practices such as the Scrum ceremonies, WIP limits, specific information radiators, etc. to assess what they are really trying to achieve.  Agile processes derive in part from psychological attributes and needs.  Humans execute agile delivery and to come together better as a team, keep our customers and upper management comfortably informed, produce what our customers and users really want, and consistently deliver high quality software, we need to fulfill our psychological needs and address our human factors.  This session will help you to understand what the intended goals are in these practices, what mindset changes may be necessary, and how you can ensure that your team achieves the value.  If your team is just “doing agile” then your project will likely wind up as another one that “was not well-suited for agile” in the eyes of your team, upper management or customer.  If your team can ”be agile,” then upper management will celebrate your success and your customers will applaud the efficiency by which your happy team routinely delivers the precise features they are looking for.