October 13, 2003

Agile Business Coach Principles

These are the work in progess principles of the Agile Business Coach

Principles

The Agile Business Coach role is based on a number of principles. They are listed below. Grouped into the categories of Why, What and How.

The first thing we established is Why do we have a Business Coach. We then established What the Business Coach should deliver. Then we focused on How. Finally we specified what the role does not do that the traditional business analyst might do.

Our original articles were about What and How. The Why is the most important question of all.

Why do we need a Business Coach?

1. To coach the Business in how to identify and model business value and ensure that it is linked to the strategy of the organisation.
2. To coach the Business and IT Team to ensure the frequent delivery of Business Value.
3. To find information about the project before it would naturally emerge. The Business Coach is a project risk management tool.

What does Business Coach do?

1. They establish a trusted relationship between the business and the IT Team.
2. They coach the business and IT Team in how to identify and release Business Value.
3. They seek to remove waste. (The Business Coach is a Muda evangelist).
4. Focus on finding possible problems that might affect current decisions.
5. They extract themselves from the project as soon as possible leaving behind knowledge and trusted relationships.

How does the Business Coach achieve this?

1. By acting as a knowledge agent.
2. By learning about the business.
3. By coaching the business and IT Team.
4. By delivering zero documentation.
5. By providing barely sufficient deliverables.
6. By setting the project up for success. This is done by getting the business users to specify the expected test results that can be automated before the solution is developed.
7. By working in pairs on all thinking activities.
8. By attempting to break models rather than proving them.
9. By actively pushing knowledge and seeking feedback as confirmation.
10. By creating knowledge (trained people) rather than information Documentation.
11. By seeking negative rather than positive feedback.
12. By eliminating batches anywhere they are to be found.
13. By specify the scope of a project by what business value is AND is not to be delivered.
14. By focusing effort scoping the edge of the project rather than the middle.
15. By using whatever tool works.
16. By reflecting on progress and review the approach on a continual basis.
17. By refusing to deliver anything that does not reault in the delivery of business value.

What a business coach assists with but does not do (and who should do it):

1. Estimate effort. (Developers)
2. Identify Constraints and Takt Time. (Project Manager)
3. Write user acceptance tests. (Business Users)
4. Write system tests. (The IT Team, namely architects, designers and developers)
5. Run system or user acceptance tests. (Testing Team).
6. Track progress against the plan. (Project Manager).
7. Report Progress. (Program Manager)
8. Buy the pizza. (Project Manager)

Posted by chrismatts at October 13, 2003 10:04 AM