Moving Day

The CG-LIMS Project Blog is moving to CG Portal.

When I started this blog in 2008, the Coast Guard had no enterprise blogging platform. In the very first post, I told you I would move the blog to the CG enterprise collaboration tool if I could.

Now that the Coast Guard’s enterprise collaboration platform has a blog component, we’re moving there. It will be simpler to use, and it will be better integrated with the rest of the collaborative content on CG Portal we use every day.

The CG-LIMS Project Blog is now at https://cgportal2.uscg.mil/units/cg9/3/3/4/blog.

I’ll transfer administration of this Intelink blog to someone else on the team so it remains visible after I retire if the team chooses.  The exported version will also remain at http://cglims.wordpress.com.  That’s a great resource to search.

I realize I’m giving up the opportunity to share ideas within the Intelink-U community who may not have access to CG Portal.  It’s not a decision I take lightly. I’ve weighed the value of that wide audience against the simplicity for my relief and decided it was best to move to CG Portal. I will certainly miss the dialogue with members of the larger community.  Thanks for your participation!

photo credit: H-65 at Sunset by  simply_dan

Just Say “No”

Bottom line:  Just say no to COTS gap fillers.

Yesterday a small group of us met to identify actions we could take to keep us on track to deliver the capability we signed up for in Release 3 per the Revision 1 baseline.

In December we decided to use a simple burndown chart for Release 3 to show our progress in completing the planned work and work identified after the release planning review that we thought needed to be done to deliver Release 3 capability.

We stole the idea from Mike Cohn. Please take a minute to read his post at http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown.   His final image shows how one can use the intersection between lines fit to the tops and bottom of the bars can help estimate when the work will be completed.

Here’s what our burndown chart looked like after two sprints:

Yikes!

The two lines never meet. The capability never gets delivered.  That’s not what we want.

The good news is we put a simple tracking tool in place before we started the first sprint. After two sprints, it told us we added more work than we completed. It told us we needed to do something different if we wanted to deliver on our commitment.

What did we do? We identified the causes pushing completion to the right, identified possible actions to pull the completion back to the left, discussed, and decided on concrete next steps.

Causes:

• deviating from our vision to implement COTS and change business processes as needed to do it
• trying to solve COTS capability gaps. three specific issues accounted for majority of added story points: serial number case sensitivity, unit configuration name change, part number change
• trying to solve later stage problems as soon as we see them
• trying to solve potential user workload issues
• still finding initial set up stories
• systems issues (not a factor now, but may be after March 6)

Possible actions to pull schedule back to left:

• focus on shipping minimal viable COTS product.
• make front-end decision to intentionally *not* do things to fill COTS gaps
• put COTS gap filler user stories at the bottom of the product backlog as possible future work
• for systems issues, we’re already bringing in expertise to have RUP5 installed in Dev 2 prior to next sprint
• considered bringing in additional Oracle CM/MM SMEs, but decided that it would not help

You might remember that last February, when the President’s Budget was released and we first went public with the planned funding from FY 12-17, I told you the CG-LIMS budget would remain small.

We will not be able to afford to customize the COTS tool, or even over-configure it. Limited resources and a focus on serving customers’ real needs will keep us from delivering any more than is absolutely necessary. We will create no more documentation, no more PowerPoint, and no more software than is absolutely necessary to accomplish the mission.

Over the past two sprints, in our eagerness to deliver the best possible application for our users, I think we took more work on our shoulders than we should have.  We lost our laser focus on configuring a minimally viable COTS application.  We started down a path of over-configuring the COTS software.

Fortunately, we didn’t do most of the work we identified. We identified it and added it to the Release 3 backlog.  We made the red bar longer.  Now we realize we need to take a second look at that added work. To keep the project alive, we need to accept we are going to deliver bare-bones COTS system initially. That is what the Sponsor has wanted for years.  COTS gap fixes must move to the bottom of our list of things to do.

After discussion among the PM, PMd, Sponsor’s Rep, and Product Owner yesterday, here’s what we decided to do:

Specific actions:

• 2/27: Review AgileZen and identify “COTS Gap Filler” stories in Release 3 Backlog
• 2/27: move “COTS Gap Filler” stories to bottom of Product Backlog
• 2/27: Update the Release 3 Burndown Chart to reflect changes in remaining work
• 2/27: remind ourselves that we are implementing COTS to deliver a minimal viable product. (This post is the first reminder)
• at every future planning session:  ask “Is this a COTS gap filler”

How will we know those actions move the needles in the right direction?

• By 2/28: The updated Release 3 Burndown chart shows lines that converge by the eighth sprint with reasonable cushion for unknowns.

After March 6th we’ll know whether we need to take additional action if RUP5 is not installed in Dev2.

I know that’s a lot to digest. If I’ve left anything out or created confusion or questions, shoot me a note or drop a comment.

ELIS Lessons

Today I will share a few lessons I learned from attending three Electronic Immigration System (ELIS) events. You might remember ELIS from a September 2012 post.  ELIS is being delivered by the U.S. Citizenship and Immigration Service (USCIS) using an agile methodology. The USCIS CIO is the leader of the DHS Agile IPT and is leading the charge to adopt more effective software deliver methodologies. As we learn and grow on the CG-LIMS project, it’s useful to see how other projects in DHS are applying the same guidance we’re trying to follow, starting with the initial WhitePaper delivered by the IPT. Since ELIS isn’t my project, I’ll be careful about what I say publicly. I know you’re used to brutal honesty about CG-LIMS. I’ll be more circumspect in sharing details about someone else’s program.

Below are some takeaways I think are useful for us.

Our approaches to the key Agile reviews are similar. I attended an ELIS Release Planning Review, Sprint Planning Review, and Sprint Demonstration. It’s clear that we’re following the same general guidance. Like CG-LIMS, much of the planning at the release and sprint level is done prior to the final review with the decision-makers. The SES decision makers understood — and welcomed — the fact that planning was being done by team members right up until the last minute before the reviews. It makes for a little messier session than some might be comfortable with, but I thought it was a good messy. Like ours.

Reviews are conducted to surface risks. The CIO explicitly described one of the goals of the sprint and release planning reviews is to surface risks and ask questions. They acknowledged that the reviews might serve as a forum to have dialogue that leads to actions to mitigate some of those risks. I think we try to do the same thing with CG-LIMS. Most things are settled before the final review, but we see it as a productive use of time to identify risks or decide to change the plan right up until the time we commit to a release or a sprint.

The O&M team operates as an Agile team on same cadence cadence as the dev team. If I have the numbers right, there are now five Agile “dev” teams and one “ops” team. Reps from all the teams participate in all the reviews. This helps keep everyone on same sheet of music. The sprints begin and end on the same date. The only difference is how often they ship. The ops team ships at the end of each four-week sprint. The dev teams a rhythm of three sprints, then one “hardening” spring for each release. During the release planning session, there was some discussion over the value of integrating the ops team in the reviews. Down the road, when CG-LIMS requires both dev and O&M work, I think it will serve us well to start with the assumption that we will treat the O&M team as another scrum team that is operating on the same cadence as dev. The only difference will be that the ops team ships to production after each sprint, whereas the dev team may take more than one sprint to deliver a product that is truly shippable.

Don’t re-estimate within a sprint. The ELIS process is to not re-estimate within a sprint, but they do update estimates for remaining work after each sprint. It wasn’t clear to me that they had accounted for those possible changes at the release level. In our current release 3, we planned for a 33% risk factor. We had a capacity to do 400 story points and planned a release that would take 267 story points. The remaining 133 points provided a risk factor that could be consumed by, among things, stories that had to be re-estimated. I think that was wise. I know the standard Agile approach would be to just deliver the release with just the highest priority requirements from the backlog that fit. But our reality is that we still need to demonstrate that we can predictably ship software. We need to show we can deliver a minimum viable product that provides the capability we promised in the time we promised. I think the 33% risk factor was a reasonable planning tool to help us do it for this release.

Architecture work is done by an Agile team. The five ELIS teams included one that is doing the kind of architecture and system setup work we are coordinating with OSC and with the systems group at ALC *outside* of the Agile work processes. I don’t want to change anything immediately, but I think it is will be worthwhile in the future to intentionally train that group on Agile principles and begin to manage their work using the same practices the dev team is using. I realize those groups are part of larger organizations and support work other than the CG-LMS project. But perhaps if we help them to work in a more explicitly agile way to support CG-LIMS, they can become a catalyst for change throughout the rest of their organization. As we grow beyond the single agile dev team as we take on SCM work, we’ll gain experience in coordinating multiple dev teams. Down the road we might see the goodness of standing up an architecture team whose efforts are planned, managed, and coordinated transparently and explicitly using the same set of agile processes.

They share our ORD and Roadmap challenges. In the release planning review, I saw that the ELIS team has many of the same challenges that we have. They have to deal with how to divide capability that can’t be completely finished within a four-month release. They also share our pain in tracing user stories back to an original detailed ORD written many years ago for a waterfall process. They have to maintain a roadmap that goes out for several years to show how the whole ORD will be delivered. How many years did it take us to write and get an ORD approved that is more detailed than we really need? Don’t answer that.

They’ve earned support from the top. The head of the USCIS (the equivalent of our Commandant) attended the Sprint Demo. He was an enthusiastic supporter of the process and the results. He told the team that since moving to an Agile process, the Executive Steering Committee has as renewed energy and excitement. He praised them for taking on the big effort and making it happen at a pace that is remarkable. There’s a part of me that wished we had that kind of support from the very top. Don’t worry. It will come. Success begets success. Once we show we can predictably deliver capability the field can really use, I think we’ll have vocal support from the top, too. Right now, it’s hard to get flags and SES’s excited about seeing working software that’s so far away from something that meets a complete business need. But just wait until they hear we’ve delivered something that lets Coasties stop using some piece of the old system and start using the new one. That’ll grab their attention.

 

Getting Smarter on EBS

Today I have another quick post with a source of Oracle information that might help us configure and support EBS more effectively.

Over the past year, I’ve several posts from Steve Chan’s Oracle E Business Suite Technology blog that I thought were relevant to the dev team. I learned of the blog first through Emil when we were dealing with issues related to Java 7 certification with EBS. I’ll admit to being frustrated to see questions on the blog answered with things like, “Oracle’s Revenue Recognition policies prohibit us from discussing….” But  some of the pointers to resources Steve shares on the blog can benefit an organization like ours that is new at EBS implementation.

For example, here are some of the posts I sent along to some of you individually:

• “Minimizing EBS Maintenance Downtimes”
• Webcast on changes coming to deployment and sysadmin with version 12.2
• Whitepaper on integrating EBS 12 with other applications 
• Webcast on advanced EBS management with Oracle Enterprise Manager 

If any of that seems interesting to you, I encourage you add the blog to your RSS feed. That’s an easy way to make  the updates come to you. They won’t all be useful to all of you. But there’s enough goodness often enough that I think somebody at OSC, ALC, and HQ should keep an eye on it.

If anyone needs a reminder of how to subscribe to an RSS feed, CommonCraft has a great primer at http://www.commoncraft.com/video/rss. There are plenty of great RSS readers available for the fancy iPhones and iPads many of you carry. Me? I use Reeder on the iPhone and Mr. Reader on the iPad.

CMRO Newsletter: Get it While It's Hot!

I’ll use the next two posts to share sources of information about Oracle EBS I think will be useful for the team.

We know one thing Oracle generally doesn’t talk about:  release dates.  An official Oracle blog says:

Oracle’s communication policies prohibit us from speculating about release dates for unreleased software. We are not permitted to give estimates, rough timelines, guesses, or anything else that remotely resembles specific guidance on release dates.

We know not to expect details on when.  But at the Customer Advisory Board Meeting last year, the product manager committed to create a monthly newsletter to communicate with CAB members on what‘s coming and how they can better support us. Some of you received the first newsletter in an e-mail from Ms. Harper late last year.

To subscribe to the newsletter, you need a validated Oracle.com account. You can create an account or login here.

Once you have an account, you can subscribe to the Complex MRO Newsletter by sending an e-mail to Ms. Harper.

I shared the first newsletter within the CG team in our CG Portal site to help you decide that it’s worth it to subscribe. You can find it in the PMO’s CG Portal site  in the Project Document Library >> System Engineering >> Templates >> Technical Data >> CMRO Customer Advisory Board folder.  The file is called “Oracle Complex MRO Newsletter 1.”

I posted the first issue, but I encourage CG-LIMS stakeholders to subscribe to receive it directly.  The content runs the gamut from stuff that will be useful to the PMO, the SDA in E City, and the folks keeping the system up and running at OSC.

The Dashboard beginning on page 6 may be a useful list of project that are recently release, being worked, and next up. That awareness could be timely for the dev team as we begin to bring the product to end users in a limited pilot and start to get the “what about x” questions.

On the last page of the newsletter there is a link titled “Oracle Support Best Practices” that leads to a series of 30 minute sessions related to maintaining a healthy system and avoiding downtime, and minimizing upgrade risk.  There’s probably a topic or two in that list that will be worth an hour of the sys admin’s time.

The newsletter is chock full of good stuff. Hillary didn’t provide a test, but you know there is one. It will come when we ship a product and the customers we serve demand excellence of us. Please have a look at the newsletter.  You just might find something that helps you ace it!

Photo Credit: Poster Boy NYC via Compfight cc

From the Summit

Today I’ll share some feedback from the Supply Summit at SFLC that I told you about in the previous post.

Rob did a great job updating the group on what we’ve accomplished, where we’re headed, and how some of the folks in that room can help.

The slides he used are at https://cglink.uscg.mil/b757e92e.

The demo we brought and tried to show is at: https://www.intelink.gov/go/peuIbo8.  (Note to self: bring speakers next time.)

Here are my top four takeaways  from the day. I invite Jim and Rob to add any additional thoughts as comments.

1. We can learn from the training that’s being done for the CMPLus replacement. One of the briefs before ours was on the status of the tech refresh of CMPlus throughout the Coast Guard. You may recall the August 6 post that described the upcoming changes to ARMS and CMPlus. I wanted to make sure our implementation team was attuned to the challenges and lessons of using LiveMeeting as part of the initial training:

We’ve talked about using technologies like that in the initial training; they are doing it. We should learn from them.

We’re fortunate that folks from SFLC are on our implementation working group, so we’ll have their perspective baked into our plans. It will be great to be able to share from their real lessons learned during this implementation over the next year. We will be in a position to learn from the CMPlus / ARMS migration to provide a better experience for the ACMS and AMMIS user migration. The users will have lived through it. They will expect that we’re aware of it and have learned from it.

They now have some lessons to share based on experience.  Overall, LiveMeeting was a big help. The field users appreciated the flexibility they provided by offering a choice of time slots during a three week window in advance of the site visit. They found that 40 people was the upper bound on the number of attendees. We’re fortunate to have access to folks with firsthand knowledge of the experience to help us with our implementation planning. Many of the users will be the same. They will expect us to have shared lessons and steal ideas that worked from the CMPlus refresh.

2. The CG-LIMS AC&I project has been de-scoped.  Really. I was surprised that some folks thought they were hearing it for the first time.  We can’t do a tech refresh of every logistics systems with an AC&I investment of $40.9M. Our message has been consistent since 2011 that are doing a tech refresh of the legacy parts of ALMIS to meet enterprise requirements. We have been consistent in saying that dealing with the remaining legacy systems would be a separate project. The messaging got really specific as soon as the President’s Budget was submitted to Congress in February 2012.

But I learned that one can never communicate enough. We had a spirited discussion with people who were hearing the news of the reduced scope for the first time. They may have heard the message two years ago, but it didn’t register until this time.

3. We can start making progress toward a single logistics system NOW. Once the message sank in that bringing assets from systems other than ACMS and ALMIS was outside the current CG-LIMS scope, someone observed that it means we’ll have a separate CG-LIMS and VLS when the AC&I CG-LIMS project is done. No!!!! Our goal should be to migrate the legacy systems along the way so we end up with just one system when we’re done migrating the assets from ALMIS.   We should not assume that we have to keep all of VLS running until FY 2018!  As soon as we have the first bits of CG-LIMS in production, we have an enterprise capability that should be considered when we choose to spend each dollar maintaining legacy systems. I reminded the group that we brought in experts from other communities on the source selection team that chose the COTS tool.  They were selecting the tool they would eventually put to use.  We intentionally hosted the system in the same place as VLS so the folks responsible for VLS can start strategizing how to migrate to CG-LIMS. As we have more capability configured in CG-LIMS, the planning will become more detailed. Folks familiar with the all the legacy logistics systems are members of our IPTs and Working Groups. The declining budget environment should drive creative thinking about how the system we configure and delivered by the current AC&I project can be leveraged on other communities.

If you’ve stuck with me this far on this topic, you’re probably wondering when I’ll point you to the Guiding Principles we wrote and began sharing after the Supply Summit two years ago. The first time I shared them on this blog was in a July 2011 post.

That guidance was refined a bit over time, but the overall message has been consistent. The current version is something like this:

• Don’t migrate unnecessarily from one legacy system to another
• Don’t arbitrarily make one legacy system or module look/feel/perform like another (this may be paving a cow path)
• Don’t invest unnecessarily in legacy systems
• Continue to target industry standard based process improvements
• First product line enrollment (CASA) will inform timeline for:
  • Additional functionality
  • Non-ALMIS product line migrations
• Host at OSC, configure at ALC. This prepositions and makes the new tool visible to surface logistics systems teams at OSC to do concurrent data mapping analysis while ALC configures for CASA.
• Don’t expect SSA resource requirement to increase; just different skills required
• Existence of SDA skills and resources for three different logistics system technologies, will mitigate resource needs under a future single technology baseline.
• With each additional step taken, the plan for bridging from Legacy to CG-LIMS will move from more Strategic to more Tactical
• Take the first step, revise. Take the next step, revise. Repeat as necessary.
• Change management (training) will look, feel and cost much the same as logistics transformation (LTPIO) did. It will also require the same commitment to funding from the base, as LTPIO did.

4. They know it’s real, and they want to help. Folks in all the logistics communities better apprecieate that we are delivering a tool that will eventually be used in all communities.  Now that they see it’s really real, we may have more lurkers at the sprint demos and throughout the upcoming 2314 pilot. We welcome that. We may also have some additional engagement on the implementation working group. We welcome that too. We may also have more engagement from folks working on more specific plans around migrating from other legacy systems. That will be fantastic!

Photo Credit: Storm Crypt via Compfight cc

Summit View

Tomorrow several of us from the project office will be attending the CG-44 Sponsored “Supply Summit” at SFLC.

That makes today a good time to go back and re-read the post wrapping up last year’s summit. It’s worth your time to read the details under each of the five takeaways I shared:

1. CG-44 is rationalizing Coast Guard Logistics Policy.
2. The ORD is the top-level statement of HQ policy for CG-LIMS.
3. The timing is excellent for us to work with users to implement business processes and IT together.
4. They’re planning for a future with CG-LIMS at the center.
5. There is lots of excitement for where we’re headed.

I provided a link to the brief in one of the comments to that post. The link doesn’t work after the CG Portal upgrade to SharePoint.  Last year’s brief is now at https://cglink.uscg.mil/f9d17e77.

You can also get to it by navigating through our CG Portal site:

Project Document Library >> Prog-Mgtment >> Briefs and Reports >> Briefings

What the message this year?  We are executing the strategy we described at the last summit. We are doing what we said we’d do.

We delivered working software. The first release is in production. We are starting a pilot program next month using one HC-144 at ATC Mobile.  Yes, we delivered less capability in release 2 than we planned, but we’re delivering. We have been moving forward in the same direction for the past year. We know the COTS tools better and are providing our investors with an updated timeline. We’re working on the updated baseline now that tells them what we’re not going to be able to deliver within the current $40.9 planned investment in the FY 2012 President’s Budget and FY 13-17 CIP.

We’ll soon start planning for the next group of requirements: the Supply Chain Management Requirements grouped in the ORD in as Segment 2. We will be standing up another Agile team at ALC to work in parallel with the team now focused on CM and MM requirements. The Supply Summit is a great forum to make and to renew the personal connections to ensure we have real engagement with SME’s from SFLC.  That support will be critical to ensure we’re building a tool that meets the enterprise — not just aviation — needs.

The slide deck we’ll use this year is in CG Portal at:

https://cglink.uscg.mil/b757e92e

We’ll also show the demonstration conducted by CDR Taylor and Mr. Price that many of you saw linked from this post:

http://cglims.wordpress.com/?p=5860

We’ll have a few members of the PMO at the Supply Summit tomorrow.  I’m sure at least one of us will have some feedback that we’ll share in with you in the next post.  Until then, I encourage you to have a look at the briefing and recap from last year, and the briefing for this year.