Pending Changes - Sprint Item Status?

What is being done to bring CAB approval and security competencies within the Development Team so it becomes adequately cross-functional?

A few things stand out to me.

First, why are you planning work for a Sprint that isn't ready to start right away? I understand the need for change control and approval, but is there a reason why the approval to make a requested or desired change can't come before a Sprint begins? I believe that this would give you more predictability in your work - if you bring in more planned and approved work, you can be sure that you can actually efficiently start work without unexpected delays from outside of the Scrum Team.

Second, why don't you have a "true duplicate" of your production environment? I can see this being extremely beneficial. Your team can execute the work, test the work, and give confidence to the various change control processes that, when rolled out to production that things will work. You can further decouple your Scrum Team's execution from the change control process and start work that hasn't been approved yet, verify and validate that your understanding of the problem is correct and the intended solutions will resolve the problems, and then roll it out to production after satisfying the change control process.

I don't think that problems that you are facing are problems with Scrum, but your environment and the broader organizational processes. My recommendation are to solve those two points that I mentioned above. First, establish a true copy of production that you can use to develop and test your solution, giving a higher level of confidence to stakeholders. Second, be able to plan based on work that is already approved and ready to go - and this can be easier if you can perform better testing and feedback loops prior to rolling it out in production.

Thomas, 

The bulk of the actual "work" part for the security items is really investigating to see if the item is false positive, and researching the options for hardening the CI in question. The work that's being performed in the change is usually something simple like updating a GPO, or checking a box somewhere. 

So its normally ~2 hours research ==> 3 days pending CAB ==> 5 minutes configuring

We'd love a test environment and are actively pursuing that, but until we have that we have to work in the world we live in. Most of our work can be tested in the test environment we have, but some of our border elements are more difficult to duplicate. 

Ian,

I don't know if the CAB folks can give us a resource to achieve cross functionality. I think the closest we could come would be achieving a standard change template that might allow us to fast track some of our changes, but I don't think they'd go for that of our use case is as broad as it is for these security items. Is this something you've seen on other teams?

I'm going to give the age old response of "do what makes sense for your team".  There is nothing in Scrum that says anything about what statuses to use on a Sprint Backlog Item during the Sprint.  Workflow is entirely up to the people doing the work to decide.  We could all give you some opinions but in the end, the only answer is "what makes sense for your team".  

I'll give you my opinion.  Blocked is not accurate.  You have an identified workflow and it seems to me that the CAB period of that workflow is review not blockage. My definition of a blockage is something preventing you from doing something that you know needs to be done. Since the CAB approval is required before you can make the change, the change is not a "known".  At that point is a "suggested" change. So I'd suggest something like Review or Pending Approval because it seems more accurate to me. 

So its normally ~2 hours research ==> 3 days pending CAB ==> 5 minutes configuring

The way I read that statement is "2 hours of discovery==> 3 days pending stakeholder feedback ==> 5 minutes work".  So I'd suggest that it be done outside of the Product/Spring Backlogs and when the work is finally identified as being needed, you just make the change.  Is it really worth the overhead of tracking it as a Sprint Backlog Item?  Do these changes have any impact on the potentially releasable increment of product functionality that your Sprint Goal is leading you to create? You can still use a ticket in your tracking system to have documentation. But unless it is truly a change made in order to deliver value to your stakeholders I'd question whether this is a Product Backlog item.

The bulk of the actual "work" part for the security items is really investigating to see if the item is false positive, and researching the options for hardening the CI in question. The work that's being performed in the change is usually something simple like updating a GPO, or checking a box somewhere. 

So its normally ~2 hours research ==> 3 days pending CAB ==> 5 minutes configuring

We'd love a test environment and are actively pursuing that, but until we have that we have to work in the world we live in. Most of our work can be tested in the test environment we have, but some of our border elements are more difficult to duplicate. 

What you describe as the bulk of the "actual work" strikes me as more closely aligned with Product Backlog Refinement. In Scrum, you would allocate ~10% (but there's no defined timebox or maximum time to spend in refinement) of your Development Team's actual capacity for each Sprint to this type of work.

If what you describe is that most of the work is research and then a trivial change, then I'd question whether Scrum is appropriate for your type of work. I do still see the benefits in having one or more test environments that mimic production to give you the opportunity to test your changes and demonstrate that they are correct, but it seems like tracking this type of work as a Product Backlog Item and creating and managing Sprint Backlogs is adding unnecessary overhead.

I don't know if the CAB folks can give us a resource to achieve cross functionality. I think the closest we could come would be achieving a standard change template that might allow us to fast track some of our changes, but I don't think they'd go for that of our use case is as broad as it is for these security items.

What else might be done to bring CAB approval and security competencies within the Development Team so it becomes adequately cross-functional? What about having security champions on the team for example, and observing a release-quality Definition of Done?

Is this something you've seen on other teams?

I usually only find cross-functional teams and release-quality Definitions of Done where there is sponsorship for deep and pervasive organizational change.