pfctdayelise + agile   23

technology-budgeting/ at master · 18F/technology-budgeting
A handbook for state budgeting and oversight
August 5, 2019

By Robin Carnahan, Randy Hart, and Waldo Jaquith

18F, Technology Transformation Service, General Services Administration

Table of contents
Basic principles of modern software design
User-centered design
Agile software development
Product ownership
Building with loosely coupled parts
Modular contracting
Best practices for budgeting and overseeing tech projects
Think about risk in a new way
Procure services, not software
Beware the customized commercial software trap
Require demos, not memos
Hire tech talent in-house
Minimize the cost of change
Measure success based on iterative outcomes, not project milestones
Limit total spending
Limit contract sizes
Fund systems, not monoliths
Expand your vendor pool
Share your software
Budget for software as an operational expense
Ask technical questions of agencies
Appendix A: Questions to ask
Appendix B: Sample Quality Assessment Surveillance Plan
government  agile  softwaredev 
august 2019 by pfctdayelise
Stop Running in Circles and
Ship Work that Matters

by Ryan Singer

This book is a guide to how we do product development at Basecamp. It’s also a toolbox full of techniques that you can apply in your own way to your own process.

Whether you’re a founder, CTO, product manager, designer, or developer, you’re probably here because of some common challenges that all software companies have to face.
softwaredev  productmanagement  agile  book 
august 2019 by pfctdayelise
In test column - JitGo Jitesh Gosai Tester, Speaker, Presenter
A colleague recently asked me why I think the in test column is a bad idea. So I had a quick search around and couldn’t find anything specifically on the topic I decided to put some of my ideas down on why we shouldn’t have one and instead to opt for a more generic In Progress column.
agile  softwaredev  testing 
may 2019 by pfctdayelise
Agile Embedded Resources | Atomic Object
Agile Embedded Resources
We're Experts in Agile Embedded Software Development
We took a dare that Agile practices (particularly TDD and Continuous Integration) were impossible to implement in anything but desktop or web environments and languages like Java or C++. We ended up doing pioneering work to bring the value of Agile methods to embedded software development.

Traditional waterfall-like approaches have failed and fail more spectacularly as embedded systems become ever more complex. Go Agile with our resources below.
embedded  agile 
may 2019 by pfctdayelise
Tea-Driven Development :: Features != User Stories
User Stories are a planning tool. They exist until they’re implemented, and then they disappear, absorbed into the code.

Cucumber features are a communication tool. They describe how the system behaves today, so that if you need to check how it works, you don’t need to read code or go punching buttons on the live system. Organising your features according to the way they were planned and implemented is a distraction from this purpose.

Imagine if the user manual for your washing machine was organised by how the washing machine had been constructed? A nonsense.
bdd  agile 
april 2019 by pfctdayelise
Derek-Jones/SiP_dataset: SiP effort estimation dataset
The data is described in the paper: "A conversation around the analysis of the SiP effort estimation dataset" by Derek M. Jones and Stephen Cullum
agile  estimates  data 
april 2019 by pfctdayelise
Handling Non Functional Requirements in User Stories and Scrum | The Scrum Crazy Blog
Handling non-functional requirements in User Stories can at first seem difficult, but as it turns out, there’s a pretty easy way to handle them.

For performance requirements and many other non functional requirements(NFR’s), one can use constraints and stories. What I usually coach is to create a story to document the NFR and define story tests for it. Then, I suggest adding the story tests as a “constraint.” A constraint is something that all implemented stories(features and functionality) must comply with. If you’re using Scrum, then you’ll want to add something like this to your Definition of Done(DoD): “All stories must comply with all of the story constraints.”
agile  nonfunctionalrequirements 
april 2019 by pfctdayelise
Non-Functional Requirements: Do User Stories Really Help?
Agile software development relies on bringing business people and developers together to deliver better software. We understand requirements by building working software and seeking user feedback on whether the latest solution meets their needs. This enables us to deliver business value early and to improve software in subsequent development cycles.

Agile teams focus on identifying user facing features that can form the basis of incremental deliveries. Often these are expressed as User Stories, slices of functionality that enable a user to achieve a specific goal. Developers work closely with stakeholders to understand what user stories must be satisfied by the product that they are developing. A flaw in this approach can be that users don’t mention non-functional requirements and developers don’t push to understand what quality attributes the software should satisfy.

So how does a team make sure they don't lose sight of "non-functional requirements"? Are user stories of any use in making these special kind of requirements visible to the team? This article explores how teams applying agile techniques go about resolving these concerns.
agile  nonfunctionalrequirements  bdd 
april 2019 by pfctdayelise
Engineering guide to writing correct User Stories
Agile people are obsessed with writing user stories. And it is a powerful instrument indeed. But, from my practice a lot of people are doing it wrong.

Let’s see an example:

As a user
I want to receive issue webhooks from Gitlab
So that I can list all current tasks
Seems like a valid user story, doesn’t it? In fact, this tiny story contains multiple issues. And if you cannot find at least 8 mistakes in it - this article will be worth reading for you.

This article is split into three main parts:

Getting better with the default user story format
Rewriting user stories with BDD to make them verifiable
Linking user stories with tests, source code, and documentation
While some parts might look more interesting to different categories of readers, it is important for everyone to understand the full approach.
agile  bdd 
april 2019 by pfctdayelise
Open Practice Library
The Open Practice Library is a community-driven repository of practices and tools. These are shared by people currently using them day-to-day for people looking to be inspired with new ideas and experience.

To help navigate the Library, all practices can be visualised on a canvas based on the Outcome Delivery framework which has three parts:

Discovery - to generate the Outcomes
Options - to identify how to get there
Delivery - to implement and put your ideas to the test. Learn what works and what doesn’t.

These are connected with an infinity loop called Mobius. In addition to this is a foundation layer to capture practices providing culture & collaboration and technical engineering. These combined enable sustainable continuous delivery.
Our Mission

This Library is intended to be a wealth of knowledge on product Discovery and Delivery practices to be adopted and evolved by a positive, engaged and supportive global community.
productmanagement  agile  softwaredev 
march 2019 by pfctdayelise
How do we actually do design in agile software development?
From a software development stand point, this process works really well. However, from a design stand point, this goes against what you we’re probably taught in design school or learned working at an agency. Visual design is almost always done in a waterfall process. Waterfall is a sequential flow where you set goals or milestones up front. You start on your first milestone and don’t move onto the next one until it’s complete. Agile blows up this model and doesn’t follow a strict sequence of events. How as a designer do you work in this model? For almost 2 years now I’ve been working on an agile development team and I’ve learned a number of best practices which are outlined below.
design  agile 
january 2019 by pfctdayelise
Blog | Documenting Architecture Decisions | Relevance
Architecture for agile projects has to be described and defined differently. Not all decisions will be made at once, nor will all of them be done when the project begins.
agile  documentation  softwaredev 
january 2019 by pfctdayelise
Modern Agile
Esp Psychological Safety Cheat Sheet
work  culturefit  teams  agile 
june 2018 by pfctdayelise
Backlog/Roadmap Hygiene Tips – John Cutler – Medium
RT @leahbannon: a thing to read: Backlog/Roadmap Hygiene Tips – John Cutler – Medium
productmanagement  agile  softwaredev 
november 2017 by pfctdayelise

Copy this bookmark: