SCRUM Master opening at NHQ

A couple things on salary...

 - CAP, Inc. is a 501(c)(3). They will never pay as much as some places.
 - COL in Montgomery is pretty low. You'd do alright on $61k.
 - They're not looking for a senior CSM. Only 3 years experience required.

I have not seen "lower than normal" market rates around D.C. It's crazy expensive to live here (I'm in NoVA).

I have not seen "lower than normal" market rates around D.C. It's crazy expensive to live here (I'm in NoVA).

I'm talking GS/Federal positions, mostly.  Pretty much poverty wages in D.C., unless you've got retiree, VA, and other income. 

For those of you who might be interested in tracking the SCR list *(software change request), it can be found at the bottom of the Commander's Corner page. You'll need to have permissions to view it; thus, I won't post the link here (sorry).

It currently has 72 ranked (racked and stacked by priority) SCRs, ending at page 4. There are, believe it, 11 full pages. So, whoever gets selected for this position has hundreds of software items as a backlog on arrival. Obviously, the team already on board are busy crunching away.


V/r
Spam

It currently has 72 ranked (racked and stacked by priority) SCRs, ending at page 4. There are, believe it, 11 full pages. So, whoever gets selected for this position has hundreds of software items as a backlog on arrival. Obviously, the team already on board are busy crunching away.

So you're thinking we will be keeping the existing WMIRS, eServices, etc., ... and it'll just be patches rolled out here and there?

I was hoping for clean slate status ....

It currently has 72 ranked (racked and stacked by priority) SCRs, ending at page 4. There are, believe it, 11 full pages. So, whoever gets selected for this position has hundreds of software items as a backlog on arrival. Obviously, the team already on board are busy crunching away.

So you're thinking we will be keeping the existing WMIRS, eServices, etc., ... and it'll just be patches rolled out here and there?

I was hoping for clean slate status ....

Well, I wasn't thinking that, exactly. I agree with your point though. There's nothing keeping a program manger (faced with the mass of deficiency reports) from coming to the conclusion that what might be necessary is a complete overhaul with a more integrated back end, coupled to a far more usable front end UI, and that the UI needs to be aimed at an average 8th grade reading level/KSA level for the basic interface, and an average 10th grade reading level for the more complex interfaces.

Certainly, as a guy who designs user interfaces (mostly for tactical cockpits I admit) I had high hopes for eServices 2.0, and am a bit underwhelmed, but there is a bit of progress there. The question is whether we'll accept the need for a systematic analysis of user missions (e.g. "analyze squadron level ES training needs", "analyze Wing level currency for ____ specialty", etc.), then map needs vs. capabilities, map currently supported and the needed functions and information requirements (e.g. reports, inputs and outputs), and create a development road map to invent or reuse the CSCIs to move from the current set of capabilities to the required one.

"Good luck, SCRUM master", O ye of a whopping 3 years of experience!

(Grin)
Spam

So prior to Kathy showing up, IT projects were rack and stacked by Joe Hall with input from a committee of volunteers on a monthly basis. At any one time, there were about 130 items on the backlog; most were  eServices modules (OpsQual and WMIRS being the top 2, with some other stuff sprinkled in). With competing priorities (ops needs this, PD needs that, CP needs everything, etc), it took a long time for backlog items to bubble up. BTW, this doesn't even touch help desk tickets that hadn't made it to the list.

Fast forward to Kathy showing up, she threw the list out, threw the help desk tickets that were bigger than simple bug fixes out, and went to all of the functionals at NHQ and asked them what was most important, thus the creation of the IT functional user group or whatever it's called now. The list you see is the product of that conversation, and now the SM's job is to play rodeo clown as these backlog items get burned down.

Going forward, if you ever want to see something changed through IT, your best bet is to channel it through the chain to the national volunteer for the functional that owns that process or module in eServices and get them to have their corporate staff counterpart (e.g., the Desmarais, Parker, Tourville, and LaFond's of NHQ) make the request to IT. That's how the stuff gets visibility anymore.

BTW NIN: Personify

They're looking for a SCRUM master? Geez, they probably have enough screwmasters....

So prior to Kathy showing up, IT projects were rack and stacked by Joe Hall with input from a committee of volunteers on a monthly basis. At any one time, there were about 130 items on the backlog; most were  eServices modules (OpsQual and WMIRS being the top 2, with some other stuff sprinkled in). With competing priorities (ops needs this, PD needs that, CP needs everything, etc), it took a long time for backlog items to bubble up. BTW, this doesn't even touch help desk tickets that hadn't made it to the list.

Fast forward to Kathy showing up, she threw the list out, threw the help desk tickets that were bigger than simple bug fixes out, and went to all of the functionals at NHQ and asked them what was most important, thus the creation of the IT functional user group or whatever it's called now. The list you see is the product of that conversation, and now the SM's job is to play rodeo clown as these backlog items get burned down.

Going forward, if you ever want to see something changed through IT, your best bet is to channel it through the chain to the national volunteer for the functional that owns that process or module in eServices and get them to have their corporate staff counterpart (e.g., the Desmarais, Parker, Tourville, and LaFond's of NHQ) make the request to IT. That's how the stuff gets visibility anymore.

BTW NIN: Personify

Nick, that's a very informative and enlightening post - thanks.

WAS (behind us):  I certainly think that dumping/discarding both the SCR (s/w change request) and help ticket list without putting out a notice to submitters was a sub standard, "non ISO" type of response, although I concede that Kathy (whom I've never met and know zero about) seems to have been put in the position of a single experienced doctor arriving at the scene of a mass casualty rail mishap, where a very few talented EMTs were doing their best against a massive overload with no time to plan or prioritize.

IS (going forward, as you constructively state it so well): I think we should give her/the team the benefit of the doubt going forward. If she ever sees this... best wishes, Kathy. You should know that CAP's biggest strength (and Achilles Heel) has always been the depth of its volunteer expertise, coupled with the relative 'flakiness' of reliable, long term support of team projects functions (e.g. curriculum projects, etc.). Drop me a line if you ever want some UX/UI support in wireframing/task and function analysis, UI design, or help with structured assessments/tests of prototypes.

V/r
Spam
Again Nick - great post. Thanks.

Sure thing. I think your analogy is spot on. All credit to Joe Hall: sustaining the systems they had was a full time project in itself, so there was really no bandwidth for innovating, yet they somehow managed to squeeze a little bit of new product out as they went. I know what it's like to have just enough staff to put out the daily fires.

I am curious what happened to all the open tickets, whether they were deleted, marked as solved/closed, or what. I don't think I had any open so I don't know for sure. I do know our open project list was abandoned, although I see some similarities on the new SCR report.


Sent from my iPad using Tapatalk

Rather than building all this homegrown stuff, has there been any discussion in simply ponying up for a configurable out of box solution that meets our needs?  K.I.S.S.   There would be an upfront expense but the ongoing expenses and maintenance could be less and provide greater agility for leveraging changing technology.   

Is there an "out of box" solution that does what eServices does? Think about all of the modules in there. What software package do you know of that does all that?

Rather than building all this homegrown stuff, has there been any discussion in simply ponying up for a configurable out of box solution that meets our needs?  K.I.S.S.   There would be an upfront expense but the ongoing expenses and maintenance could be less and provide greater agility for leveraging changing technology.

So the problem becomes two-fold:

1) Conform your business processes to the out of the box solution (or, in some instances, forego certain amounts of functionality when that solution just doesn't have the capability); or
2) Suck it up and live with the customizations you need to meet your mission and business process requirements.

I did this kind of development in the early 2000s (web-based front end customized apps to larger business back-end systems). One of the systems I was responsible for was an "in-the-building-only" system built up by 3 different guys in 4 different coding styles and development methods before my arrival, so I had a patchwork quilt of code to deal with just to maintain it. Then, one day, the sales guys in other offices discovered that this tool existed and they wanted in.  Then it was sales guys in Europe, Asia-Pacific, etc.  We always wanted to do a "clean slate" rebuild of the whole thing using more modern code (C#), modularization and with an eye toward maintainability.  Strip off some of the database layers, beef up security, change some data models for things, allow user access from outside our domain, etc.  Unfortunately, there was no corporate impetus to invest in the development time, mostly because "it worked, don't mess with it."

eServices has grown in leaps and bounds over the years, and with it applications to promote & laud our members, track our flying hours, etc.  When I retired in 2009, eServices was still pretty nascent. When I came back in 2013, it was *incredibly* more full-featured, and even in the last 4 years, its grown more.

If you want an interesting parallel, ask anybody in the UK Air Cadets about Project Bader sometime.

To clean-sheet the whole thing would be a pretty massive development effort.

Is there an "out of box" solution that does what eServices does? Think about all of the modules in there. What software package do you know of that does all that?

Yes, lots.

Let's step back and be realistic for a moment.  e-Services is not some super special wahzoo application that does something no one else can.  The fact that it has all these built out modules is part of the issue.  We're a volunteer organization operating on a limited IT budget.  Maintaining that crap is a nightmare, I'm sure. 

What do we really need e-Services to do?  It's a secure portal that houses membership information, general organization of resources/assets, professional development, etc.  There are many solutions out there that can do this.  Hell, SharePoint and Google Apps solutions can seriously handle 90+% of this need out of the box. 

What needs to take place is a true enterprise needs assessment with an openness to new approaches.  Would some of our processes need to change with a new solution?  Probably, but I'd argue in virtually every case that would likely be a very good thing.  We'll likely gain some functionality in the process.  The biggest obstacle in this is old guard who are slow to embrace the wheel of change.

Short term pain (minimal), long term gain.  I've done this stuff for a living for quite a while.  It's not secret squirrel.  It will take financial commitment from the organization (forego purchasing a couple new airplanes) and someone that can get leadership buy in.  They also need to be willing to put the effort in up front and follow it through to implementation.  Bottom line:  It needs to be a priority for the organization.

When to use Traditional vs. Agile methods:

	Traditional	Agile
Criticality is...	High	Low
Requirements change...	Rarely	Frequently
Team size is...	Large	Small
Team members embrace...	Order	Change

CAP's IT systems have high criticality, and infrequent requirements changes. The HQ team is small, and I have no idea if they embrace change. Agile seems like a poor choice for CAP, but I'll admit I don't have a complete picture.

Would not going back, clearing everything, and using (Google Aps, SharePoint) be more painful?

Not everyone here knows (Google Aps, SharePoint) so it would be nearly impossible to have something functional in about at least 6 months. Assuming the membership would like to start learning a new system. And new terminology. As (Google Aps, SharePoint) do not call every single module there the same as in e-Services. Getting to rename them would entail changing some of the code, no?

Believe me, we would be getting the same complaints we get from members about e-Services if we select GA, SP, Brand X, Brand Y, or Brand Z.

If it seems to be working, do not mess with it (other than fixes).

Would not going back, clearing everything, and using (Google Aps, SharePoint) be more painful?

Not everyone here knows (Google Aps, SharePoint) so it would be nearly impossible to have something functional in about at least 6 months. Assuming the membership would like to start learning a new system. And new terminology. As (Google Aps, SharePoint) do not call every single module there the same as in e-Services. Getting to rename them would entail changing some of the code, no?

Believe me, we would be getting the same complaints we get from members about e-Services if we select GA, SP, Brand X, Brand Y, or Brand Z.

If it seems to be working, do not mess with it (other than fixes).

With all due respect, the post above is a perfect example of the cogs of the machine that are difficult to change.

Do not confuse the tools used to create a solution with the user experience.  If done correctly, the impact to the end user, from a functional perspective, should be minimal.

My vote would be a custom web app which decouples UI from backend. Build the data system on a RESTful/JSON (though technically with RESTful you're supposed to support XML and JSON) API, then sit a UI on top of the API. You can interchange the UI design, or access the data programmatically, with no change to the backend - it doesn't care, it's just an API.

Then again, as I've found myself saying a lot lately, if I were king I'd have a way cooler hat.

What's worse? 1 year of hassle, or another decade of "planned but not implemented"?

"If done correctly..."

I saw this last in the Best 100 List of Well-Intentioned Phrases...

In Puerto Rico they say "Mas sabe el diablo por viejo que por diablo..." 

Rough translation by me, The Devil is Wiser since he is older, not because he is the devil... 

And I have seen a lot... 

It is seldom done, and often incorrectly!

 

My vote would be a custom web app which decouples UI from backend. Build the data system on a RESTful/JSON (though technically with RESTful you're supposed to support XML and JSON) API, then sit a UI on top of the API. You can interchange the UI design, or access the data programmatically, with no change to the backend - it doesn't care, it's just an API.

What leads you to believe this isn't the current system's architecture?