Project success =  f (listening, feedback, intentionality, practices) 

To make your agile practices and processes come to fruition, you need to cultivate an environment that promotes listening, learning, inquisitiveness, intentionality and top notch feedback that everyone is comfortable with. 

Agile projects succeed when there are frequent high-quality reinforcing feedback loops. I will share communication models based on Clean Language questions of David Grove and the Systemic Modelling techniques of Caitlin Walker that can greatly increase clarity, sense of purpose and listening skills within your team and collaborative endeavors.  These include: Clean Questions, Clean Feedback, and Clean Setup.

This is a hands-on, try it out, concrete practice session.

Great systems require active, capable Product Owners.  Functional innovation is not possible without their commitment and involvement in the project.  Too often in government contracting, the Product Owner is an Absentee Owner.  Agile Development teams often seek out tools and techniques to create great systems, however too frequently what is holding them back is the lack of an engaged Product Owner. Teams in this situation must face the elephant in the room if they desire to build a system that brings positive change in efficiency, productivity, quality, usefulness, and adoption.  This talk shares solutions I have used for challenges I see again and again on government contracts.

The talk begins with some introductory material on the problem, its causes, what I mean by functional innovation, and why this is required to build great systems.  I describe four challenges with Product Owner engagement that are not unique to government contracting, but that I see recurring on projects: committing staff, procurement practices, role ambiguity, and absentee ownership.

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.

So what does Collaboration really mean?  It's just ensuring people understand what each other is doing right?

The Power of 13 Collaboration Game illustrates what true collaboration means.  We'll do work by rolling dice over a 3 week Sprint. We'll then explore the results and start our next Sprint. In each Sprint, we're going to increase the participation across players and see what the effect is on productivity.  Prepare to be surprised!

Should there be enough time remaining in the hour; we'll then specifically apply true collaboration to better understand the effects of pair programming by playing Pair Poetry.  This simulates the power of pair programming and demonstrates why the one screen, one keyboard concept works.

From an agile implementation perspective, emphasizing the art of facilitation is an incredibly powerful tool for creating a culture of collaboration, and then leveraging that culture as a springboard to organizational transformation.  With strong facilitators at the gateway between business and IT, within IT delivery teams, and at key intersection points within an organization, the challenges to achieving organizational agility diminish. Strong facilitators bring forth the wisdom of teams and provide a container for self-organization. Facilitation is the cornerstone of servant leadership. 

We have heard a lot about no defects or zero defects, but is that reasonable or achievable in the government context?  How else can each sprint be deployable? Or how can you get to true flow with each story deployed to production?

 This session will explore how to get to a no defects posture across all of the tests required in a government setting. 

We will look at the various types of testing:

Unit, Functional, Integration, Security, 508, System, User Acceptance, etc 

We will look at what defects mean and how (or if) they should be tracked

We will look at what potential impediments from government organziations may exist in reaching a no defect state of software delivery

We will look at what tools and techniques can be used successfully in the government setting to address the impediments and achieve no defects in released software

Faster than a speeding bullet – less risky than a waterfall!

Government programs and agencies follow structured guidelines for just about everything. Guidelines reduce risk and control the value of products and services provided. It should come as no surprise that government organizations generally follow very structured processes for systems and software delivery too. However, the reality in today’s world is that change is inevitable and structured processes don’t harmonize well with change. Programs find themselves driven towards a more continuous engineering approach, where requirements evolve, stakeholders are engaged and an on-demand understanding of engineering artifacts optimizes decision making. These practices are key to Agile development which several government organizations have embraced in order to cope with rapid change and ever-rising citizen expectations.

In this talk we will present real government case studies of agile adoption for systems and software engineering. We will discuss the objectives, adoption, application and outcomes for each case study and then open the discussion for Q&A.

Join Scott as he discusses valuable lessons he has learned as an Agile Coach working with new agile teams on government projects. After several years on agile projects in the private sector the shift to agile in the public sector was quite a shock. Scott will discuss how the Japanese martial arts concept of ShuHaRi (roughly translated, it means first learn, next detach, then transcend) has helped him become a better coach when working on Agile transformations on government projects. Explore when the maxim “Let the team decide” is not appropriate and the technique of rationing tools and process to encourage engagement. Engage in thoughtful discussion about the stages of learning and come away with valuable guidance for managing the seeming paradox of self-organization and disciplined learning. This discussion provides a powerful message for agile coaches and scrum masters for teams just beginning an agile journey or just stuck in hybrid mode.

Many agile initiatives suffer from a feeble launch.  As Aristotle once stated “Well begun is half done”.  Performing the activities associated with developing a sound charter can help increase the likelihood of success for a team or organization .  

Beginning with the end in mind, we use retrospective techniques to develop consensus around objectives, vision, and mission.  In this workshop we introduce the components of a good charter and how those components help focus the teammates toward a common goal.  In addition, the development of the recommended charter components ensures that key questions are succinctly answered during the kickoff of a team.

Participants will learn the various types of charters and their recommended content.  During the workshop activity teams will develop a complete charter based  team of their choice or a provided case study.

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.

Creating an approach for change is difficult. There is a fine line between imposing an Agile adoption and creating a Transformation where people are collaboratively working together for the change. Based on my experience and in large US Federal Government organizations where imposed adoptions seem the norm, I’ve been working on combining many concepts into a transformation model that can work for large organizations that have ingrained cultures. This starts by helping the organization’s people take ownership and personalize what Agile means to them. Believe it or not, this can work.

Intended for senior executives and their immediate staff (and the coaches that help them), the Taking Flight approach presents the importance of culture and how creating an organizational aspiration will help guide people. For large organizations, culture has been built up over decades and changing this is of the utmost importance to have an Agile Adoption stick. There are 3 main points I’ll address:
- how to get people ‘onboard’ with a cohesive direction that they accept by collaboratively building their aspiration
- how to develop and select strategies for incremental improvement towards the aspiration
- how to realize changing from old routines into new ones aligned with the aspiration

To help establish cohesive direction, I use an Aspirational model (your Guiding Star) to help organizations develop the direction they want to go. I show how the differences between an Aspirational model and an End-State. I explain that aspirations are inspiring and allow for a mindset change by not expressing the final state in terms of structure our expected metrics. From there, I discuss different techniques for assessing the current state of the organization and its people and developing strategies and actions for the necessary change management to move towards the organizational Aspiration; this is where the concrete steps come into play. Throughout this portion, I have the group try out various techniques for building an aspirational model and how to build the backlog of work to undertake the transformation. I introduce the Power of Habit as a means to help the organization undergo the necessary behavior changes. I close with a discussion to help the audience think around limiting change-in-progress and how to grow capacity to become more responsive to change.

In this, you’ll get exposed to a few of many hands-on techniques that can be used to develop your Aspiration and execute on it. These are:

• KrisMap
• Business Model Canvas
• Habit Loops

Agile emphasizes self managing teams that regularly change how they work to improve productivity. Auditors and examiners want to ensure that management is actively providing oversight and that the team is following a consistent and repeatable development process. Continuous Delivery and Infrastructure as Code requires operations engineers to commit code into source code control systems and it encourages developers to have sufficient access to help troubleshoot production problems. Meanwhile, auditors and examiners are strong believers in separation of duties. These are just a few examples of how new development processes are creating serious challenges for audited and regulated companies. Given the conflicting priorities, how is a highly regulated or audited company supposed to implement either Agile or Continuous delivery without violating the core principles of these development approaches?

In this talk we will review 25 actionable items to help position Agile and Continuous Delivery so that your next audit is a success. Come with your own challenges as well as items that you are implementing so that the discussion period at the end of the presentation can include a meaningful session on additional tips and tricks you are employing or find solutions to your particular challenges.

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

In large Government and Commercial organizations with many interacting systems, architecture is necessary to collaborate effectively across disparate entities and systems. Traditional command and control approaches to architecture are often ineffective and cause great tension, especially when Agile efforts are part of the portfolio. We will discuss two principles, Vision and Partnering.  These principles provide insight and get results for both architects and Agilists; and present tools and approaches on how to effectively engage architects and architecture.

The White House recently created a new Government Digital Services group to deliver “customer-focused government through smarter IT.” As part of this announcement the Office of Management and Budget released the “Digital Services Playbook” and an accompanying “TechFAR Handbook for Procuring Digital Services Using Agile Processes” to make it easier for agencies to procure and implement agile.

In this session, we’ll review the TechFAR handbook objectives, key components and recommendations for getting agile adopted in your agency.

This session will be an interactive exploration of how delivery teams, product owners, and organizational stakeholders can get their "story cargo" moving without first having to tear down the mountain range or create a fission-powered maglev train to carry everything including an army of kitchen sinks.

Large organizations - especially Government ones, like to talk about change, but mostly they appear interested in changing everything but themselves.  Based on the concept of "The Little Engine That Could", this session is designed to help you examine ways to use Kanban and SAFe principles to get your release train accelerating even when you are being asked to haul MONSTER epic stories along the tracks that seem to be climbing up sheer cliffs of compliance regulations.  

Bring your favorite "Franken-story" examples and be prepared to have fun talking about ways of getting them over the mountain range.

A common misconception of Agile Scrum is that it can only be applied to software development projects.  This case study examines a DOD Modeling & Simulation project set in a Scrum environment and focuses on the roles, interactions and "rules of engagement" for all relevant stakeholders. Some of the key aspects that will be described are the critical importance of the team, customer involvement, frequent communication, and lessons learned. Executed properly, Scrum can transform the responsiveness, productivity, and quality of products and organizations. This work serves as proof that Agile can be successfully implemented in non-software development projects.

Sprint retrospecives are a key part of Agile, but are you getting enough out of your retrospectives? Are they taking too long?

In this session, you will learn how to

1. Gather input from "the quiet types" who may be hesitant to speak out in groups;
2. Separate the positive feedback from he negative feedback easily;
3. Quickly determine the level of support for each feedback item;
4. Increase the amount of team input as much as five-fold; and,
5. Synthesize and organize the input you receive so that you can act.

In doing so, you will increase team satisfaction with retrospectives and improve team productivity.

About the Speaker

Donald Patti is a Director of Applications for the AAMC, a non-profit organization that serves medical schools and students by providing services that enable members to improve the health of all. He also teaches courses in software development, web design, e-business and project management for the University of Phoenix. Prior speaking engagements have included presentations on risk management to PMI Washington DC, on Agile to PMI Washington DC, on release planning to Global Scrum Gathering and Agile 2014; and, on Lean Principles, Tools and Techniques to AAMC constituents.

United States Citizenship and Immigration Services (USCIS) decided to shift thier agencies current Transformation to include changing the entire development process all at one time. This included utilizing multiple contractors, shifting to a DEV/OPS structure, using a new cloud enviroment, transitioning from COTS to open source software all while introducing Agile concepts to the development team. This complete overhaul of "business as usual" was a complete culture shock to the enviroment and required close colloboration and consistent communication in order to create change and progress. As the Release Manager during this transition I will speak the lessons learned and how the team was able to progress after the introduction of so much change at one time, all while ensuring Government requirements were still met.