Staffwork to Scrum
By: Mark Peters
Traditional waterfall organizations face many challenges when beginning the transition to an agile or Scrum mindset. Some organizations attempt to change many parts simultaneously to maximize effort while minimizing resources. These notes summarize my lessons learned during our security team’s transition. Our team handles compliance requirements for the broader organization, ensuring all deliverables and products can be documented as secure. In the first nine months, our security compliance branch faced challenges handling traditional compliance staffwork from an agile perspective. The first challenge was defining the previous staff deliverables, evaluating requirements and then level setting expectations. The next challenge was understanding how scrum could advance our process without returning to waterfall practices. Finally, we had to decide which functions to adapt, combine or abandon to satisfy compliance goals. All this integration led us back to coordinating with the various multifunctional teams doing daily development and sustainment to maximize transparency for required compliance items. Throughout, we employed regular retrospectives to track progress and map future steps.
Everyone most likely has suffered through staff-work. The Vice-President, or C-suite executive, or even manager, gathers immediate subordinates in a room. Options are discussed, current actions are reported, future events are planned with varying difficulty levels, and several new projects are created with individual champions. Then those champions continue this telephone game, gathering their subordinates, and further dividing tasks. These subordinate groups may be called teams, they are frequently not, instead representatives of functionally divided responsibilities. Then, at a predetermined time, meetings progress in the reverse order, reassembling data at each level to present progress at more and more senior levels. And the chain begins again. The inability to define useful deadlines to manage value explains why many projects never end early, relying on late activity swarms to rush inferior tools across the finish line. Staffwork problems include persistent small blockers, ineffective work distribution, and functional silos within companies preventing cross-functional development. Generally, the inability to project deadlines accurately worsens as sizes increase and target dates drift further back from the current day. Late swarming alleviates some difficulties with overwhelming resource commitment to a single problem but creates additional problems for parallel tasks. This describes not only typical staff-work but traditional waterfall essentials and requirements. There is a better way.
My team handles cybersecurity compliance and was historically mired in staff-work. A recent shift to a more DevSecOps approach incorporating Scaled Agile For Enterprise (SAfE) meant we could again attempt overcoming these traditional challenges. First, we changed our security documentation mindset through implementing scrum practices based on daily stand-up, review, retro, planning and backlog grooming. We managed cycles through Kanban with the board columns as; Backlog, To Do, Requirements Review, In Progress, Mitigating, Peer Review, and Done. The primary task was to document security practices from a Risk Management Framework (NIST 800–53) for a higher headquarters review. The team conducted daily standups as well as a two week review-retrospective and plan cycle to manage progress. Once the schedule was set, next up was reviewing old staff-work actions for transition into a new format.
Staff actions were evaluated for adapting old methods to our new processes, combining new and old processes, or simply abandoning the old. Many issues arose and were discussed, for space considerations here, only one is highlighted from each category. For adaptation, old practices needed increased transparency. Previously, security documents were constructed and kept within structured communications as were any security meetings. Those barriers were broken despite keeping similar patterns and structures with all events posted on shared digital spaces including even the security scans (CVE, STIG and others). Adapting transparency combined old security delivery processes’ gargantuan tasks with newly packetized work broken out and tracked by Kanban board. RMF control sections were reviewed with each tracked as a separate task, highlighted indicator artifacts as individual stories attached to the overall requirement, and charted our progress. Tracking clearly visualized progress towards completing compliance paperwork. One critical note was the constant push shrink items to manageable levels, preferably not more than 3 days to complete any item. Finally, in adapting transparency, siloed delivery practices were abandoned. Previously, branches in development passed security staff-work to their seniors who tossed over to the security group after significant delays. Interacting directly to work the issues at the lowest level allowed us to accelerate solutions, fixing problems in days instead of months.
Our teams excelled with the initial process transition. Next up was considering the impacts on other release train teams. Key release train teams included development, engineering, lab, and shared services. Development and engineering handled coding and initiative development prior to coding, respectively. As a common community best practice, we highlighted security champions within these two teams. These were not assigned security team members but matrixed to advocate for critical concerns. The Lab team handled the development environments for dev, QA, and test from a single functional environment with logical divisions. Initially, Lab was under Shared Services then migrated to Security, three sprints into the first iteration. This migration consolidated logical development requirements with compliance documentation needs. Merging ensured comprehensive compliance during development and before production. Finally, one Security member always participated during other teams daily scrums. The two-way conversation between always present security champions and our regular integration increased overall transparency.
These changes lead to our current path. We intend to stay on this path for at least twelve to sixteen weeks, with minor corrections provided through the end of sprint retrospectives. Future requirements may change and require unique consideration. For example, automation often becomes the center of continuous integration and continuous development practices. Automating through a heavily compliant organization often requires additional staffwork, evaluation, and remediation which sometimes prove challenging to accomplish during the scrum/ sprint cycle. Further, even though a process becomes automated, coordinating multiple checks, and multiple tests, to verify accuracy tends to increase staffwork for some organizations. The challenge will be to maintain pace, and avoid falling back on old habits as workloads increase. Overall, our initial plan is running, the challenge will be to see what we can automate, and what we must re-engineer but I continue to look forward to the journey.
All of these thoughts and representations are mine alone. They do not represent either the company I work for nor the U.S. government. Also, no copyright infringement is intended or implied.
DevOps Institute is dedicated to advancing the human elements of DevOps success through the SKIL Framework: Skills, Knowledge, Ideas, and Learning. Learn more.
This blog was originally posted on DevOpsInstitute.com.
