Snarkier, more truthful answer: "We're behind schedule and can't seem to ship, and one of the developers heard agile helps with that."
(Note: agile and scrum overlap entirely in my mind; I understand some people differentiate the two, but I use them as synonyms.)
Usually the core pieces of agile I hear used are (in decreasing order of actual use): 1. Work broken into short iterations/sprints (1-3 weeks). This alone is sufficient for people to claim they are being "agile". 2. Short daily stand-ups to report status and force engineers to talk to each other 3. Work decided ahead of time for the sprint 3b. Work sometimes changed mid-sprint, sometimes not 4. Work priority decided using "user stories"--Ship Value Early 4b. and possibly a Product Owner who knows what users want 5. Work difficulty estimated ahead of time using story points or the equivalent 6. Demo/ship every sprint 7. Development team given more control over how to do things 8. Development team expected to cross-train--implement features "depth-wise" rather than staying in their stratum of the system. (E.g.: developer is responsible for writing front end, glue, and backend for feature X) 9. Introspection after a sprint to figure out what happened, why, and how to improve it 9b. Use of introspection to improve the team's estimating skills
9b is, of course, one of the places that outside management can start to see value--which makes it frustrating when it's at the bottom. Improved estimates are a product of a good process but take some time to evolve...
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2014-02-05 10:57 pm (UTC)Snarkier, more truthful answer: "We're behind schedule and can't seem to ship, and one of the developers heard agile helps with that."
(Note: agile and scrum overlap entirely in my mind; I understand some people differentiate the two, but I use them as synonyms.)
Usually the core pieces of agile I hear used are (in decreasing order of actual use):
1. Work broken into short iterations/sprints (1-3 weeks). This alone is sufficient for people to claim they are being "agile".
2. Short daily stand-ups to report status and force engineers to talk to each other
3. Work decided ahead of time for the sprint
3b. Work sometimes changed mid-sprint, sometimes not
4. Work priority decided using "user stories"--Ship Value Early
4b. and possibly a Product Owner who knows what users want
5. Work difficulty estimated ahead of time using story points or the equivalent
6. Demo/ship every sprint
7. Development team given more control over how to do things
8. Development team expected to cross-train--implement features "depth-wise" rather than staying in their stratum of the system. (E.g.: developer is responsible for writing front end, glue, and backend for feature X)
9. Introspection after a sprint to figure out what happened, why, and how to improve it
9b. Use of introspection to improve the team's estimating skills
9b is, of course, one of the places that outside management can start to see value--which makes it frustrating when it's at the bottom. Improved estimates are a product of a good process but take some time to evolve...