Defining Agile at Your Firm (or in your Department)

The Idea (or the Practice)

Let me propose an idea. I am happier if you call it a practice.

The idea is simple.  That agreeing on what you are doing will help.  Or, that not agreeing and only kinda sorta roughly trying to do [agile] is likely to lead to notably less-good results.

And I am not proposing a draconian “Thou must do Agile with absolute purity as defined by Gods 6000 miles away!”.  Not at all.

But I am suggesting that by talking about it, thinking it through, and roughly assuming that people in roughly the same situation should do agile roughly the same way…..that that will help.

It will, especially, be less confusing to relative beginners (that is, those who have only been doing “pretty good” agile for 3 years or less).

It certainly should lead to some good discussions about “what is the best way to do things around here”.

Getting Started

OK, say you have a group of 50 people.  Gather your 7 “best” people.  Include some managers, some coders, some testers, maybe a ScrumMaster or two, maybe a Product Owner.

Note: I made some assumptions. You are doing software. And your firm is trying to be at least Scrum-ish.  Also, this is not the only way to do this exercise.

OK, start defining agile for your teams.

Here’s what you might come up with.  (Lots of really good discussion as you agree to each item.  Agreeing on these might take some time.)

This is an example list. (For your specific situation, I might propose a notably different list.  You must decide, although starting with standard things until you give them a good experimental try is not a bad policy.)

Principles

1. Agile Manifesto (4)
2. Agile Principles (12)
3. You have to go slow to go fast
4. Fail fast, learn fast
5. It ain’t over ’till its over (eg, a story must have zero bugs before done)
6. The bad news does not get better with age (it gets worse)
7. More honesty, more truth, more transparency
8. Minimal viable product.  We’re shooting for 80-20. (80% of the BVPs can be done with 20% of the SPs.)
9. Increase Happiness metric.
10. Double Velocity in 1 year.
11. Quality (in every dimension) cannot go down.
12. WIP. Minimize Work In Process.
13. Single piece continuous flow.  In the sprint, AMAP.

Roles

1. That Scrum Team size normally = 7
2. Product Owner. 100%
3. ScrumMaster. 100%
4. Doers.  Coders, testers. 100%.
5. Managers and team agree team set up for success, enough
6. Business stakeholders (BSHs) – 4 people.  15% available. Right people. Will attend every Sprint Review.  Are appropriate to give fast and complete feedback on details in Sprint Review (or will bring a SME).
7. Chickens.  Always identified at beginning of project

Meetings

1. Sprint length = 2 weeks
2. Always do a Low Grooming (aka pre-planning) meeting before SPM.  All stories “good to go” per Team based on Ready-Ready Criteria.  All stories small, about the same size, and at least 8 stories. All stories have SPs (before going into SPM)
3. Sprint Planning Meeting.  BSHs attend first part. Max 4 hours total.  All tasks less than or equal 4 hours.
4. Daily Scrum.  Less than 15 mins. No disruptions. Team feels this enables them to self-manage toward success. (That is, the meeting is for them.)  SM and PO also answer 3 Q’s. Everyone is honest. People help each other.  Everyone admits to a biggest impediment. They even say “I sucked yesterday…. because I don’t know how to do that kinds stuff in Java.”
5. After-Meeting. Usually we have an after-meeting (after the DS). And ~3 people stay to discuss the biggest impediment
6. Sprint Review. 10 min Review. Mostly Demo. Roman voting by all. Most discussion is about those that are “close”, which must be fixed next sprint. Cheers when everyone is thumbs up on a story. All BSHs attend and are useful. Virtually zero “I will get back to you on that”
7. Retrospective.  Whole scrum team attends. Short bitching and moaning.  Short SM report (has to show some results).  Expect improved Velocity each time.  Mainly work together to fix top impediment
8. High Grooming Meeting. Team meets to break down stories and re-org PBL based on new info (eg, new SPs and new BVPs, or new stories)

Artifacts

1. Product Backlog (PBL). Goes out 6 months. Mostly stories. Everything in current release must be “sprint-sized” (8+ stories in each sprint). Stories in at least 1st and 2nd releases have SPs.
2. Ready-Ready Criteria.  We have them. We know how to use them.  The Team feels like they are set up with all the info they need to be successful
3. Sprint Backlog (SBL). Stories and tasks
4. Scrum Board. SBL becomes Scrum Board.  Backlog, In Process, To-be-tested, Done. A kind of flow in a Kanban Board. Visible to all in the Team Room
5. Sprint Burndown Chart.  Team updates data daily. Team uses it to self-manage
6. Release Burndown Chart. Team updates data each sprint.  Team uses it to self-manage
7. DOD. Definition of Done. Stronger now. Zero bugs, more testing
8. Working product.  Almost always all the stories are potentially shippable product increment by the end of the sprint
9. Impediment List. The top 20 impediments as of now.  If we fixed a half or third of them, we would double velocity

Metrics

1. Business Value. [Should be several metrics, and they vary a lot.  We’ll give one example now that fits some situations.]  Within 6 months, we expect unique visitors to increase 20% as a daily average over a week
2. Business Value. We will use BVPs (voted by our experts, the PO and BSHs) to improve BV delivery
3. Velocity. Average over last 3 sprints.  Expect to double within one year at least.  (Do not expect as much improvement once they get to 5x of initial baseline.)
4. Happiness metric per Jeff Sutherland
5. Quality. Adhere to new coding and technical standards. Goal: Zero bugs escape the sprint.  Legacy bugs: reduce by 5% per sprint. Legacy bug list to zero within 20 sprints
6. Hours. No more than 45 hours per week.  No over-working at home; minimal working at home

Key Execution Points

1. Stable team. We work hard to motivate the Team and keep the Team together and stable
2. Real Team. The Team will be better if they all commit. Help each other.  Become more multi-functional. No one is equal, but everyone can contribute. “All for one and one for all.”  The magic of the Team cannot be clearly explained
3. Motivation. Autonomy, Mastery Purpose.  PO expected to inspire the Team (AMAP)
4. Team Room. Most teams will be collocated. Collocated teams will have a Team Room.  Team members expected to be in Team Room > 4 hours per day
5. Self-manage. Team is responsible for full success.  Full success with everything considered. And to act like adults and use common sense
6. Ask for help. Team is expected to ask for help on some things
7. Fail Fast. Team is expected to make mistakes and learn from mistakes.  Faster
8. Changing Plan. The plan MUST change every sprint.  More accurate.  In general, we want the plan to become better AMAP, that is, usually “deliver less sooner”.  Like Lean Start-up; learn and pivot
9. Managers. Servant leaders. Managers are essential.  Can offer help. Must intervene if the team will fail. Usually encouraging the team to self-organize and self-manage.  A (local) Manager manages 4 teams
10. Budget for Impediments. Every team gets 10% of team cost to spend to fix impediments. We expect at least a 3x return on that investment.  Team and (local) manager are responsible for ROI on that investment over a year
11. Higher innovation. A key goal is faster learning and higher innovation. We assume all of us must work together to make that happen
12. Customers. We assume the customer feels the pain.  We assume that customer is usually bad at diagnosing the root cause. We assume the customers are usually bad at identifying the root cause problem.  The customer (with our persuasion) is the final authority on whether the problem was fixed the right way. The customer prefers something now rather than a LOT later. Delivering something wrong now is better than delivering something “perfect” later.  The bad news does not get better with age
13. Shut-up and Drive. The worst decision is no decision. Better a wrong decision now than wait (endlessly) for a perfect decision. BUT…a few decisions deserve careful thought.
14. We want emergent leadership
15. Delivered BV faster is more important than the efficiency of each team member.  We must have some slack to get speed

***

Comments

This is an example list.

Your list will be different.  First, you might want to take this and make it better or more.  Or different and maybe less.  Also, often they won’t agree to it — better to get them to agree and then do it.  Then make it stronger later.

Second, your situation is different, or where your team is now is different.  So, this list might be inappropriate, at least in part. Or, as suggested earlier, the politics of getting them from where they are to a specific place would be too hard.

BUT, they will have agreed on some list.

Was that list implemented in a draconian way?  No.  They agreed to it.

In your larger group, there is at least the possibility that one or more teams is special.  A specific team needs something different or at least a bit different.  You must have a way to accommodate these difference, without letting down standards completely.

Let’s be fair.  Some of these things I proposed will cause some people to push back.  They will see it as a threat, they will object to the transparency, they will feel threatened.  And they (some of them) will just not understand (yet).

Still, some of the push backs will likely to be fair and appropriate.

So, have a small group of people (agile coaches) who deals with each special case.  If the proposed changes are ill-advised, the reviewers try to talk the team out of it.  And the reviewers can make some changes legitimate (as well they may be).

***

If you implement this, it is work. But it will help.

And “agile” will not be just a tick box.

I think this will lead to great conversations that enable the teams to get more benefits from lean – agile – scrum.

« « Inhouse Courses and Workshops || What to fix first? » »