Reviewing for content

Title: Reviewing for content
Type: principles
Status: final
Version: 2007-07-26
Gist: Conduct reviews in the right order.

P1: check formal characteristics
P2: only if the object is clean, it's useful to see if it's right

Optimizing subsystems does not help optimizing IT costs

Title: Optimizing subsystems does not help optimizing IT costs
Type: theory
Status: final
Version. 2007-07-26
Source: Chris Matts, Gilb Seminar, London, 2007

The IT world is misperforming when trying to optimize IT costs, because when one subsystem is optimized normally the performance of the surrounding systems decreases.
We have to optimize the whole.
At Toyota, they even optimized their suppliers (and customers?).

Same thing with single projects. Most of the time it is easier to solve a problem by means of thinking out side the box of this praticular project.

Go Agile, Enterprise Wide

Title: Go Agile, Enterprise Wide
Type: Rules
Status: final
Version: 2007-07-26
Source: Pollyanna Pixton, talk at APLN 2006, Gerhard Wohland, Niels Malotaux, my own thoughts

R1: make sure the individuals in the enterprise want to learn and are allowed to learned
- unleash creativity
- lead change (not adopt to change)
Note: since business is global now, you have to put pressure on competitors if you want to sustain and succeed. You cannot just follow, because your market share will be eaten up by others.

R2: prioritize: all decisions are based on business value
- what is the most valuable thing to do *now*
- change lubricant slogan: "take the fun out of being disfunctional"
- finding business value of new products: give the product away for free

R3: do cascading agile:
- Do a business-level roadmap cycle every 3-6 months. "Do the tactical objectives still comply to the enterprise's strategic plans?"
- Do a project-level tactical cycle every 1-3 months. "Does our business unit / project still comply to the tactical objectives?
- Do a delivery-level cycle every 2 weeks or less. "Are we moving towards the right product?"
- Do a task-level cycle every 1 week. "Are we doing the right things in the right order?"

R4: Iterate: Review Goals and Objectives
Principle 1: full transperancy, give all information to everybody
Principle 2: fail early, fail fast!

Being agile on offshoring projects

Title: Being agile on offshoring projects
Type: Process
Status: final
Version: 2008-05-13
Gist: How to implement agile across distributed teams.
Note: Keeping productivity in mind it is really not advisable to distribute teams. Expect half the productivity you could otherwise expect from a team.
See Agile Advice for tips on proper room design.

S1: produce a feature list
S2: Give the offshore team a tiny (2-3% of total size) bit of features
- prioritized based on business value

S3: write the test cases, give them to the offshore team

S4: use focus groups

S5: if the features are delivered, go back to the feature list and ask the focus group: do we have enough business value?

Leadership

Title: Leadership
Type: Principles
Status: final
Version: 2007-07-25

P1) Step aside and let your team members work
P2) Only do 2 things
- make shure everybody has what they need to succeed
- create a place where people want to be

Note: If your people are passionate about what they are contributing to your endeavor, THEY will work things out (better than you can). You just sit and watch!

Note: It is a leader's responsibility to protect the team from leaders higher up in the food chain, that are trying to dictate how to do things.

Good Practice in Writing Acceptance Criteria

Title: Good Practice in Writing Acceptance Criteria
Type: Rules
Status: draft
Version: 2007-07-15
Gist: To explain, how to produce useful acceptance criteria.
acceptance criteria (AC) DEFINED AS a means to express the important tests for a product or system from a behavioral point of view.
Sources: Dan North, Chris Matts, Dave Astels, my own practice.
Note: Writing acceptance criteria is not about specifying tests and not even about preparing for writing test cases. Instead, it's writing specifications of behavior.

R1: Use the standard form "given [Context] when [Event, Feature, Function] then [(expected) Outcome]".
R2: Write one AC for every single expected result. If you end up with more results per AC, try making the contexts more specific. Gist: By keeping the AC small and focused, they are easier to refactor.
R3: Don't just have one AC per feature, that says "everything turns out perfect". You need one per specific context.
Note: This rule seems ridiculously self-evident, but my recent experience while working with an "experienced" requirements analyst shows that it isn't...

Clear Conceptual Writing

Title: Clear Conceptual Writing
Type: Process
Status: final
Version: 2007-07-15
Gist: To explain how to amplify skills for writing information texts (not fiction or poetry). You can apply it to the introductory or explaining parts of requirements and design specifications.
Source: Michael Covington and my own experience.

S1: Planning: Decide what to write about. It's not important to have a very clear idea about the subject yet. It will evolve.
S2: Planning: Decide, for whom you are writing. if you don't know much about your audience, go and find out first.
Note: Writing is about transferring ideas. Although it can be used as a thinking tool for yourself (like this blog), it was invented to express ideas for others to read. Keep in mind that your writing tells something about you, whether you make it easy for you or easy for your audience.
S3: Planning: Every section has a purpose.
S4: Drafting: Write everything down. So you don't have to juggle with ideas in your head.
S5: Drafting: Concentrate on the what, not the how. It's okay if only you understand what's on the paper.
S6: Drafting: Get to the point. Say the main point of every paragraph in its first sentence, then provide the reasoning that leads to the main point in the following sentences.
Note: Mark Twain once said "Establish the facts first! You can mess them up afterwards."
S7: Revising: Make your text as easy to read as possible. Use someone who does not know about the topic to find out if it's understandable. Your kids or your gandparents should be able to understand what you say.
S8: Revising: Shorten your sentences. Then shorten them again.
S9: Revising: Think of ways how your sentence can be misunderstood, e. g. by reading it aloud several times and stressing different words in each pass.
S10: Editing: Fix the grammar, spelling an punctuation.
S11: Formatting: Keep it simple and standard, avoid meaningless variation.

Evolutionary Development, Waterfall and Change

Title: Evolutionary Development, Waterfall and Change
Type: Principles
Status: final
Version: 2007-07-10
Gist: Explain which conditions make a case for evolutionary development.
Source: Scott Selhorst on http://tynerblain.com/blog/2007/07/09/enabling-and-resisting-change/
Find a less brief description of Evolutionary Development here. http://kw-agiledevelopment.blogspot.com/2007/06/scrum-agile-development-uncommon-sense.html

P1: Evolutionary Development can very briefly described as:
Decide what needs to be done.
Do the most important things first.
Release the product incrementally as you complete items.
Re-evaluate and repeat.

P2: Waterfall Development can very briefly described as:
Decide what needs to be done.
Do things in an efficient sequence.
When finished, release the product.

Note: Kelly Waters descibes waterfall as: "Seeking to complete *everything* before releasing *anything*."

P3: There are at least 3 types of change where, if they occur, evolutionary development is better in handling than waterfall development.
Change in business needs (less frequent, large change each)
Change in requirements (frequent, medium change each)
Change in business rules (more frequent, small change each).

Risk and Uncertainty

Title: Risk and Uncertainty
Type: Principles
Status: final
Version: 2007-07-27
Gist: Provide a set of principles on how to tackle risk and uncertainty
Source: Matthew Leitch's Online Survey on 'Indivudual differences in risk and uncertainty management' (http://www.internalcontrolsdesign.co.uk/rumaresults/index.html)

P1: Objectivity and rationality are desirable.
P2: We usually face risk and uncertainty and need to acknowledge this and act in accordance with it.
P3: Focus on single future outcomes is usually at the expense of an objective view of the future, which requires a recognition of uncertainty.
P4: It is better to be honest.
P5: These considerations are very important and usually outweigh others.

Note: Sven Biedermann offers the notion of 'a project without risk and uncertainty isn't a project'.

Humbling Exercise on Estimation

Title: Humbling Exercise on Estimation
Type: Process
Status: final
Version: 2007-07-27
Gist: show the participants of the experiment that they are not very good at making estimates and not very good at knowing what the requirements for a solution are
Source: Niels Malotaux, Gilb Seminar on Decision Making, London, UK, 2007

S1: Explain the 'project': "multiply 2 numbers of 4 digits each, on paper". Every participant will conduct the project on his or her own.
S2: Ask for everybody's estimate, how long the project will take to be finished.
S3: Everybody shall measure the time needed, from reception of the requirements to delivery of the result.
S4: Give the requirements: "The numbers are: 4-5-6-7 and 9-8-7-6".
S5: Let them re-estimate.
S6: Interrupt them now and then by talking, because this happens to every project.
S7: Yot down the times needed.
S8: Ask if they have testet the result. Make them test their results and take the time again.
S9: Add the times and compare them to the original and second estimates.
S10: Show them a solution to very different requirements. Make something up, like changing the order of the digits.

Note: There are a couple of interesting questions to ask here.
Like "What does 'finished' mean?",
"What was the reason for the adjustment of the original estimate?",
"What was the impact of the interrupts?",
"Is it rational to forget testing, and why does it happen all the time?",
"Why were we assuming that we really understood the requirements?"

Reducing the size of power point presentations with pictures

Title: Reducing the size of power point presentations with pictures
Type: Process
Status: final
Version: 2007-07-04

S1: Right-Click on one of the pictures.
S2: Pick Properties.
S3: Click on Compress...
S4: Choose "all pictures" and a flavor of compression you like