We often talk about what the Product Owner Must "Do" - they must own the Product Backlog, they must manage the product backlog and the priorities, they must refine the backlog, they must answer the team's questions.

We very rarely talk about what the Product Owner must "Be".

During this session I will highlight what I have learned from my experience as a Product Owner and a Product Owner coach, what I believe are the main Must "Be's" for a Product Owner.

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.

Delivery teams know from experience the importance of maintenance such as applying patches, upgrading, and conforming to the latest security and accessibility regulations. Product Owners, other value team members, and system stakeholders are focused on functionality and end user satisfaction. Maintenance isn’t sexy and can sink in priority until it fails to be included in releases.

The Security community has been using Dark/Abuser/Evil Stories using the persona of a Black Hat Hacker to uncover vulnerabilities. In this workshop participants will assume the role of Delivery Team members and use the power of personas to write “Dark Stories” that bring to life the full impact of failing to perform necessary maintenance.  The intent is to give Product Owners a complete understanding of the importance of maintenance so they can appropriately prioritize maintenance and keep their systems strong.

"Language does not just describe reality. Language creates the reality it describes." - Desmond Tutu

The agile community has evolved into a group of highly enthusiastic proponents who bring a high level of excitement to everything they say and do. Agilists speak a strange sort of insider jargon in which plain English words have very unusual, and often counterintuitive meanings.

They may describe your multi-billion-dollar enterprise as "dysfunctional" and on the verge of "failure." They may suggest your teams "sprint" to get work done, and yet do so at a "sustainable pace." They may tell your management that agile helps teams "go faster" while assuring your teams that agile isn't about "going faster." They may insist that agile is more about culture and mindset than about practices, and then measure your progress in terms of how faithfully you follow a prescribed set of practices.

There are many more examples of this odd insider jargon, starting with the seminal buzzword itself, "agile." Over the years, the way agilists speak has confused and turned off many who might otherwise have benefited from applying agile values and principles. The presenter will share several stories of the unintended effects of agile-speak, and will invite you to share your own tales of woe and amusement.

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.

There is much talk about diversity in the software development field and in the tech industry in general, and yet most teams and organizations comprise mostly a single cultural group. The dominant group may be 20- and 30-something white males, as is common in Silicon Valley, or some other culturally homogenous group, such as H1B holders from the same country, as is common in large corporations. 

When nearly everyone in an organization has the same general worldview, problem-solving approach, educational background, life experience, and so forth, the organization tends to suffer from groupthink - they can only conceive of a single approach to achieving a goal or solving a problem. When faced with a unique challenge or an unexpected change in circumstances, such an organization often has great difficulty.

In contrast, a diverse organization can bring to bear a variety of perspectives, experiences, collaboration styles, and problem-solving approaches. The rich blend of differences enables the organization to adapt to change and to overcome unexpected challenges creatively and flexibly. How can we build a more diverse workforce in the software development field?

Many large organizations try to get real innovation with lots of time and resources, but many end up failing and complaining when their innovation never arrives.  What we see in these organizations is that there are individual and organizational habits that cause innovation efforts to fail.  These organization rewards acts of heroism rather than acts of learning and punishes those that makes failures.  As the individual level, it encourages maximizing completing project work over learning and minimizing taking risks.

What this all means is that these organizations have a culture that inhibits learning and creativity.  These organizations wonder why innovation never comes.

True innovation in the IT world is only possible by leveraging creativity, which requires a mindset of learning and being able to accept failure.

Improvement and Coaching Kata also known as Toyota Kata, is a model and technique that can help incrementally move IT organizations towards a culture learning and experimentation.  Its practices involves everyone in the organization working collaboratively towards the vision of the organization.  By understanding where the organization wants to be in the far distance future, we analyzes what is the current state and value streams of the organization, and what experiments could be run to learn more on improving the various processes.  All continuous improvement efforts are executed with systematic experiments with the vision in mind.  The primary outcome of these experiments is learning. It does not matter if experiments succeed or fail(to a certain degree), only if we apply its valuable learning to the process or new experiments.  

By doing Improvement and Coaching Kata on a high frequency cadence(daily), new habits form that encourage learning and experimentation. 

When organizations start to adopt the DevOps methodology, many groups tend to react in similar ways.  The business and PMO office will see it as "something" to buy, implement and deliver product faster, while the techies will think of the many cloud infrastructure tools enabling continuous integration, continuous delivery, monitoring, and automation.  As human beings, we tend to focus on what the practices are("the doing"), and we lose sight of what is really important("the being").  For DevOps adoption, we need to ask ourselves,  What is the mindset behind DevOps? its values? its principles?  

Let's get away from the chatter of "doing" DevOps and move more towards "being" DevOps.

Instead of listening to the great stories on adopting DevOps and its technical complexities, we'll experience through an agile game

• What does DevOps look and feel like end to end?
• What is the mindset behind DevOps?
• What does DevOps culture look like?
• Your own self-realized outcome!

Subtitle:  The CMMI Is Still Among Us – How To Cope

(This is an update to a presentation given at STC 2003 entitled “The Agile Non-Debate.”)

Agile methods have spread worldwide, and have helped bring tremendous improvements in system development.  And yet, they are not 100% successful.  When I entered into discussions about using agile, IEEE, CMMI, ISO, and other standards, a common position was that CMMI et al suck innately, while agile efforts failed because people were “doing it wrong.”  This polarizing position was a distraction. 

Now, such polarization can be damaging.   Despite Agile’s increasing toehold in the public sector, the CMMI is far from dead; organizations are letting contracts based on agile requirements with one hand, and others based on CMMI and other certification-based models with the other hand.  Treating the two as mutually exclusive is just too hard, and its unnecessary.  Worse, it clouds the reality of how the two approaches actually differ and how they can be harmonized.  While a SCAMPI-like appraisal method for Agile has not gained wide traction, such a monster could arise, and understanding Agile CMMI interpretations could help organizations survive such a monster, and perhaps help Industry nip it in the egg.

In this session we will discuss briefly how the CMMI world got to be such as mess, how Agile has helped cut through a lot of that, and how to prevent some of the same ills from infecting the Agile world.  The core of this discussion, however, will be about juggling agile performance and CMMI compliance simultaneously.

DevOps is all about using automation to accelerate and expedite development and operations processes. However, tools are only as effective as the processes that they enable.  How do you ensure you get the most out of your DevOps solution within the context of federal processes?  A DevOps solution provides transparency and can output an overwhelming amount of data.  How do you make sense of the data and pinpoint the actionable items to make informed decisions?  Security threats are real.  How do you ensure that your DevOps solution will be resilient and available in spite of persistent threats?

This session will discuss these challenges, potential solutions, and provide a demonstration of an Intelligent DevOps solution.  

Most people would say that dedicated teams are a must for Agile effectiveness.  However, many government and contractor organizations have constraints that lead to situations in which teams must include resources that are not dedicated to that team.  This session will cover challenges that arise from such a situation, potential options to overcome them, and a case study from recent federal experience.

Mainframe systems continue to play an important role in large IT operations. Contemporary software solutions often comprise components that run on multiple platforms, from smart phones and tablets to Windows, OSX, and *nix systems, and mainframes. 

Is it feasible to extend modern software engineering practices like continuous integration; automated deployment; automated unit, component, and functional testing; and test-driven development to this venerable platform? It turns out to be quite feasible. There are several practical approaches to the problem, including commercial products from IBM and third parties; off-platform test drivers such as Cucumber, Concordion, and FitNesse; service virtualization products; on-platform approaches such as Java on zOS Unix System Services; hand-rolled mocking of CICS, DB2, and MQSeries resources; using IBM utilities to isolate and test individual steps from batch jobstreams; and isolated off-platform solutions based on hand-rolled test frameworks running under S390 emulation or mainframe-compatible compilers.

This session provides a summary of several of these approaches. Unfortunately, it isn't feasible to run working examples on an actual mainframe in the context of the conference. We can show code that works and walk through it to illustrate approaches to test automation that are in use in real mainframe environments, and we can demonstrate the emulation-based solutions that don't require a connection to a real mainframe.

To wrap up, we can have a group discussion about the specific testing and automation issues you have in your organization and how you might introduce test automation on your mainframe systems. Better yet, you can share your own stories of how you have solved this problem.