This article comes from the GSA Tech Guides. Very informative regarding differences between Agile and DevSecOps. https://tech.gsa.gov/guides/understanding_differences_agile_devsecops/

Time management is a common challenge for any team.  Timeboxing is a tactic to assign a fixed, maximum unit of time for a single activity.  Scrum teams can use timeboxing as an effective tool to concretely define open-ended or ambiguous tasks with strict time limits.  Click on https://www.scruminc.com/what-is-timeboxing/ to see a video and full content about timeboxing from Scrum Inc., and consider applying it to your next Scrum.

FCW reports that the White House’s Office of American Innovation (OAI) is seeking to establish “centers of excellence” on identity management and authentication, cloud computing, consolidated contact centers and data transparency and access.

A Request for Information was released by the General Services Administration on behalf of OAI says these centers would be staffed by a mix of federal employees and industry contractors.

Former Federal Communications Commission CIO David Bray says these areas of focus will help ‘improve the agility, resiliency, and effectiveness of what public service provides’.

While researching for whats new on Agile in Federal space, I found a really interested take on Agile practices by Feds.

Here are the excerpts:

There are a lot of teams out there saying they practice agile software development, when in reality they’ve just broken up their waterfall roadmap into two-week sprints (often called agilefall). This can lead to executives in government thinking “well, we tried agile and it didn’t help at all.” What they really tried is the exact same waterfall approach they’ve always been using with a slightly different vernacular surrounding it. This means really changing your team into an agile operation can be an uphill battle, because you have to overcome some of these initial biases (just listen to Tim Gribben, the CFO of the Small Business Administration, talk about how he’s not a fan of agile, but he acknowledges agile development was central to the success of the DATA Act implementation).

If you think you’re likely to face resistance from your leadership about trying an agile development approach, you can start out by asking your leadership questions like:

• How confident are we that we’ve captured all of the requirements up front?
• Do we anticipate any of the requirements may change after our initial planning phase? If so, how will we accommodate that with our team and/or contract?
• Are there some areas with lots of variables and moving parts (like legacy technology systems) where we can’t accurately judge the risk up front?
• Is it risky to pin all of our hopes and dependencies for this large project on one vendor?
• Should we schedule regular demos of the software with the vendor (instead of taking their word for it in status meetings) so that if things aren’t on track, we’ll know sooner?

Read more > 

Attached is the updated draft compiled GAO Agile Assessment Guide and the comment template.  The following is a summary of the changes/updates from the previous draft compiled guide:

• Chapter 3 has been updated based on our internal comment vetting sessions
• Chapter 8 (Agile Program Management) has been added
• Appendix 4: Common Agile Methodologies has been added
  • GAO currently have some placeholders for certain methodologies.  If you have additional information on these, we would love to include it in this appendix
• There are several new graphics
• The comment tracking information for each chapter has been updated based on our internal comment vetting sessions
  • Note: GAO have received 375 comments and have vetted 175.  We are currently at a ~75% acceptance rate as we go through the comments

GAO hope to publish this chapter as a technical appendix in an upcoming GAO report, and need to have time to vet and adequately address the comments received.  For the remaining chapters, there is no set deadline for comments. 

Next expert meeting will be on January 25, 2018 from 2-4pm EST at GAO headquarters (441 G St. NW, Washington, DC, 20548).  GAO’ll be sending out the official agenda in the New Year. 

Attachments:

 ALL_STAFF-#2226648-v4-COMPILED_EXPOSURE_DRAFT_FOR_AGILE_EXPERT_GROUP_REVIEWS.DOCX

Agile Guide Comment Input Template.xlsx

Agile development really just means continuous and incremental improvement. Don’t try to plot the three-year path of your product in one sitting. Instead, focus on steady and demonstrable progress on individual features rather than detailing every possible requirement up front. This refers not just to the product itself, but also to the team working on it. You need to regularly and honestly assess what is and isn’t working in your team, and continuously improve it (referred to as a “retro” in agile speak). Honest retros are so important that, in fact, I would hire someone with no discernible skills beyond active and constructive participation in retros over a “superstar coder” any day.

Read more >

The GAO was seeking ACT-IAC volunteers to serve on an expert panel to assist in creating a guide for auditors to use when evaluating agencies “agile development practices”. This guide will emulate the GAO cost and schedule guides.  It started the panel in August 2016 and the first meeting was held in August 2016. 

The guide has three primary objectives:

• Familiarize the reader/auditor with common terminology and practices in the adoption and application of agile software development
• Highlight structural barriers and other challenges that the reader/auditor should consider.
• Define a general framework against which an auditor can consistently evaluate the effectiveness of project control disciplines such as cost estimating, schedule estimating, systems integration & testing, requirements management, and project performance management in use for agile software development

 Additionally the guide will help auditors address issues like:

• What is “agile development”?
• What are the essential elements of an “agile development” program?
• Who should they talk to in an agency when evaluating an “agile development” program?
• What documentation should be available for review in an “agile development” program?
• What are high risk areas that should be considered in an audit of an “agile development program”? 

Individuals from government, industry and academia are welcome to volunteer to serve on this panel.

Qualified volunteers were needed to have the following skills:

• A strong background and understanding of “agile development”.  
• Technical knowledge and experience with IT and systems engineering

____________________________________

On May 4, 2017, after an Agile Expert Meeting held by GAO, Karen briefed "We had an excellent discussion of all agenda items and we very much appreciate all who participated and shared their knowledge with us. We are planning to send out a file towards the end of the month that includes draft chapters of the Agile best practices guide along with their appendices so you can see how our work is progressing."

Please see attached documents from the meeting:

• ALL_STAFF-2158289-v3-MAY_4__2017_.pptx
• ALL_STAFF-2158289-v3-MAY_4__2017_AGILE_EXPERT_MEETING_MINUTES.docx

Next meeting is scheduled for August 24, 2017 from 2-4pm at GAO Headquarters.

In July 2012, the U.S. Government Accountability Office (GAO) identified 10 practices for applying Agile software development methods to IT projects.

From the GAO report:

“The practices generally align with five key software development project management activities: strategic planning, organizational commitment and collaboration, preparation, execution, and evaluation. Officials who have used Agile methods on federal projects generally agreed that these practices are effective.”

10 best practices

1. Start with Agile guidance and an Agile adoption strategy.
2. Enhance migration to Agile concepts using Agile terms, such as user stories (used to convey requirements), and Agile examples, such as demonstrating how to write a user story.
3. Continuously improve Agile adoption at both the project level and organization level.
4. Seek to identify and address impediments at the organization and project levels.
5. Obtain stakeholder/customer feedback frequently.
6. Empower small, cross-functional teams.
7. Include requirements related to security and progress monitoring in your queue of unfinished work (the backlog).
8. Gain trust by demonstrating value at the end of each iteration.
9. Track progress using tools and metrics.
10. Track progress daily and visibly.

(Source: U.S. Government Accountability Office, Effective Practices and Federal Challenges in Applying Agile Methods)

Agile Software Development

"I've always seen the essence of agile thinking resting on two contrasts with traditional plan-driven software engineering." - by Martin Fowler

Credit & read more at: Cabot Solutions

Few more articles worth mentioning: 

Daily Stand-up – Dos and Don’ts

Effective Scrum Master’s Dos and Don’ts

The TechFAR Handbook highlights the flexibilities in the Federal Acquisition Regulation (FAR) that can help agencies implement “plays” from the Digital Services Playbook that would be accomplished with acquisition support — with a particular focus on how to use contractors to support an iterative, customer-driven software development process, as is routinely done in the private sector.

You can also download the handbook as a PDF file or .DOCX document

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

That is, while there is value in the items on the right, we value the items on the left more.

- agilemanifesto.org