A screen/report prototype mocked up in Excel using hyperlinks to demonstrate navigation.
A very quick and easy way to get early feedback from end users.
If you spend more than a few hours on the prototype, you are doing it wrong. It is Muda after all.
My favourite analysis/learning tool is the business model. This is a diagram that shows objects/entities and the relationships between them. I use the crow's feet notation because it is easiest to intuitively understand (for me at least). The only thing I am interested in is whether the relationship is many to one etc. I do not bother with optionality, that's too much detail. I stick attributes and methods on the objects/entities as appropriate.
Typical bad smells I look for are:
1. Many to many relationships normally indicate a missing business entity.
2. When I cannot link two objects/entities through a valid set of business relationships, I know that there is a missing object(s)/entity(ies) and relationship(s).
3. Violation of 1st or 2nd Normal Form. As these are analysis and not design or implementation models I normally go to 3rd normal form.
Once again, these business models are for my personal use and understanding. They are not a deliverable although they may be useful to developers.
This is a question I often get asked. The answer is no.
A zero documentation approach means you do not intend to produce documents as your deliverable. Your aim is to coach not document.
You will still produce documents, probably as your own reference material so that you do not forget important facts. You may also produce coaching material. Finally you may be asked to produce compliance documentation. This should be less onerous if a number of people on the project have been trained in the material.
This could be regarded as Agile Analysis as very little analysis documentation is produced.
Simple answer. Spend time coaching rather than writing documentation. Its a much more effective use of time.
Documentation slows down learning.
Consider two scenarios. In the first the student is reading a document and they have a question. They have to wait until the coach is available to answer the question before they proceed. In the second, the coach is training the student. Feedback is instantaneous.
Metaphors are a very powerful teaching tool, however they only work if the metaphor is shared between the teacher and the student. If the student does not understand the metaphor, they are unlikely to grasp what is being taught to them.
Chose metaphors based on the personal understanding of the student, not the teacher. If the student cannot understand the metaphor, use another one. This instant feedback is another reason why coaching is better than documentation.
Of course metaphors can be reused but not at the expense of learning.
Think back to school. Personally I found the least satisfying lessons were those where the teacher got the class to copy or read a passage from a book. This is what we are doing when we use documentation to convey knowledge.
Once I realised this I then started thinking about the other styles of learning/coaching. These included discussions, worked examples, the teacher explaining at the white board (they were black in my day ;-) ) and homework. Homework was a way for the teacher to get feedback from the class on how well they had understood a subject. Distasteful as it sounds I think homework was where the real learning took place, it was all to easy to stop listening in class.
The Agile Business Coach should use all the coaching techniques available to them rather than focus on the one approach that is most likely to cause boredom and sleep.... documentation.
Knowledge is information with context.
This is why the Agile Business Coach focuses on training rather than trying to store 'knowledge' in documents or knowledge management systems. Training establishes the information in context.
Think of all the times you have been given a document to read that explains the 'requirements'. This document either has too much information, or more frequently not enough. Developers then program blind. The Agile Business Coach focuses on building a shared context with the developer and the end users of a system.
One of the most useful risk management tool in the financial markets is an option. It provides the ability to hedge exposures or to take a position in an instrument without fully commiting oneself.
Options can be used to manage risk on IT projects as well.
Rather than chosing a single path for the project, a number of paths (design decisions etc.) can be followed. With each option, it is important to understand when it will expire, i.e. it can no longer be exercised. The aim is to make decisions about your portfolio of options understanding when they should be exercised and when they should be allowed to lapse. At some point you need to commit to a single path, however options delay the date on which you need to fully commit to a single path. this means you will have more time during which information can arrive which may have a big influence on your decision as to which option to pursue.
The use of options is 'simple' in this case. First identify all the options available. Then for each option, calculate the cost of keeping the option available (known as the premium in financial options) and the date on which the option matures. Then track your portfolio of options making sure you make active decisions over which to exercise and which to discard.
The maturity date for an option of this kind is determined from the deadline and then working backwards to determine when the decision is needed by.
Making decisions early to give the apperance of progress reduces the number of options available. This makes managing the risk on the project harder.