From 0b875b42ab01461552a12c60dd245c951e1b2701 Mon Sep 17 00:00:00 2001 From: Paulina Bustos Arellano Date: Fri, 23 Feb 2018 23:22:41 -0300 Subject: [PATCH 1/2] Update README.md Adding a couple of ideas on big ideas --- README.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 30566a2..e48e3bf 100644 --- a/README.md +++ b/README.md @@ -14,5 +14,19 @@ The old linear method of software development deals with change poorly. A key co ### Define the Problem, not the Solution First, define the actual problem. Rather than prescribing a solution, share as much as possible your understanding of the problem your agency is trying to solve. This could be: - CA residents are taking too long to fill out -- we have low engagement on our website -[TODO]: add more examples +- We have low engagement on our website +- Our users do not complete the process on time +- Our users' experience with the site is poor rated + +### Define metrics, not releases + +### Explain your current solution as a process + +### Provide dates + +### Describe the policies you HAVE to follow as CONSTRAINS + +### Allow for an open proposal with diagrams + + + From bd438994749cdc29e91eeb0bc8991bba3eca7090 Mon Sep 17 00:00:00 2001 From: Paulina Bustos Arellano Date: Sat, 24 Feb 2018 00:59:26 -0300 Subject: [PATCH 2/2] Adding rules Adding a couple of rules for real Agile Teams. --- README.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index e48e3bf..7159f48 100644 --- a/README.md +++ b/README.md @@ -19,14 +19,22 @@ First, define the actual problem. Rather than prescribing a solution, share as m - Our users' experience with the site is poor rated ### Define metrics, not releases +Real agile do not rely on arbitrary release dates but on iterations based on how the product is growing. To start a real agile process define metrics and based the roadmap moves according to those metrics. -### Explain your current solution as a process +### Describe your users +An Agile teams knows its users as they know themselves, provide user profiles and users references into the RFO. Team should be eager to know your users. -### Provide dates +### Explain your current solution as a process +Software never ends, it is a process that moves continously. Define the extension of your process and let the team explain how they will divide and conquer. ### Describe the policies you HAVE to follow as CONSTRAINS +Agile teams that work with governments know that there are laws and policies to follow. You should always describe them in your RFO and be sure to ask the teams to describe how they will tackle them. + +### Allow for an open proposal +Instead of giving a hard template for creating a proposal allow teams to use their formats. This will allow you to evaluate creativity in their teams. -### Allow for an open proposal with diagrams +### Ask for the development process and not specific roles +An agile team knows their team is as strong as their weakest member. Teamwork is important for an agile team and this should be represented in their development process. Don't ask for specific roles, ask about the tools and process used inside the team.