Using a “Definition of Agile” in a Large Corporation

Fairly often a large corporation will mandate Agile. One thing to consider is Open Space Agility — more on that before and later. For now, I want to suggest a “Definition of Agile.” This is vaguely similar to the Definition of Done concept.

The idea here is that often teams will… make up what Agile is, or at least get “rather creative” in doing “Agile,” and doing a lot of things that any coach would not like.

So, we strongly recommend that any large corporation (or organization) have a good set of internal and external coaches. These coaches must be really good. (We won’t explain why now.) CTCs and CECs are excellent choices, but there are other good coaches (and there are lots of “not so good” coaches, too).

Some groups of people (about seven) get together and discuss the minimum definition of what it means to be an Agile team at XYZ corp. Then, to be a Agile team, you must at least follow that minimal definition.

A team can be exempt from certain requirements of that definition, but only after getting approval from an Agile Center (or whatever your firm calls it). That is to say, after coaching from one or two of the best coaches you have. Why? So that someone knowledgeable explains why many of the things that they may want to be exempted from have a very good basis for being there, or that they misunderstood what it meant, or that someone badly implemented “it” (e.g., the Daily Scrum).

It is necessary to have some exemptions.  Any good sized fir will have special teams that have special needs, and therefore it may be advisable not to do some of the things in the minimum definition of Agile, but it will likely only be special teams. But any team can ask for an exemption.

Let’s give an example of a possible minimal definition of agile at firm XYZ.

1. They must have a real team. (Defining a “real team” might take some time.)
2. A team will be six to eight people in total (including the PO and SM).
3. All members of the team must be full-time. That includes a full-time PO and a full-time SM.
4. Obviously, each team member should feel that all the team members are reasonably competent at their jobs. Any concerns should be discussed immediately.
5. The team will be supported by a small set of “chickens.” In the beginning of the effort, the team must assess whether the identified chickens should be good enough for success. This includes, of course, whether the chickens have been allocated a sufficient amount to this team’s work, and are not otherwise too “distracted.” Any concerns must be identified quickly, but might not be apparent until later.
6. The Implementers are expected to try to be as multi-functional as they can be, and to become more multi-functional over time.
7. The Sprint will be 2 weeks.
8. All four standard Scrum meetings will take place as per rules in the Scrum Guide.
9. The team will have two burndown charts: Sprint BD and Release DB.
10. The team will have a Velocity in Story Points.
11. The team will actively try to learn how to become reliable in committing to its stories in the Sprint Planning Meeting.  Reliable means that seven or eight sprints out of 10 they get at least as many Story Points of work done as they commit to.  And, the team is expected to have fewer story points done in two to three Sprints out of 10.
12. The team will learn to become more reliable in estimating using Story Points.
13. The team will have an Impediment List.
14. The team members will normally work 40 hours per week.
15. The firm will have a budget of $X to assist in removing impediments.
16. The team is expected, mainly through the SM, to double its Velocity in the first year by removing impediments. Something should be improved every Sprint, normally. The team may not increase Velocity by working harder.
17. The team will have a Happiness Metric (see Jeff Sutherland’s blog), and it is expected to increase. If the team is not having more fun, they are not doing Scrum (and XP) right.
18. The team is expected to add XP practices quickly.
19. The team is expected to build 80 percent of the new functional tests as automated tests.
20. The team is expected to release faster. This is largely the responsibility of the PO, but the whole team must support this. Exactly how much faster (compared to the past) will vary by team, product and release. But in general, for this firm, about 2 times as often per year.
21. The team is expected to deliver more Business Value per time period. Each team will measure business value after the fact. The ABC team will review your expected measures and help you design an approach to measuring them after the fact. These measures may include measures of customer satisfaction.
22. Each team will have four “business stakeholders.” (More or fewer must be approved.) These Business Stakeholders must be at least minimally competent at the start, so that, in the Sprint Review, they can give a useful opinion of the Business Value delivered with each story, and provide complete feedback in the meeting about all the changes necessary to any story that is not “good to go.” (If a story is totally wrong, BSHs can defer the details until later.) We expect the BSHs to become more competent with time.

This is only an example. Hope this helps you. Feedback is always welcome!

« « Is the PO full-time? || About the New “Path to CSP” » »