More CMRO Lessons

Last week I spoke to one of the people working on the Air Force implementation of CMRO for the ECSS project. A small group of people got an instance of 12.1.3 RUP5 up and running to support a series of conference room pilots of the functionality. Here are three timely takeaways from that conversation:

1. Sticking to Oracle naming: They are shifting to “visit,” “routine,” and “non-routine” for the same reasons we are. When they talk to real users in the conference room pilots, they explain the differences and the reasons, and folks generally get it. They are also finding that there are expected configurations that can be done in many cases. For instance, TCTO’s can be created as a defined program type without customization.
2. Considering business case before customizing: The word “document number” has a very specific meaning within their (and our) requisition system. Oracle’s document management system also uses a “document number” to describe a technical document. One of the users asked to disambiguate the term by changing the name. Changes like that will be made only after a business case to determine real cost of making it. We’ll do the same before we make a change like that.
3. Big fans of UPK: They are finding the UPK is a great training aid. He’ll be sending me a copy of the scenarios they configured for the conference room pilot. It will probably look similar to the PowerPoints that some of you have already seen on the Oracle CMRO CAB collaboration site, but I think the UPK content, which reflects RUP5 capability, will help the dev team understand the changes and develop a better sense of what has changed.  That knowledge will help us decide when to make the upgrade.

As he described their pilot, it was clear to me that face-to-face initial training is an important part of change management. It’s much better to let folks vent to and ask questions of a live person, particularly in the early stages. When we do the initial pilot with the 2314, we’re planning to include plenty of face-to-face training.  And listening.

Two of the people who did the technical work of configuring the system are members of the CMRO CAB. Since they are the only customers who have an instance 12.1.3 RUP5 up and running, they are a great source of technical expertise. I encourage you to use them!

photo credit: Jeremy Brooks

What will it take?

As we continue to plan the releases that will allow us to deliver Configuration Management (CM) and Maintenance Management (MM) capability in CG-LIMS and retire the legacy ACMS application, I want to make sure we continue to ask ourselves three questions others will ask of us.

We should push ourselves to these questions to a level of detail appropriate given our experience on this project and past projects:

1. What can we accomplish this calendar year with the dev team’s current velocity?
2. Given the dev team’s current velocity, when do we think we will implement the CM and MM requirements in CG-LIMS necessary to replace ACMS?
3. What does this team own that we can change to replace ACMS this year?

I know this forum isn’t the right place to answer these questions. But I want to make sure we are using the planning sessions this month as a place to answer them. We need to identify what, if anything, we need to begin doing differently now, while we still have the opportunity to impact what we deliver this year.

The folks on the front lines of mission support are struggling to support Coast Guard missions and transition to modernized logistics processes relying on a mix of legacy tools, including ACMS. Strategic planners need some clarity on when we think CG-LIMS will be available as a platform to support additional assets rather than continuing to migrate assets into ACMS.

Our vision remains to modernize logistics information systems to support common logistics processes across the enterprise. Retiring ACMS is an important step in “making it real” for end users. CG-LIMS will become very real for a group of end users when they stop using ACMS and start using CG-LIMS. We need to begin painting as clear a picture as possible of when we can make that replacement a reality for them.

photo credit: Petty Officer 3rd Class Levi Read

What did we do well?

I’ve received some strange looks over the past year when I’ve ended meetings with the question, “What did we, as a group, do well in this meeting.”

Today I want to take a moment to fill you in on where the question came from. I stole it from a book called, “The Thin Book of Appreciative Inquiry” by Sue Hammond. One of the major assumptions of the change philosophy of Appreciative Inquiry is that in any organization, there is stuff that works and change can be managed by identifying what works and figuring out how to do more of what works.

Find what works. Do more of it.

I used this as part of the internal marketing as we changed to a low cost non-major acquisition led by the Coast Guard that would leverage what’s working within the development teams at ALC and OSC.

This belief that we are doing things well at ALC and OSC is critical to delivering CG-LIMS quickly. We’re not starting from scratch. We’re building on what is already working, and applying that within the opportunities and constraints provided by a COTS EAM tool.

If you’re interested in reading more, send me an e-mail and I’ll lend you the Kindle book (one at a time, 14 days at a time). You can read it over a lunch break.

On the second page, you’ll read this challenge:

There is no other way to discover how it works and, indeed, how practical it is, until you do it. You do not have to have a major change program in order to experiment. you can start with something as simple as asking a question at the end of a meeting: “What did we, as a group, do well in this meeting?” You will get a stunned silence. Then people will begin to throw out some very carefully worded responses. Depending on your position and title, they will try to figure out the politically correct response. Responses will quickly turn into a discussion about what didn’t work. We are very good at talking about what doesn’t work…. It is my opinion that we have little practice looking for what works and finding ways to do more of that.

If you want to learn a bit more on the idea without cracking the book, I’d encourage you to read this quick article with a few examples from HBS in the article, “The Art of Appreciative Inquiry.”

photo credit:  Kerekes Janos Scongor

Learning

One of my high points last week was attending a training workshop on Agile System Development. The workshop focused on executing projects in the federal space.

It was wonderful to see some old friends from ALC and to meet folks on the development team I hadn’t worked with before.

Today I’ll share my three biggest takeaways and invite others to do the same in the comments.

1. We’re approaching the basics right. The day started with a basic overview of the Agile approach to delivering software. It left me feeling like we’re doing the basics right. I was pleased that they covered the INVEST acronym to describe what makes good requirements. That’s been on my list of things to share in the blog since I first heard it from the leader of the DHS group developing an Agile approach to Level 1 and 2 Acquisitions. I know it’s commonly used in Agile circles, but I hadn’t heard it used within our team. I was pleased that the requirements manager from ALC was familiar with and supported the notion that that good requirements should be Independent, Negotiable, Verifiable, Estimated (or Estimable), Small, and Testable.

2. We’re fortunate we can leverage existing contracts and in-house talent. Much of the extra overhead and extra work in executing Agile development in the federal space comes from the fact that the requirements development and system development are often separate efforts done by separate organizations and separate contracts whose communications are restricted by OCI concerns. We’re fortunate that at this point, our Sponsor’s requirements are defined and approved. The rest of the requirements definition will happen within the context of the system development team. This is consistent with what one of the speakers said about typical development in the commercial space, where there is less separation between the requirements team and the development team.

3. We’re fortunate to have tools to rapidly prototype and get user feedback. We heard about the notion of using “pre-visualization” to create code free prototypes as an intermediate step in requirements elicitation and refinement. It was good food for thought and led to some side conversations with folks with experience doing it. Fortunately for us, the two main ways we’ll deliver capability–configured COTS and changes to EAL–lend themselves to rapid prototyping with the user *without* the intermediate step of code free pre-visualizion using a separate software environment. On the COTS side, within two weeks we should have a demo environment established that we can use to show the basic interface and work alongside users to prototype ideas within the constraints of the COTS software. In time, we’ll also have a development environment we can use for iterative configuration. At some point, that becomes an environment we can use to work with end users. I can see us going from whiteboard to modeling environment within the COTS tool (which we’ll soon learn much more about) to seeing the results on screen without using an intermediate code free pre-vis environment as described in the workshop. For changes to EAL, we’re fortunate to have well established UI and team of people who grew up doing prototyping with live apps the way Ryan Singer of 37Signals describes in a 2010 talk at the “Future of Web Apps” conference in London.

Those were my big three takeaways that apply directly to CG-LIMS. Here’s one more thing I heard that’s so true: “Great things come out of people whom you allow to think.” Indeed.

What did you take from the experience? I’d love to hear from anyone who was there!

photo credit: Martin_Heigan

CMU on Agile

Today’s post shares a paper that Carngie Mellon’s Software Engineering Institute just released titled, “Agile Methods: Selected DoD Management and Acquisition Concerns.” The timing is great for us. I’d encourage you to read the three-page Executive Summary, then dive into the sections you find most interesting.

I’ll highlight a few excerpts here to make sure everyone on the team reads them. My hope is that the ideas will either stretch you as you think about how we’ll implement Agile for CG-LIMS, or they may serve as background that you can use to better communicate our approach.

One good insight is right in the Executive Summary:

Most Agile methods are comprised of practices that compensate for each other. For example, minimal documentation is compensated for by practices like information radiators; no code reviews is compensated for by pair programming; and minimal documented requirements is compensated for by test-driven development. Chosen piecemeal, Agile practices can leave large gaps and introduce risks. Selecting an established method brings in a set of compensating practices, and reduces risk.

There’s a section on Page 20 that describes the difference between how requirements are treated on Agile programs and traditional programs. It is outstanding:

An expected, but still striking difference we saw in Agile programs versus more traditional software programs was the attitude toward requirements. In the more traditional programs that some of our interviewees had worked on, a tremendous amount of effort, energy, and attention was paid to refining requirements statements to a low level of detail and obtaining multiple levels of approval of them before doing any prototyping or visible design activities. The confidence of the development team in how accurate the requirements were in terms of the user’s needs was low. However, they could not substantively move forward with the design until the complete systems requirements had been approved. A reviewer who had a similar experience said, “To date, I have not seen where the rigor applied to our requirements has brought any value to our product.” The attitude toward requirements in the programs we interviewed using Agile was much more focused on a definition of only enough capability to bring acknowledged value to an end user, with much less focus on ultimate completeness of the requirements set. In the program using Agile, the team was confident that with the user involvement that they knew they could count on, they would discover additional requirements as the project evolved and that all the requirements they worked on would provide definable value to the customer.

The shared value of prioritizing end-user involvement to build confidence in requirements early allows both the acquirer and developer to permit appropriate ambiguity early in the project. This is contrary to what is more typical in a traditional acquirer/development team, which strives for completeness of a requirements specification prior to significant design work. Although this is a false completeness (almost everyone we spoke with acknowledged that the complexity of today’s systems makes it impossible to completely know a system’s requirements prior to design), the shared values of the acquirer/developer team are focused on the completion aspect of the requirements rather than allowing evolutionary learning about them.

The Agile attitude toward requirements must inform any further thought or work applied to the requirements in the CONOP and ORD.

I’ll also echo the guidance from one Colonel to his PM’s on page 20. It is fantasitic guidance for us to put to use as we move forward to the planning for configuring the COTS software to meet the CM and MM requirements.

Planning Release 1 … [should contain the] smallest fieldable amount with tangible ROI that the customer will agree to, and
* should demonstrate that the system will work end-to-end … or a logical chunk of it that can be built upon.
* Pick the easiest requirements that have the best quality data.
* Fight for this. The customer wants it all in the first release … every time.
* Give success earlier, validate assumptions, buy time to further analyze the harder things.
* If budget cuts take everything except the release 1 money, you are still a success. Another key concept is that the whole point of using Agile is to reduce risk by defining the highest value functions to be demonstrated as early as possible. This means that technical reviews like PDR and CDR will be used to validate early versions of working software and to review whatever documentation had been agreed to in the acquisition strategy.

I want us to have the same view of requirements described by this group:

One group of interviewees emphasized that, unlike other programs they had worked on, they were allowed to accept that the requirements will change as a routine-rather than exception-condition. Agile encourages interaction among the entire stakeholder team to determine what is required to satisfy the current user needs. Thus, they do enough analysis so that user stories (their way of expressing requirements) assigned to the current iteration can be accomplished, but allow for continuing accumulation of data for stories that will be implemented at a later date. This approach also allows them to not waste effort on items that may change or might be interpreted incorrectly.

I would also love to see approach to requirements reflect the value placed on user involvement described on page 58:

It is important to note that even after stories have been broken down and estimated, they generally are not specified to the degree that would be found in a traditional requirements document. This does not necessarily imply increased risk, because successful Agile teams rely on ongoing dialog with users, user proxies, and subject matter experts throughout the course of the release to gain insights needed to satisfy the users, usually better insight than could be gained from typical requirements-specification documents. If the user interaction that makes this dialog possible is missing, the benefits associated with user stories as an anchor for the requirements will be lost.

One of the sticky wickets is how to handle the big capstone technical reviews like SDR/PDR/CDR in an Agile environment. They ask a fantastic question that is the final thought I want to leave you with:

In order to determine the type of criteria needed for any review, the intent of the review or purpose must be known. This raises a question: What is the purpose of any technical milestone review?

As we update planning artifacts neeed for the Design Phase, I challenge each of you to ask the same question for each planning document. “What is the purpose of this plan? Who needs it? What are they going to do with it?”

The last excerpt I’ll share describes the value of information radiators:

Communication amplifies individual learning into team learning through information radiators. Often, these take the form of big, visible charts that are posted in common areas of the workplace. They should display progress, obstacles, and actions, and be easy to update. Thus, they “radiate” information and support communication and rapid response to changing project conditions. In geographically distributed teams, other mechanisms besides physical wall charts are used for the same purpose, and some vendors of support tools for Agile methods incorporate tools specifically meant for this purpose. One of our reviewers commented on their use of the wall-chart style of information radiator: “[This was] one of the key practices used on [our program] increment 1, which brought about significant change in a short period of time.”

One of the things that struck me as I was reading the section on change management is that I think we need to simply accept that Executive Leadership is not going to change their view of Agile until without seeing success. Our job? To show success.  As quickly as we can. I think their desire for stacks of documentation, PowerPoint, meetings and pre-meetings can be quenched much more easily once we show the first bits of working software that satisfies users and delivers business value.

If any of that piqued your interest, take a few minutes, grab a cup of coffee, and download the report!