Hyper-Productive Teams

The Agile Engineer Ryan Shriver has stunning news from the productivity front. After he 'produced' a whopping 1.750 attendees for his webinar on the topic, he was kind enough to share the presentation slides and a companion article. I quote from the article:

Hyper-productivity describes a state of being where teams are working at much higher levels of performance such as two, three and four times more productive than their peers. 

The interesting question for agilists and other method-interested people alike is: How can I do it? Well research shows than hyper-productivity seems to come with a couple of practices, all to be found in Ryans slide set and article. Be aware, don't get trapped into the logic than you only need to follow these practices to be hyper-productive.
I'd like to highlight one theme here, and Ryan probably says it best (mark-up is mine):

[...] the difference with the hyper-productive teams is their ability to stick to the practices over the project while continually removing impediments limiting performance.  

This resonates quite a bit with something Eric Ries posted about a startup lessons learned conference, in which Kent Beck happened to develop another manifesto, apparently (mark-up is mine):

Team vision and discipline over individuals and interactions (or processes and tools)

Validated learning over working software (or comprehensive documentation)

Customer discovery over customer collaboration (or contract negotiation)

Initiating change over responding to change (or following a plan)

I wouldn't go as far as calling this the new agile manifesto. This is more a set of paradigms for startups, so one could call it a startup manifesto ;-).

Writing Many High Quality Artefacts - Efficiently

I finished a process description on writing many artefacts, like use cases, requirements, book chapters, test cases, in high quality with the least effort possible. Please have a look, I'm eager to see your comments. After all, it's a Planet Project wiki article, so if you feel like it, just edit.

This, again, is on evolution, or learning by feedback. Makes heavy use of inspections. Inspections BTW, are one of the most effective QA methods known in software engineering history, according to metrics expert Capers Jones.

Extracting Business Rules from Use Cases

A while ago I posted a process for Extracting Business Rules from Use Cases, on this blog and on PlanetProject. I'm proud to announce an article on the very same subject. While the original form was quite condensed, the new version has more background, and examples. It has the core process of course. Find it at modernAnalyst.com as a featured article.

I'd be happy to discuss the topic here, there, or work with you on improvements on PlanetProject.

Lack of Engineering Practices Make 'Agile' Teams Fail

James Shore wrote a blog post that is among my TOP 5 in this quarter. Go read it! He argues that the industry sees so many agile projects fail because most teams that call themselves 'agile' mistake the real idea with the wrong set of practices. Maybe this quote says best what his article is about:

These teams say they're Agile, but they're just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It's the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff--the stuff that's really Agile--they're setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won't last.

This speaks from my heart. It's exactly what happened when I tried to turn a project 'agile' in a super waterfall organization (picking up this metaphor I'd say it's an Angel Falls organization). We will have technical debt to pay off for at least a decade. However, we found that out quite quickly ;-)
If you're looking for some method that is strong both in the management and engineering field, check out Evo by Tom Gilb. I know I recommended Mr. Gilb's work over and over again in the past 2 years, and it almost seems ridiculous. Be assured, I'm not getting paid by Tom :-)
To get a very clear perspective on iterative planning check out Niels Malotaux' Time Line.

Patterns for Use Case CONTENT, anyone? Yes, finally!

While modelling use cases, have you ever thought 'I have modelled something very similar before.'? Here's a solution to re-occuring modelling tasks. Martin Langlands has developed a bundle of patterns for the content of use cases. He developed these with an extensive backround in banking and insurance systems. After reading his well written article it I found myself in a very different field but still the patterns were applicable, to say the least. I think they are ready to use in most areas of concern, and the idea should set the use case modelling world on fire!

Visit Planet Project to see the respective Process.

Note: I proudly contributed the idea of another pattern to Martin's, the DESTRUCTOR pattern ;-) Go have a look.

5 Steps Towards Simple and Effective Project Estimation

Name: 5 Steps Towards Simple and Effective Project Estimation
Type: Process
Status: final
Version: 2008-07-31
Sources: my practice, Niels Malotaux (see http://www.maloteaux.nl/), www.iit.edu/~it/delphi.html

Gist: Every once in a while we start projects, or are about to start one, and somebody asks "how long will it take? " (The better question would be "how long will it take to have benefit A and B?", but that's another story.) The following simple 5 step process provided sufficient precision while not being too time-consuming. Additional benefit of the process: A group of people did it, most commonly the group that as to work on it anyway.

Entry1: You need to have clear objectives.
Note: If you don't have clear objectives, you will notice in Step 4.

S1: Sit down - alone or better with one colleague - and break the work down to one or two dozens of task-chunks. List them.
Notes:
* If it's a well-known problem go find someone who did it before!
* If it's a rather small project you can break it down to single tasks, but you don't have to. Roughly 10-25 list items.
* Best effort. Don't worry too much about forgetting things or about the uncertainty because you don't know every constraint.

S2: Distribute the list to the people who will work on the project or know enough about the work to be done. Ask for their best estimates for each chunk. Allow for adding items to the list.
Notes:
* It's a good idea to limit the time for the estimations, especially if you have external staff that is paid by time and material.
* Don't go for ultimate precision, you won't achieve it anyway. Variances will average.
* You're much better off with an initial, not so precise estimate and early, constant calibration.

S3: See where estimates differ greatly. Discuss or further define the contents, not the estimates.
Notes:
* Everyone's an expert here. It is not about right or wrong estimates, but about understanding the work to be done.
* In the original Delphi process there's an element of anonymity. I can't follow that advice, for the purpose of this process also is to build consensus.

S4: Iterate S2-3 until sufficient consensus is reached.
Notes:
* Niels says, not more than one or two iterations are necessary.
* I say, it sometimes needs a dictator approach.
* Careful here, make sure to discuss the content of the work. Also helpful to further specify the objectives!

S5: Add up all task-chunk's estimates: that's how much work the project is.
Note: The single most useful approach to fitting the work in a tight schedule is to work hard to NOT do things that later will be superfluous.

Related Posts:
Earned Value Analysis for Feature-Burndown in Iterative Projects
Measuring and Estimating one's Velocity
Calculate Process Efficiency
Quantum Mechanics, Buddhism and Projects

How to Personally Get the Most Out of Finished Projects

Name: How to Personally Get the Most Out of Finished Projects
Type: Process
Status: final
Version: 2008-05-19

Gist: Dustin Wax wrote an awesome article at the Lifehack web log. Topic: Getting Past Done: What to Do After You've Finished a Big Project
As it is significantly more stuff than fluff I will essentially post a link only, for once. However, you might like the following definition.

reflective thinking DEFINED AS active, persistent, and careful consideration of any belief or supposed form of knowledge in the light of the grounds that support it and the further conclusions to which it tends [that] includes a conscious and voluntary effort to establish belief upon a firm basis of evidence and rationality <- Dewey, J. 1933. How We Think: A Restatement of the Relation of Reflective Thinking to the Educative Process. Lexington, MA: Heath.

S1: Read: Getting Past Done: What to Do After You've Finished a Big Project <http://www.lifehack.org/articles/productivity/getting-past-done-what-to-do-after-youve-finished-a-big-project.html> and extract the questions.

S2: Answer the questions in a quiet moment. You could also use them for a guideline in a lessons learned meeting.
Note: Reflection is method of learning with scientific proof of its effectiveness.

S3: Prepare a checklist for future use on finished projects (or link here).

Calculate Process Efficiency

Name: Calculate Process Efficiency
Type: Process
Status: final
Version: 2008-04-10

Gist: to find out, where in a process you can improve efficiency, with respect to added value to the customer
Sources: http://www.shmula.com/458/the-hidden-factory-would-the-customer-pay-for-that

Process DEFINED AS a systematic chain of activities with a customer observable outcome.
Note: this may be a use case, a scenario used to plan the user experience for a product, a company's process chart ...

Process efficiency DEFINED AS value adding activities in a process divided by all the activities, in seconds, minutes, hours, days ...
Note: You could also measure it in money, or people, or other resources.

S1: Plot the process, maybe using a UML activity diagram

S2: For each activity in the diagram, decide if it's either
- adding value to the customer,
- not adding value to the customer, but is absolutely necessary, or
- not adding value to the customer

S3: Measure with a stopwatch how long each activity takes.

S4: Sum the measured times for each category of S2

S5: Divide the measurement for the 'adding value'-category by the sum of S4, that's your Process Efficiency.

Note: Most likely you will come up with a number smaller than 1, because of the 'not adding value' activities that are necessary.
Note: the 'not adding value' category is the cost you bear on your customer, but does not add any value to the customer. (uh!)
Note: Obviously, from this point on work to eliminate not adding value activities. Or at the very least reduce the time needed for them.

Measuring and Estimating Personal Velocity

Name: Measuring and Estimating Personal Velocity
Type: Process
Status: final
Version: 2008-03-28

Gist: to improve on estimating how long a given task will take. To give a well grounded answer to the question: "When will this be finished?"
Note: although this process aims at personal velocity, it can be adapted towards team velocity. But mind entry condition E1, every team member will have to fulfill it.

velocity DEFINED AS the number of task-points done per day.

Entry Conditions:
E1: You must be willing to take notes of all your tasks and review them regularily, i. e. once a week.

Process:
S1: for every task you get or generate for yourself, do a rough estimate on its complexity. Simply give points ('gummi bears'), use Fibonacci's numbers for that, i. e. 1, 2, 3, 5, 8, 13, 21, 34, ... (each number is the sum of the two preceeding ones). "If task A was worth 5 points, Task B is a bit more complex, so I will give an 8."
Note: It is not important to estimate for example the hours you'll probably need. A relative meter is sufficient.
Note: For me, this takes 5 seconds longer than just jotting down a task. With about 30 tasks/week this adds up to whopping 2,5 minutes this substracts from my weekly work time.

S2: whenever you finish the task, just mark it 'done'. No need to recalculate your original estimate.
Note: This works because of a levelling effect over time and the number of tasks. See Notes below.

S3: Regularily (I go for once a week), sum the points of all tasks you finished since last time (e. g. the past 7 days). Do it at least a couple of weeks to get credible results.
Note: I do it all the time because I found that my velocity changes with the projects I work on. It takes 3 minutes per week.

S4: Divide the sum by the number of days you actually worked on tasks, so that holidays, etc. are not factored in. The result is your velocity, Gummi Bears Done per Day.
Note: you can decide to factor in holidays and the like, but then you will need a much more data in order to come up with useful answers.

S5: Whenever you are asked the magic question "When will this be finished?", do the rough estimate of S1 on 'this'. Divide it by your velocity. The result is the time you will need, in days. Don't forget to think about when you will start to do the task before answering...
Note: I use the average velocity of the last 5 weeks, to take changing velocities into account. Maybe after a year I find that it is good enough to use the year's average velocity.

Notes:
The steady estimation process S1 will level out a couple of unwanted effects:
- you will have good days and bad days
- you will have to estimate rather small AND rather large tasks
- one day, you will finish that monster task you estimated with 55 gummi bears, and this will boost this weeks sum.
- your always optimistic (or pessimistic) with your estimates
- tasks sometimes will have subtasks, that both appear in your task list side-by-side. 'this is not a problem unless you do a complete work breakdown

To give you a hint, tasks in my list range from 'Call Andy' to 'Write a new requirements management plan for Project A'.

I misuse MS Outlook's® Task-Details for keep track of the estimates. I don't care if the field says ' x hours', for me it's just 'x'

Earned Value Analysis for Feature-Burndown in Iterative Projects

Name: Earned Value Analysis for Feature-Burndown in Iterative Projects
Type: Process
Status: final
Version: 2008-03-27

Gist: to explain how to obtain information about the Earned Value of an agile project that is using a backlog of either {user stories, features, requirements, change requests}

Source: T. Sulaiman, H. Smits in Measuring Integrated Progress on Agile Software Development Projects. In addition, there's tons of information out there on Earned Value Analysis, check out:
http://en.wikipedia.org/wiki/Earned_value_management
www.earnedvalueanalysis.com/
www.projectlearning.net/pdf/I2.1.pdf

feature FOR THIS POST DEFINED AS a thing to be implemented, could well be a requirement, a user story, a use case. Whatever your backlog consists of.

Entry-Conditions:
E1: Each feature in your backlog needs to have an estimate, best measured in some points, gummy-bears etc. (Make the sum of all features your parameter TSPP, total sum of planned feature points)
Note: It's not imortant that these estimates represent actual budget, time or similar. They have to be consistent with each other and represent properly the relative relations between them
Note: You can adjust the number later but you will have to recalculate things (see S3-S5).
E2: You need to know how many iterations you will undertake. (Make this your parameter TNI, total number of iterations).
Note: Ideally, iterations are all the same length, i.e. timeboxes. You can adjust the number later but you will have to recalculate things (see S3-S5).
E3: You need to know the budget you are about to spend, from now to the end of the last iteration (make this your parameter TBP, total budget planned).
E4: You need an established way of tracking how much budget you have actually spent on each of the iterations.
Note: This can be obtained by maintaining a log of workhours spent on the project by each of its members.

Process:
S1: After every iteration, find out how much budget you have actually used for the iteration. Sum it up over all finished iterations. Make this your ABS, actual budget spent
S2: After every iteration, find out how many points you have actually implemented within all iterations (= ASI, actual sum implemented). All the feature's points count as implemented if and only if the feature is in full effect.
Note: this means you have to have a clear understanding what 'done' means for a feature.

S3: Do some calculations
- Expected Percentage Completed = TNI / number of already finished iterations
- Actual Percentage Completed = TSPP / ASI
- Planned Value = TBP * Expected Percentage Completed
- Earned Value = TBP * Actual Percentage Completed

S4: Find out about you projects cost performance and cost estimate:
- Cost Performance Index = Earned Value / ABS
Note: > 1 means under budget, = 1 means on budget, < 1 means over budget
- Cost Estimate to Completion = TBP / Cost Performance Index

S5: Find out about you projects schedule performance and schedule estimate:
- Schedule Performance Index = Earned Value / Planned Value
Note: > 1 means before schedule, = 1 means on schedule, < 1 means behind schedule
- Schedule Estimate to Completion (in iterations) = TNI / Schedule Performance Index

How to figure out what the problem really is

Name: How to figure out what the problem really is
Type: Principles, Process, Rules
Status: final
Version: 2008-03-27
Source: Don Gause & Gerald Weinberg, Are Your Lights On?; two own thoughts

Problem DEFINED AS difference between things as desired and things as conceived
Note: Don's and Gerald's original definition stated 'perceived' instead of my 'conveived'. I changed this due to some buddhism-oriented mindset of mine. Thanks to my friend Sven for reminding me.

Principles
P1) Each solution is the source of the next problem.
P2) Moral issues tend to melt in the heat of a juicy problem.
P3a) You can never be sure you have a correct problem definition, even after the problem is solved.
P3b) You can never be sure you have a correct problem definition, but don't ever stop trying to get one.
P4) The trickiest part of certain problems is just recognizing their existance.
P5) There are problem solvers and solution problemers.
P6) In spite of appearances, people seldom know what they want until you give them what they ask for.
P7) The fish is always last to see the water.
P8) In the valley of the problem solvers, the problem creator is king.

Process
S1) Ask: Who has the problem? Then, for each party, ask: What is the essence of your problem?
S2) think of at least three things that might be wrong with your understanding of the Problem. If you can't think of at least three things that might be wrong with your understanding of the problem, you don't understand the problem.
S3) Test your problem definition on a foreigner, someone blind, or a child, or make yourself foreign, blind, or childlike.
S4) Generate points of view. Every point of view will produce new misfits between problem and solution.
S5) As you wander the weary path of problem definition, check back home once in a while to see if you haven't lost your way.
S6) Once you have a problem statement in words, play with the words until the statement is in everyone's head.
S7) Ask: Where does the problem come from? Who sent this problem? What is she trying to do to me? The source of the problem is most often within you.
S8) Ask yourself: Do I really want a solution?
S9) Ask Why 5 times. Normally this leads you to the essence of the problem.
S10) If a person is in a position to do something about a problem, but doesn't have the problem, then do something so he does.
S12) Try blaming yourself for a change - even for a moment.

Rules
R1) Don't take s.o. solution method for a problem definition - especially if it's your solution method.
R2) Don't solve other people's problems when they can solve them perfectly well themselves. If it's their problem, make it their problem.
R3) If people really have their lights on, a little reminder may be more effective than your complicated solution.
R4) If you solve s.o.'s problem too readily, he'll never believe you've solved his real problem.
R5) Don't leap to conclusions, but don't ignore your first impression.
R6) We never have enough time to do it right, but we always have enough time to do it over.
R7) We never have enough time to consider whether we want it, but we always have enough time to regret it.

Simple Solid Decision Making

Name:
Type: Process
Status: final
Version: 2008-02-01

Gist: how to make well-grounded decisions even if you cannot use Tom Gilb's Impact Estimation method for some reason (see Gilb, Competitive Engineering, Elsevier 2005). Decision making is the process of choosing a solution to a problem from a set of solutions, given a set of goals.

Sources: Stefan Brombach (http://www.dreizeit.de/), Kai-Jürgen Lietz (Das Entscheider-Buch, Hanser 2007), Tom Gilb, own thoughts.

S1: Make clear the goals of your endeavour. you need to understand what you want to achieve, what you want to keep and what you want to avoid. Consider using the Decomposing Goals principles.

S2: If you have many 'small' goals, say more than 12, then consider integrating some of them in a more abstract goal. Example: 'low costs for running the application' and 'don't exceed the budget' could be combined into a 'cost' goal. If you have to be quick and can't afford doing step S1 (please really consider doing it!) take the common three goals {time, scope, quality}.

S3: Compare each goal with every other goal. The more important goal gets a point. If you can't decide which one is more important, give 0,5 points to either goal. In the end, add 1 point to every goal for every goal has at least 1 point. Now you know the ranking of your goals in terms of importance.

S4: Go find at least three different realistic 'solutions' or ways of achieving your goals. You need three or more to have a little room for manoeuvres. Bear in mind, if you only have one solution there's nothing to decide.

S5: Using a 0..3 scale, iterate through all your solutions and goals and again give points to the solutions. 0 means solution X does not help achieving goal Y at all, 3 means it helps a great deal. Multiply these points with the importance of the goal from step S3.

S6: For each solution, add all products from step S5. The solution with the largest sum wins.

Course of Action

Name: Course of Action
Type: Process
Status: final
Version: 2007-12-20

Gist: to explain how to act upon a problem or complex, dynamic, invisible situation

S1: work out your goals see >Specifying Goals, to be used as guides and criteria for evaluation of your actions (see step 5).
S2: gather information about the situation and about how it changed over time in order to build a structural model of the problem
S3: build hypotheses about how the situation has changed and deduct how it will change
S4: plan your actions, decide on your actions, act (don't forget to think about doing nothing)
S5: check the effects (momentary facts AND tendences!) of your actions and refine your strategy with new evidence
Note: this is not a linear process. Trace back to any step whenever you feel you should.

How to give a project a good start

Name: How to give a project a good start
Type: Process
Status: final
Version: 2007-12-06
Gist: describes what to do as a manager to make sure that the project after it's finished will be seen as a success AND something of real value has been produced.

S1: Meet with a few of your management colleagues and talk about the project's goals until you reach a consensus.
S2: Gather a kickoff meeting with these colleagues and make everybody bring one or more workers who are supposed to do the project work.
S3: Be as precise and specific as possible if some of the workers ask questions.
S4: Be specific about the project goals or concrete deliverables you might want to see. Let the project work out project organisation and courses of action.
S5: Ask the workers to explain their understanding of your vision.

Note: Surprisingly, you might have a hard time finding a project leader to happily go along with this behavior, for he can't sell almost anything as a success for you.

Improve Reusability of Use Cases by Extracting Business Rules

Name: Improve Reusability of Use Cases by Extracting Business Rules
Type: Process
Status: final
Version: 2007-11-21
Source: Scott Selhorst on Tyner Blain; Business Analysis Body of Knowledge, Version 1.6; my own experience, also see Wikipedia

Gist: write use cases that do not have to be edited if business rules change. write use cases that can be reused for various purposes, where the purpose is determined by business rules. write use cases that consist of essential, implementation independent statements (as opposed to concrete and implementation dependent). implement solutions that separate volatile rules from the rest of the code.
Note: It requires an explicit decision within the architecture or the design to implement things that way! However, in an agile development, you might not designg for this kind of flexibility unless you are sure it has a business value. This should not keep you from writing the requirements with business rules separated! Writing business rules separately may prod you towards a respective refactoring step.

A business rule
- describes a policy, guideline, standard, or regulation upon which the business operates.
- determines business decisions.
- defines or constrains some aspect of the business.
- is intended to assert business structure, or to control or influence the behavior of the business.
- is atomic, that is, it cannot be further decomposed.
- is not process-dependent, so that they apply at all times.
- normally has a significant impact on business processes, business data and business systems.
Example: "Only users with Level 3 clearance may access the XY-logs".

business rule IS EITHER a
Constraint - mandated criteria such as "the applicant must not be a felon",
Guideline - suggestions such as "the applicant should not have been rejected previously",
Action Enabler - rules that initiate or trigger behavior, like "when the customer's card has been rejected, it must be confiscated",
Computation - the embodiment of calculations, like "pay 1.5 times the wager for a two-card total of 21″, or
Inference - the canonical "if…then" statements

S1: Assume you have a use case with sections of some sort for a description, triggers, preconditions and normal / other flows.

S2: In every section go find statements that constrain the use case. Look for the keywords "must be", "must have", "make sure that", and also "always", "every", "never", "no", "all", "may", "can". 'careful here, make shure that the statement is true, i. e. validate it.

S3: In every section go find statements that enable actions. Look for the keywords "when", "if", "as soon as", "in case", and time triggers.

S4: In every section go find statements that describe computations. Look for factors and divisors, formulas in general.

S5: In every section go find statements that describe inferences: Look for "if ... then".

S6: In every section go find statements that describe default values. ' A classical rule to be implemented as a parameter.

S7: Especially in the flow sections, look at every decision or branch and find the rules that govern the decision making in this particular spot.

S8: Search the Normal, Alternative and Exception Flow Parts for concrete values like keywords, number ranges, states. Their abstractions are the business rules.Note: this also helps with finding the essential steps in a use case.

S9: For every statement found, see if you can extract it into a whole new sentence AND rewrite the remaining part of the description by using a reference to that new sentence. If you can, you have probably found a business rule in that statement. Give it a name and or a number.

S10: Make sure your Business Rules can be clearly distinguished from the rest of the specification.

S11: Consider writing an explicit requirement that requires some robustness concerning the change of these rules.

Do the Right Things

Name: Do the Right Things
Type: Process
Status: final
Version: 2007-09-04

Gist: to provide verification for a feature of a product, a plan of actions concerning the development of a product, or concerning the development of real options.
Note: you can apply this process on various levels of problems and or solutions.
Note: This process optimizes the success in the success equation

stakeholder differentiating: a function or property of the product (or an action of a plan) adds to the overall capability to satisfy the main stakeholders
Note: This means you have to have some notion who the product's main stakeholders are. The stakeholders will accept the product more if the product helps them reaching their goals.
Note: YOU could be the main stakeholder. Then differentiating means options for a wealth of future situations.

mission critical: a function or property of a product (or an action of a plan) is mission critical if the stakeholders will reach one or more of their goals only if the product has it (or the plan caters for it)
Note: This means you have to have some notion of the stakeholder's goals. The stakeholders will accept the product more if the product helps them reaching their goals.
Note: careful, you might presume that some way is the only way.

S1: produce a 2-dimensional space using the above dimensions (mission critical/not mission critical, stakeholder differentiating/ not stakeholder differentiating). This gives you 4 quadrants.
S2: for each feature or sub-feature of the planned product (or action of your plan, or possible step towards your personal goal), ask and answer the following questions: "is it stakeholder differentiating? y/n" and "is it mission critical= y/n".
S3: place it in the quadrants of the space you created in Step 1. You may express more continuous answers than y/n along the axises of your space.
S4: The verfification rules for the four quadrants are:

stakeholder differentiating AND mission critical:
invest and excel. you should do lots of things. put your main effort here. provide the most inner quality.
Note: this is the place where the rewarding things to do yourself are. It is nice to harvest the options you .
stakeholder differentiating AND NOT mission critical:
"good enough" will do. use Pareto. do cheap and easy things.
Note: Will you have the option anyway, whether you do a lot now or not?

NOT stakeholder differentiating AND mission critical:
find a quality partner. use your partner's services. don't do it on your own
Note: Do not expect that your partner gives you many options. However, it is nice to share success (with a business partner or some other partner). Be honest and thankful.

NOT stakeholder differentiating AND NOT mission critical:
do nothing about it. don't waste time and or money
Note: You can use the options that lie here anyway.

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?

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.

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