Lean Documentation in a Federal Government Context: How an Agile team can meet mandatory Federal IT governance documentation requirements
Many Federal government agencies are implementing Agile methods in addition to or in lieu of traditional waterfall lifecycle models. However, comprehensive documentation is often still required by Federal IT governance, legal, regulatory, or statutory frameworks, or to meet outside audit or “watchdog “ requirements. The Agile Manifesto values “working software over comprehensive documentation,” but that does not mean that Agile teams cannot or should not produce valuable documentation. Although there are some well-publicized Agile success stories in the federal space, some agile federal projects are receiving criticism for failing to meet applicable standards when it comes to documentation deliverables. With Agile’s emphasis on small, lean teams and intensive technical practices such as pair programming, meeting documentation requirements set forth by Federal IT governance poses challenges for Agile teams in the Federal space. This session will review the documentation that is typically required in a heavily regulated environment, and discuss specific techniques for reducing, replacing, generating, or “slimming” the document deliverables. Specific tools, techniques and best practices will be reviewed and analyzed with “before” and “after” snapshots and a look at cost versus benefit. Documentation generation is an area of intensive activity with some very exciting new developments that can change the game significantly for the better! Tune in to share insights and discuss strategies for breaking down one of the last big barriers to significant agile adoption in the federal space.
Outline/structure of the Session
- What are the document deliverables required by typical Federal Government IT governance?
- Management plans
- Technical documentation
- Configuration management
- Test documentation
- Release documentation
- End-User documentation
- Management Reporting
- What is the Agile approach to documentation?
- Working software over comprehensive documentation
- What does CMMI and PMBOK have to say about documentation?
- Process tailoring
- Template tailoring
- Solution: change the process
- Recognize documents a first-class work items, with their own user stories added to the backlog, and get peer review just like code
- Document as-is state rather than to-be state
- Document in real-time during conversations (whiteboard, wiki)
- Track and report percentage of time spent on docs, make it visible to the customer
- Update technical documentation as part of the “definition of done” for each user story
- Strive to capture information in one and only one place: single-source information. Either reference it or generate both documents from a single source
- CMMI and PMBOK both allow for template customization
i. Create more agile-friendly templates for technical documents
ii. Combine documents where possible
iii. Refactor documents in order to segregate docs with high level information that changes slowly from docs with all the details that need constant changes
iv. Decide carefully when to add a new document versus add to an existing one
- Replace documents maintained by hand with generated reports wherever possible
- Customized work item tracking system
- BDD toolkit: Specification by Example
- System Management tool
- Information Radiators for the team
- Management Dashboards to reduce reporting requirements
- Generated Tech Info: Design Diagrams, Code Comments
- Add a QA/tech writer to the team
- Add a toolsmith who is an expert at generating reports from your management tool. This person should have skills such as SSRS, HTML, XML/XSLT, SQL, SharePoint
- Add a UX designer to the team to help design the generated reports
- Review of Examples
- Refactored design document
- Functional specification generated from SpecFlow BDD toolkit
- “Agile RTM”
- Asset Tracking report generated from system center
- Installation documentation generated from PowerShell and wiki
- What we started with
- What we ended up with
- Estimated savings
- It is possible to adopt Agile in the Federal context and still meet standards of IT governance
- We will review specific techniques for streamlining documentation
- We will review new technologies and toolkits for generating documentation
- We will identify the roles required to make the transformation successful
- We will explore cost vs benefit for recommending agile alternatives to traditional handwritten documentation. Where does it make the most sense to push back? We must pick our battles carefully.
Federal managers, project managers, contract officers, vendor managers, technical leaders, QA practitioners, software engineers
schedule Submitted 2 years ago
People who liked this proposal, also liked:
3 Techniques to Raise the Communication Bar on your Agile TeamAndrea
schedule 2 years agoSold Out!
Project success = f (listening, feedback, intentionality, practices)
To make your agile practices and processes come to fruition, you need to cultivate an environment that promotes listening, learning, inquisitiveness, intentionality and top notch feedback that everyone is comfortable with.
Agile projects succeed when there are frequent high-quality reinforcing feedback loops. I will share communication models based on Clean Language questions of David Grove and the Systemic Modelling techniques of Caitlin Walker that can greatly increase clarity, sense of purpose and listening skills within your team and collaborative endeavors. These include: Clean Questions, Clean Feedback, and Clean Setup.
This is a hands-on, try it out, concrete practice session.
How much testing is enough for software that can condemn a man to death? Traceability in an Agile Federal Government Agency ContextCraeg K Strong
schedule 2 years agoSold Out!
Using tools like TDD and ATDD, Agile provides the means to be confident that your brand new software is well tested-- even for life critical situations such as criminal justice software. But hold on a minute! It is a rare mission critical system that is built completely from scratch. There are always legacy components your team didn't build or doesn't control. Maybe the previous contractor built it-- but now they are gone and it is your problem. How can you be certain that everything functions properly in such a situation? How much testing is enough? How can you know whether a system has been tested? These are the questions that standards such as CMMI and PMBOK seek to answer with traceability.
The debate about traceability has been raging for a long time, with passionate advocates on both sides of the argument. Projects following traditional waterfall methods, and projects that conform to PMBOK or CMMI standards often create and maintain a requirements traceability matrix, or RTM, a document that traces “shall” requirements to functional capabilities and testcases. Some Agilists argue that the RTM is rarely consulted in practice, so the significant efforts required to maintain such a document are “waste.” Others point out that agile practices such as TDD provide all the traceability that may be needed. This talk will explore the underlying reasons why traceability may be important and worthwhile in many Federal government contexts, and review exciting new technologies that may provide an “agile answer” to this conundrum.
Agile Testing: Guiding Principles and Enabling PracticesRaj Indugula
schedule 2 years agoSold Out!
Despite the belief that a shared context and collaboration drives quality, too often, software testers and quality professionals struggle to find their place within today's integrated agile teams. This session is a practitioner’s view of testing and testing practices within an iterative/incremental development environment. We will begin with a discussion of some of the challenges of testing within an agile environment and delve into the guiding principles of Agile Testing and key enabling practices. Agile Testing necessitates a change in mindset, and it is as much, if not more, about behavior, as it is about skills and tooling, all of which will be explored.