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.