Jason Heaster, Certified Scrum Master and Project Manager at CivicActions, and Marc Jones, Compliance Engineer and Attorney at CivicActions, present ideas on:
-
why the government’s approach to software procurement doesn’t produce the same kind of quality that users have come to expect today
-
ways for everyone involved to make changes that will help increase quality and work in a more agile manner
This session is geared toward both those in government who have to work within the confines of current procurement & contract rules, and vendors who want to work with the government in an Agile way but find the current system frustrating and constraining.
We’ll cover how the basic waterfall contract structure can cripple software projects from the start, and what kind of changes can be made to contracts so they encourage agile workflows rather than stifling them. If there is time, we’ll talk about a successful experience working with a large federal government client in an Agile way, even though the contract was waterfall in structure.
Outline:
-
Government contracts are old
-
Lawyers and governments are slow to change
-
Project management was invented about the same time as modern government contracts
-
-
The project management we invented looked like a contract
-
You layed out all of the requirements of the relationship in advance
-
Then you execute on them
-
-
Things have changed
-
For instance the internet is a thing now
-
And Toyota (“Lean Manufacturing”)
-
-
Effective organizations don't build software on waterfalls anymore.
-
Toyota taught everyone (except for lawyers) that we need to be more agile
-
-
Modern software is built in an agile way
-
Agile changed how we think about requirements
-
We don't know how many functions we will write or what those functions will do
-
We know the least about a software project’s needs at the beginning, so why try to write all the requirements at that time?
-
-
We do know what the business goal is
-
We generally have high level objectives
-
-
We do know what the budget is
-
We know we need to spend money responsibly
-
-
Contract define relationships
-
Good contracts are design to enhance success
-
Technology changes rapidly
-
You always need to hold people accountable
-
-
Agile defines rigged relationships
-
We hold each other accountable
-
We have defined roles
-
We have regular deliverables
-
We regularly generate metrics of productivity and success
-
-
Agile aligns available budgets with achievable goals
-
We define what the general mission is to make progress on it
-
We know what the budget we have is
-
-
Once we know our mission and our roles, we work together
-
We hold each other accountable throughout the process to make sure we use the money effectively
-
This is a better contract
-
There are real and regular points of accountability
-
You always have deliverables
-
You generate documentation required to get out of bad contracts
-
It is easier to switch vendors when you know they are bad vendors
-
You never waste time/money on material your customer doesn't care about
-
-
Accountability is easier
-
There is never an excuse for your sprint not ending at 2 weeks
-
There is never an excuse for not having deliverables at the end of 2 weeks
-
You know if you contracter sucks every two weeks
-
You know if the product is working every two weeks
-
You know if you should fire them every two weeks
-
You know if your customer sucks every two weeks
-
-
Your requirements get better as you learn more about the contract
-
You never are working on outdated requirements
-
You never take delivery of something old and useless
-
-
Ways to push forward in Agile contracts
-
Agile contract template
-