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 ;-).

Project management template for FREE download KOSTENLOSER Download: Projektmanagement Vorlage

Projects by the book or by the trenches?

The PRINCE2 project management standard by the OGC is a very practical piece of work. There is no obligation to do it by the book while you meet certain criteria. And it is supposed to be helpful, not an obstacle. I believe it is indeed helpful, and that is exactly why I based upon it the design of some quite central piece of paper document for some projects I work on, the Project Identification Document (German: Projektleitdokument).

I wanted to fulfill the following requirements:

• Mustn‘t be lengthy.

• Mustn‘t become shelf-ware.

• Must be easy to maintain.

• Must be interesting for the steering committee, the project manager and the project team.

• Must include everything relevant to guide projects of 5 - 20 week‘s duration.

• Mustn‘t shut off readers who are not familiar with PRINCE 2.

• Must facilitate checking defect density, i. e. number of defects per page.

• Must combine the PRINCE 2 Project Identification Document, Business Case, Project Mandate and Project Brief into one (1) manageable document (huh!).

I decided to design a standard document structure for one of my clients, along with guiding descriptions of every document section and a checklist for each section. As you might suspect from my background, my former work and my friends, I not only rewrote the respective PRINCE 2 product, but included my 12+ years experience with projects and some relevant pieces of good engineering, as taught by honorable Tom and Kai Gilb.

Out came the RTF template you can download for free from PlanetProject. Be aware that RIGHT NOW IT IS IN GERMAN only. If you would like to have it in English, please contact me and provide me with a good reason to work on the translation :-) (or maybe YOU translate it and provide it on Planet Project, too?)

Let me know what you think, please!

All you want to know about Stakeholder Management

Alec Satin of the "Making Project Management Better" weblog has a brilliant list of links to Stakeholder management resources.

From his explainatory text:

In this list are articles to get you thinking about some of the less obvious issues in pleasing stakeholders. Primary selection criteria: (a) quick to read, (b) good value for your time, and (c) of interest whatever your level of experience." Markup is mine.

Enjoy!

8 Useful Tips to Pick an Analyst

Name: 8 Useful Tips to Pick an Analyst
Type: Rules
Status: final
Version: 2008-05-16

Gist: Every now and then I run into the task to pick a business analyst or systems analyst for a project or customer. Sometimes this starts with writing a job offer, sometimes with a colleague asking if I could take part in a job interview with some prospect. What should you look for?

R1: Clarify what tasks the candidate will have. 'Ok, this is a no-brainer

R2: Clarify what the challenge in this particular project or this particular job will be.

R3: Clarify what (analyst-specific) professional skills will be needed, now, and in the future, in this particular job.

R4: Clarify what soft skills will be needed, now, and in the future, in this particular job.

R5: Make sure the candidate knows these things (and has a sound approach to dealing with them):

• Stakeholders seem to change their mind on a regular basis. 'I think they don't, it just looks like a change
  
• Goals are seldom properly understood.
  
• Demand and Supply speak two different sociolects.
  
• Stakeholders (among other people...) have trouble communicating about future, i.e. the benefits, or the system-to-be.
  
• Other team members, including fellow analysts, architects, and QA-folk, deserve proper appreciation.
  
• A problem is a solution to a problem is a solution to... (also see the means-and-ands post)
  
• Many people (the prospect, too? Would be a bad sign for an analyst.) have a well developed answer reflex, so finding out what the problem really is can be quite a challenge.
  
• Any required product quality can be described in a meaningful, quantified way. (Refer to Tom Gilb's extensive and highly useful wokr on the subject.)
  

R6: Clarify what testing skills will be needed. 'An analyst that does not know how to design acceptance criteria?

R7: Look for someone who uses words like 'now and then', 'generally', 'frequently', 'some', 'somewhat', 'arguable', 'among other', 'on the other hand', 'also', 'able', 'allow'.

Note: The language gives you hints on the prospect's experience level. Experts tend to have many answers.

R8: Avoid people who use words like 'steady', 'always', 'every', 'all', 'absolute', 'totally', 'without doubt', 'nothing', 'only', 'entirely', 'without exception', 'must', 'have to'.

9 Rules for Requirements as Means of Communication

Name: 9 Rules for Requirements as Means of Communication
Type: Rules
Status: final
Version: 2008-05-05

Gist: What are the requirements for? From time to time I run into a project where the business analyst in charge (or requirements manager, or what ever they call him) does not know the answer. These projects do requirements because some governing company rule says they should. To my mind, requirements as all about transferring ideas from one person to another, or one group of people to another group. Here's what a BA should think about concerning communication.

R1) Always identify the readers. Make sure you sort out primary and secondary readership. Go for the group that benefits from the requirements NOW, if in doubt.

R2) Don't forget to ask your primary readers how they want to read requirements. Spoken or written prose, pictures, tables? Do they know UML? What's the common language of all your readers? Go check the SOPHIST's material on language and requirements if 'plain natural language' is the answer to the latter question.

R3) Always check if you can reduce the need to write things down by including people in requirement workshops with your stakeholders.

R4) Challenge arguments like 'we need the requirements after the project's finished, for maintenance'. Will there be an organization maintaining the system? Will they use your requirements?
Note: I know this rule hurts. However, I haven't seen a single specification that is still useful years (or even months) after the project's end, if this spec isn't maintained as well.

R5) Don't overestimate your memory. If you will be on a project for several months you yourself will need some aid for remembering that darn detail.

R6) Adjust your requirements style to what you're specifying. Is your system user interface-heavy? Database-strong? Functions? Constraints? Highly interactive? Real-time? Product family?

R7) Think of it: can the team (of designers, programmers, testers, users) be allowed to ask for the information they need, in contrast to you providing them 'one-size-fits-all' requirements.

R8) make sure everybody understands that perfect communication is not possible. The best thing you can do is speak with everybody a lot. The worst thing you can do is write a specification from beginning to end and throw that piece of paper over the fence (also see BUFR)

R9) You don't need requirements at all? You cannot not communicate! (Watzlawick)

5 Powerful Principles to Challenge Arguments

Name: 5 Powerful Principles to Challenge Arguments
Type: Principles
Status: final
Version: 2008-04-21

Gist: to provide a general checklist for the suspicious. The 5 principles show behavioural patters people use to make you do things in their favour, but not necessarily in your favour. Use this on (in alphabetical order) advisors, colleagues, consultants, counsels, managers, salespersons, vendors.

Sources: Scott Berkun: How to Detect Bullshit; and my all-time-favourite checklist: 12 Tough Questions by Tom Gilb.

P1) People are uncertain and tend to ignorantly stretch the facts.

• How do you know?
• What are your sources? How can I check them?
• Who told you that?
• Can you quantify the improvement?

Note: Carefully watch the answerer. If he needs a while, maybe uncomfortably shifting position, there's a good chance he's either making something up or needs time to figure out how to disguise a weak argument.

P2) People with weak arguments often have not made their homework on the topic.

• What is the counter argument?
• Who else shares this point of view?
• What are the risks of this, and what will you do about it?
• Can you quantify the improvement?
• How does your idea affect my goals and my budgets?
• What would make you change your mind?
• Have we got a complete solution?

Note: As from any facts, one can draw a set of reasonable interpretations, not just one. Everyone with intimate knowledge won't have great difficulties taking a different point of view for a while.

P3) People tend towards urgency when you are asked to make a decision with some hidden consequence.

• Can I sleep on this?
• When do we need to have a decision made? Why?
• I'd like to consult Person A first.
• Expert B, what do you think?

Note: People pressing ahead may try to throw you off your guard.

P4) People without a clear understanding of their point of view tend to inflate the language used.

• Please break this in smaller pieces, so I can understand.
• Explain this in simpler terms, please.
• I refuse to accept this until me, or someone I trust, fully understands it.
• Are you trying to say <...>? Then speak more plainly next time, please.

Note: Mark Twain once wrote in a letter to a friend: 'I'm sorry this letter is so long; I didn't have enough time to make it shorter.'

P5) People tend to have stronger arguments if they know someone is present who is hard to deceive.

• Use your network.
• Invite colleagues who have worked with these people.

Note: Simply help each other, like your family would do.

6 of the Dalai Lama's Leadership Principles

Name: 6 of the Dalai Lama's Leadership Principles
Type: Principles
Status: final
Version: 2008-04-18

Gist: to reflect upon the behavior of the 14th Dalai Lama when appearing publicly. It seems to me the following principles can also be applied in anyone's work in the position of some kind of leader. May be a project leader, a company's boss, the head of a department, or 'just" a thought leader within a group of people.

Sources: inspired by Cheri Baker at the Enlightended Manager Weblog; the 'Seeds of Compassion Webcast' from an event in Seattle, USA; some of the books the 14. Dalai Lama wrote; what people told me who had seen the Dalai Lama live.

P1: Don't direct, facilitate instead.
Note: This way, you find delight in the success and happiness of others.

P2: Make sure you want to learn something, so inquire rather that advocate. Listen, explore.
Note: In doing so, you'll show appreciation.

P3: Don't assume you know everything on the topic you're discussing. If someone brings something up that you think is wrong, show equanimity.
Note: There's the word 'equal' in equanimity.

P4: Be (and stay) humorous. Don't get angry, show compassion instead. Compassion means communication from your heart.
Note: This will facilitate creativity among the people you talk to.

P5: Encourage people to find their own answers, instead of giving all the answers you might have.
Note: also a good way of supporting P2, Learning.

P6: Be accountable.
Note: That means, you should pay attention to your actions and understand their consequences.

The Ominous Bill of Rights

Name: The Ominous Bill of Rights
Type: Principles
Status: final
Version: 2008-04-14

Gist: To present the Bill of Rights for a project development team (or contractor, originated by Tom Gilb), and to contrast it with a Bill from the customer / client point of view. I intend to balance Tom's view. PLEASE NOTICE, that these principles does not represent any official terms or principles used by my employer. This is, as all the other posts, a completely private matter.
Find a German version below.

Sources: The Contractor's Bill is from Gilb, Tom. 1988. Principles of Software Engineering Management. Wokingham and Reading, MA: Addison-Wesley. Page 23.
The Customer's Bill is out if my head.
Note: Tom did not call it 'Contractor's Bill of Rights', but only 'Bill of Rights'. It's clear what he had in mind if you read the specific principles.

Contractor's Bill of Rights:
P1: You have a right to know precisely what is expected of you.
P2: You have a right to clarify things with colleagues, anywhere in the organization.
P3: You have a right to initiate clearer definitions of objectives and strategies.
P4: You have a right to get objectives presented in measurable, quantified formats.
P5: You have a right to change your objectives and strategies, for better performance.
P6: You have a right to try out new ideas for improving communication.
P7: You have a right to fail when trying, but must kill your failures quickly.
P8: You have a right to challenge constructively higher-level objectives and strategies.
P9: You have a right to be judged objectively on your performance against measurable objectives.
P10 You have a right to offer constructive help to colleagues to improve communication.

Customer's Bill of Rights:
P11: We have a right to set the objectives for the endeavour.
P12: We have a right to change our minds about objectives at any time.
P13: We have a right to set the criteria by which we will measure your success.
P14: We have a right to be informed about exactly what you have accomplished at any time.
P15: We have a right to hear your arguments if you plan to change a decision that effects our objectives.
P16: We have a right to be informed of the consequences of a planned change, in measurable, quantified formats.
P17: We have a right to constuctively debate your planned change.
P18 We have a right to get clear documentation about any changed decision.

German Versions:
Rechte des Auftragnehmers:
Sie haben das Recht, genau zu wissen, was wir von Ihnen erwarten.
Sie haben das Recht, Dinge mit Kollegen aus der gesamten Projektorganisation zu klären.
Sie haben das Recht, klarere Definitionen von Zielen und Strategien anzustoßen.
Sie haben das Recht, Ziele in messbarer, quantifizierter Form präsentiert zu bekommen.
Sie haben das Recht, unsere Ziele und Strategien konstruktiv zu hinterfragen, um insgesamt ein besseres Ergebnis zu erzielen.
Sie haben das Recht, objektiv anhand messbarerer Ziele bewertet zu werden.
Sie haben das Recht, zu entscheiden über die Maßnahmen zur Erreichung der Ziele und ihre Reihenfolge.

Rechte des Auftraggebers:
Wir haben das Recht, die Ziele für das Vorhaben vorzugeben.
Wir haben das Recht, diese Ziele jederzeit zu ändern.
Wir haben das Recht, die Kriterien vorzugeben, anhand derer wir Erfolg messen.
Wir haben das Recht, jederzeit darüber informiert zu werden, was Sie bereits erledigt haben.
Wir haben das Recht, Ihre Argumente zu hören, falls Sie vorhaben Entscheidungen zu treffen, die sich auf die Zielerreichung auswirken.
Wir haben das Recht, über die Auswirkungen informiert zu werden, und zwar in objektiv überprüfbarer Art und Weise.
Wir haben das Recht, Ihre Entscheidung konstruktiv zu hinterfragen.
Wir haben das Recht, getroffene Entscheidungen klar dokumentiert zu bekommen.

7 Rules for Explaining Requirements to Colleagues 'Downstream'

Name: 7 Rules for Explaining Requirements to Colleagues 'Downstream'
Type: Rules
Status: final
Version: 2008-04-04

Gist: As a business/systems analyst, you will inevitably be confronted with the need to tell somebody about the requirements. The challange is to transport your knowledge effectively.

colleague downstream DEFINED AS someone who takes your requirements as an input for her work. I.e architects, developers, desiners, testers, techical authors.

R1: Include your audience as early and as frequently as possible. Don't fall to the BUFR principle, even if you are part of an organization that follows that principle. YOU can always make things a little differently, i. e. use unofficial channels. CC people, invite them to your stakeholder meetings, talk to them at the coffee machine.

R2: In general, use feedback cycles. It is not sufficient if your audience nods or exclaims 'understood!'.

R3: Explain the requirements, and let the others do a design right on the spot. The idea is not to come to a good design, but to see if you have effectively transported your ideas. Do the same with testers, let them lay out their test plans on the spot. Expand this Idea by doing the proven, highly efficient JAD.

R4: Don't be mislead by R3, it may be not sufficient. If you as well have to explain your requirements to someone who is not available (offshoring?), consider a formal review by someone who is not available.

R5: There's a classic but sometimes forgotten technique to make sure 'the other side' has understood: you write the business requirements, they write the system requirements. Again, this is not sufficient.

R6: Make sure your 'downstream colleagues' have to do with the subject matter for long years. (I. e. stretch projects as long as you can ;-) This way, they become subject matter experts (SME's). Weird, but efficient. However, beware of the risk that the new SME's are running the show, not your business stakeholders.

R7: Make sure YOU understand, that you cannot not communicate (see Watzlawick). However, also the reverse is true: You can't communicate, really. You will present your model of the knowledge and the receiver inevitably will have a different one.

Do Job Interviews Efficiently

Title: Do Job Interviews Efficiently
Type: Rules
Status: final
Version: 2008-08-22
Gist: selecting people to join your project team in an efficient and fun manner

R1) invite all candidates at once
R2) talk to the group, let the group talk to itself
R3) wait for the silent people to be asked questions by other people
Note: You will need to explain the project only once. You will feel the people you want to be with in a couple of minutes anyway.
You will save time.

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.

Principles of Clear Thinking

Type: Rules
Status: Draft
Version: 2007-12-20
Quelle: Principles of Clear Thinking. <- Blog on http://www.blogger.com/www.gilb.com 2007-03-27 (R1 to R10); rest: own thoughts
R1. You have to have a clear set of objectives and constraints, to evaluate proposed solutions or strategies against.
R2. You have to have a reasonable set of facts about the benefits and costs of any proposed idea, so that you can relate it to you current outstanding requirements.
R3. You have to have some notion of the risks associated with the idea, so that you can understand and take account of the worst possible case.
R4. You have to have some ideas about how to test the ideas gradually, early and on a small scale before committing to full scale implementation.
R5. If there are more than very few factors involved ( 2 to 4) then you are going to have to use a written model of the objectives, constraints, costs, benefits, and risks.
R6. If you want to check your thinking with anyone else, then you will need a written model to safely and completely share your understanding with anyone else.
R7. You will need to make a clear distinction between necessities (constraints) and desirables (targets).
R8. You will need to state all assumptions clearly, in writing, and to challenge them, or ask ‘what if they are not true?’
R9. You will want to have a backup plan, contingencies, for the worst case scenarios – failure to fund, failure for benefits to materialize, unexpected risk elements, political problems.
R10. Assume that information from other people is unreliable, slanted, incomplete, risky – and needs checking.
R11. Assume that you models are incomplete and wrong, so check the evidence to support, modify or destroy your models.