Blog


Software Delivery – Optimise for predictability or productivity?

This blog post was inspired by a recent work rant:

/Rant
It may be worth having a conversation around what a delivery plan is (and isn’t). Once the delivery-plan has been communicated, it will likely be out of date as we’re working in a unpredictable complex system (not an ordered predictable system). I hope we consider the delivery plan as an alignment tool which will constantly change as we learn, react & adapt (not as a stick for fixed dates/deliverables). If we need a guaranteed delivery plan and dates, then perhaps we need to use a different method of planning & delivery (perhaps Waterfall, with lots of buffer, contingency & lead times).
/End Rant

Often when delivering software we have two competing interests; being predictable in delivery (i.e. hitting targets / deadlines) vs. maximising productivity (delivering valuable output). For this article we’ll define predictability as ‘delivering software features on time, to budget and to an acceptable level of quality’ and define productivity as ‘maximising value-add features, maximising learning and minimising waste’. From experience these two concepts can be opposing and depending on the type of work at hand can land your initiative in a different place on the scale below in figure 1.

Figure 1. Predictability vs. Productivity in software delivery

Often the more predictable a team needs to be, the less actual value adding work (or validated learning) it will produce, and will often partake in poor processes and generate low-to-no value-add artefacts. My hypothesis is if two independent teams were to solve the same problem, within the same environment, with the same constraints and technical stacks etc (i.e. identical space), the team choosing to be more predictable would be between 10% to 40% less productive. The more predicable team would spend more time on upfront analysis, design, architecture, upfront spikes on unknown areas, more time breaking down work into detailed tasks, estimating & planning. They would then likely deliver in larger batches and have longer release cycles, but the team would hit delivery targets, budgets and be predictable – happy days (or so we think)!

I suspect the more productive team would be less predictable, most likely starting by completing a high level delivery plan upfront (i.e. a mud map), identify dependencies with long lead times (early on), look to attack hidden complexities through working software and be constantly evolving their delivery plans, budgets and forecasts. The more productive team would spend less time producing upfront artefacts such as business requirement documents (BRDs), solution architecture documents (SADs), detailed work breakdown structures, detailed delivery plans & budgets, but would plan to deliver the smallest vertical increment of working software, and continue to iterate and build based on rapid feedback from the environment. Valuable working software would provide the best feedback, documentation and risk reduction and any artefacts required such as architecture diagrams, user documentation etc would be produced just in time. The team would frequently evolve the delivery plan based on historic velocity with just enough detail to communicate dependencies, ensure alignment, communicate actual & forecasted dollar burn-rate and set/reset delivery expectations as value is realised and the ecosystem changes.

Methods of Software Delivery

The Waterfall method is an extreme example of large up-front effort with little to no early value and long lead times, Scrum introduced time-boxed, value adding increments and lands in the middle of Predictability vs. Productivity scale and Lean / Kanban method is an example of a fluid, flow based delivery method as seen in figure 2.

Figure 2. Schedule based vs Flow based software delivery methods

Extreme caution should be used when moving too much towards big up front delivery planning (such as the Waterfall method) where there is a need to try to understand and solve all problems at the start of a project, as highlighted in the 2015 Standish Chaos report smaller projects have a much higher chance of success, and in all project sizes Agile methods delivered success 39% of the time (challenged 52%, failed 9%), compared to Waterfall which delivered success 11% of the time (challenged 60%, failed 29%) . Ignoring Waterfall, the predictable team above may choose the Scrum methodology and assuming a 7 person delivery team, two week sprint and a 40 hour work week we see the following time spent on Scrum rituals per team member:

  • 15m daily standup
  • 4hr backlog grooming, story breakdown & estimation
  • 1hr sprint planning
  • 1hr showcase
  • 1hr retrospective

Total of: 9.5 hours per sprint or 12% of sprint time per team member
Total of : 66.5 hours of team time per sprint

Spending time breaking down the backlog into smaller backlog items, discussing visual and technical designs, teasing out complexity & dependencies, poker-planning and thinking about execution are very valuable activities which lead to higher confidence levels and better predictability. With a little bit more work relatively-estimating the delivery backlog, some historic velocity and some contingency built in, the predictable team can now forecast delivery in the 2-3 month window with a level of confidence.

The productive team may feel spending 12% of their time on rituals as heavy and would look to spend minimal time on overheads. As work comes in and is prioritised, the team would break work down into small (similar sized) items and tackle the next most important issue, continuously deploying value and seeking feedback. They would likely spend less time breaking down work and planning, and more time doing and assessing the results; more of a continual flow based method. Often the flow-based delivery teams are good at forecasting days-to-a-week of work, but not great at forecasting weeks-to-months of work, and are often less predictable than a typical Scrum team, but arguable more productive.

The culture of the productive team is likely to be more focused on being brave, attacking problems, compelled to action, taking calculated risks, rewarding failure & learning cycles, supporting each other and focused on getting things done whilst the predictable team will likely play it more safe, be more risk adverse, compelled to analysis and more focused on delivering to expectations rather than striving for stretch goals. The culture of the team and the broader ecosystem the team operates within is a major influencer on the teams ethos; to be predictable or to be productive.

The above example indicates both extremes of the predictability vs. productivity, there are many different considerations when choosing where to land on the scale and my hypothesis above assumes a certain context & problem; however many things needs to be considered such as:

The type of work at hand – is it well known, repeatable, complex or unknown?

Following the Cynefix framework, where does your work or ecosystem fit?

Are you operating in business as usual mode (BAU) of an established well understood application?

Are you building a new application from scratch and don’t fully understand the customer problem or domain?

Are you working on a pure innovation front, or with bleeding edge technology?

The team & individuals

How experienced are the team within the current ecosystem and technology?

How much career & technology experience does each team member have; graduate, junior, mid or senior?

How much cumulative experience does the team have (a team full of graduates, mid-tier developers or senior specialists or a good mix of all)?

Do you have an established, battle hardened team, or a newly forming team (going through Tuckman’s forming, storming, norming performing phases)?

The size of the feature, application or system

Are you building a small increment to an existing application or are you building an entire business support system?

Are you modifying a standalone feature, or a full customer or business workflow?

Are you building for a local market, or one that spans across language, time and culture?

The surrounding ecosystem of the feature, application or system

Are you working in a startup, trying to find customers, or in an established and highly regulated industry such as banking or insurance?

Do you have millions of customers on a legacy platform?

Do you have full freedom of ways of working to define your own processes, or are you bound to an existing corporate environment?

How much lead time does the business need for change management and go to market activities?

How many up-stream or down-stream dependencies do you have, and what are their lead times?

How easy is it to make a change in your ecosystem, how much effort is required to handle changes to an upfront plan?

The initiative, project or program of work in play

Are you working on a single, isolated system with limited dependencies or part of a complex, interconnected large ecosystem?

Are other teams and systems dependent on the work you’re producing to deliver on a program of work?

How many people are involved in the initiative, project or program of work – one team of 5 people, 15 teams and 150 people or hundreds of teams and thousands of people?

The lifespan of the feature, application or system

Following the lifespan of an feature, application or system by Kent Beck – Explore, Expand, Extract & Extinct

Is this feature a learning and innovative piece of work (i.e Explore) and needing extreme productivity and validated learning cycles?

Is this application or system scaling up and expanding (i.e Expand) and needing to overcome technical, system, process & people limitations?

Is this feature being delivered to an existing large customer base (i.e. Extract) where predictability and profitability are key drivers?

Is this feature, application or system being delivered at end of life (i.e. Extinct), hard to coordinate & expensive to change?

All problems are inherently different

Experience has taught me there’s often more than one way to solve a problem, each having a unique context & ecosystem; one size never fits all. Like most things in life, to move forward some trade-offs are likely required and most teams will find themselves somewhere in the middle of the scale, doing enough work to be predictable, without suffering significant productivity loses.

Where do you fit on the scale of predictability vs productivity?
What are your unique needs?
How fast do you want to go?
How predictable do you want to be?




Rich Dad Poor Dad summary

Rich Dad, Poor Dad is a great book on personal finance, investment and financial acumen, containing the lifetimes learnings of two men; their beliefs, wisdom and ultimately their financial outcome. Robert Kiyosaki had an extraordinary upbringing with a biological father who believed in studying, working hard and getting a secure job for life, whilst another father figure (a friends dad) left school early, believed in working hard for yourself, setting up businesses, finding investments, building wealth and continuous learning – who do you think ended up with a better financial position?

Robert highlights the importance of becoming financially literate, which our education systems don’t teach and compares the two approaches in his upbringing; at the dinner table of Poor Dad, financial discussions were forbidden, whilst at the dinner table of Rich Dads, financial discussions were encouraged and supported. Poor Dad encouraged studying hard and finding a good company to work with benefits (for life), whilst rich dad encouraged finding a good company to buy. Rich Dad forbid the words “I can’t afford it”, rather encouraging “how can I afford it” to get the brain searching for ways to generate more income and wealth. “If you don’t learn it, you become a slave to money”.

On setbacks, Rich Dad would say “There is a different between being poor and being broke. Broke is temporary. Poor is eternal”“The poor and middle class work for money. The rich have money work for them”. It’s very hard to generate wealth when only working for an income – the risk of a single employer and the government taking so much of your pay in taxes leading to The Rat Race – a cycle of people controlled by the emotions of fear and greed. Fear of not having money leads us to work, including in jobs we don’t want to do, and greed is spending all our pay checks each week, and as we get raises and promotions, up goes our spending – a vicious cycle. “Its not how much money you make. Its how much money you keep”. Saving and investing your income is “like planting a tree”,  you plant it, water it and watch it grow;  eventually becoming self sustaining and producing an abundance of fruit.

“Rich people acquire assets. The poor and middle class acquire liabilities that they think are assets”.

Rule 1: You must know the difference between an asset and a liability, and buy assets.

  • An asset puts money in your pocket, a liability takes it out.
Income Statement & Balance sheet of an ordinary citizen:

Working only for an income, you end up:

  1. Working for a company (time)
  2. Working for the government (taxes)
  3. Working for the bank (mortgage & credit cards)

Working harder in this situation to get ahead is not a great option.

Generating Wealth & Tending to your Business

Robert defines wealth as the number of days a person can survive without working (for money) before running out i.e. – financial independence. Ideally this is a balance of wealth generating income (high) and daily expenses (low). You don’t necessarily need high wealth if your expenses are low.

Mind your own business – be aware of where you are at and have a financial plan on generating wealth – revisit frequently and ensure you’re running your personal wealth like a business. Failing to do this will result in you never truely generating wealth, being prosperous or becoming financially free (like Poor Dad financial struggle). Look to keep expenses low, reduce liabilities and invest in a solid base of assets such as:

  • Businesses that do not require your presence
  • Stocks
  • Bonds
  • Income generating real-estate
  • Notes (IOUs)
  • Royalties from intellectual property
  • Anything else that produces income or appreciates

Get ever dollar working for you. Think of every dollar in your asset column as a dollar working for you to produce income, further growing assets. “If you work for money, you give the power to your employer. If money works for you, you keep the power and control it”.

There is an old acronym for a job – Just Over Broke.

Richard discusses the history of government and tax – including how to minimise your tax position through incorporating (i.e. corporations). Corporations can do things that ordinary tax-paying citizens can’t – like paying (nearly all) expenses before paying taxes (i.e. to reduce taxable income) and protecting from lawsuits (using trusts etc to protect personal assets from litigation etc). In summary:

Differences Between Poor, Middle Class & Wealthy People

Robert compares three different classes of citizens – poor, middle & wealthy class’ and their corresponding income statements & balance sheet snapshots for comparison.
Income Statement & Balance Sheet of an poor citizen:

The Poor have an income generated from salary and all outgoing to weekly expenses, with no assets.

Income Statement & Balance Sheet of an middle-class citizen:

The Middle-class have an income generated from salary, all ordinary expenses (including tax) and have liabilities such as mortgage, car loans, credit card debt etc. however don’t have any income generating assets.

Income Statement & Balance Sheet of an wealthy citizen:

The Wealthy class have income generated from from multiple sources including salary, multiple income generating assets and have liabilities such as mortgage, car loans, credit card debt etc. Through investing in wealth generating (often non-taxable) assets – wealth increases and asset accumulation grows.

Building Financial IQ

Financial intelligence (financial IQ) is made up from knowledge in the following areas:

  1. Accounting
  2. Investing
  3. Understanding markets
  4. The Law

Build up your knowledge and use experts in these areas (be aware you get what you pay for).

Learning to embrace failure is important and you should not despair – valuable lessons. “People who avoid failure also avoid success”. First you have to try – fail – learn and repeat. Create experiments which are small and make many to aid the speed of failing / learning, and moving closer to success. Fail fast, try again sooner.

There are generally two types of investors:

  1.  A common investor who invests in known, packaged investments (mutual funds, stock, bonds etc)
  2. A creative investor who seeks to find and create unique opportunities, looks for bargains, puts the difference investments pieces together and understands risk/rewards – often non-standard/non-typical investments. They find opportunities others have missed, learn how to raise money (i.e. outside direct bank funding) such as connecting a seller and buyer by “tying it up / taking over a position” and organise smart people to work for & advise them.

Career & Learning

Sometimes you can be highly educated / trained / experienced / specialised in one skill (i.e. a doctor, lawyer, teacher, IT etc), but it pays to keep learning, especially in other fields such as marketing and sales. Often highly skilled people “are one skill away from great wealth”. Its a good idea to develop specialisation in a field, however, it should just be the beginning, leading to developing more diverse and generalised skillset – “you want to know a little about a lot”. As an example – McDonalds do not make the best burgers (i.e. specialisation), however have excellent business systems, marketing & selling (i.e. good across many areas). Poor Dad encouraged specialisation whilst Rich Dad focused on learning a lot about many things including running a business and investing. The main skills for success are:

  1. Management of cash flow
  2. Management of systems
  3. Management of people

Most important specialised skills are sales & marketing.

Generating Wealth & Making It Happen

Once people have become financially aware / literate there are some common obstacles preventing generation of wealth:

  1. Fear – the fear of losing is far greater than desire to be rich. Be inspired by failure and learning.
  2. Cynicism – Cynics criticise whilst winners analyse and look for opportunities
  3. Laziness – Either by lack of work ethic, or more often by being too busy to tend to your business. Ask “how can I afford it” rather than saying “I can’t afford it” to get the mind thinking.
  4. Bad Habits – Pay yourself first – designed to motivate you to find (or save) money to pay all your other expenses.
  5. Arrogance – What you don’t know (or what you think you know, but don’t)  loses you money
Getting Started:
  1. Find a reason greater than reality: the power of spirit – find a purpose which is a combination of wants / don’t-want’s & passion
  2. Make daily choices: the power of choice – with every dollar we get in our hand, we hold the power of choice – to spend on liabilities, or to invest in assets or to be rich, poor or middle class
  3. Choose friends carefully: the power of association – those who you surround yourself with; you become.
  4. Master a financial formula and then learn a new one: the power of learning quickly – you can work for money as a formula, or you can learn other methods to generate income & create wealth – then rinse & repeat.
  5. Pay yourself first: the power of self-discipline
  6. Pay your brokers well: the power of good advice
  7. Be an Indian giver: the power of getting something for nothing – look at an investments quick-wins, getting your money back fast and review at what you get for free all for limited risk
  8. Use assets to buy luxuries: the power of focus – use the returns on your investment to buy luxuries as a form of motivation
  9. Chose heroes: the power of myth
  10. Teach and you shall receive: the power of giving
Other Considerations:
  • Stop doing what you’re doing
  • Look for new ideas
  • Find someone who has done what you want to do
  • Take classes, read and attend seminars
  • Make lots of offers (with necessary escape clauses)
  • Visit different areas to look for deals
  • Look in all markets
  • Look in the right places
  • Look for people who want to buy first, then look for someone who wants to sell
  • Think big
  • Learn from history
  • Action always beats inaction

You can review and purchase Rich Dad Poor Dad on Amazon.com.au.




Peopleware: Productive Projects and Teams summary

Authors Tom DeMarco & Tim Lister

Peopleware - Productive Projects and Teams 

1.Managing the Human Resource

  • Don’t manage to the software vending machine mentality – standard operating processes, telling a technical team how to do the job, hiding the team from the underlying problem, prescribing solutions, leaving no room for learning or creativity etc.
  • Allow and encourage teams to make errors and learn.
  • Work a sustainable 40 hour week, nobody can continually work overtime, or sprint from the start to the finish on a long project without slowing down, or worse, burning out. Creative workers require rest to be at their maximum productivity during their work hours, and great knowledge workers spend time outside work learning about their trade and applying learned excellence back to their work.
  • “Quality, far beyond that required by the end user, is a means to higher productivity.”
  • “Quality is free, but only to those who are willing to pay heavily for it.”
  • Employees who are experts at designing, developing and delivering the said work should be the people who estimate and commit to it; “Programmers seem to be a bit more productive after they’ve done the estimate themselves, compared to cases in which the manager did it without even consulting them. When the two did the estimating together, the results tended to fall in between.”

2. The Office Environment

  • “There are a million ways to lose a work day, but not even a single way to get one back.”
  • “While this [10 to 1] productivity differential among programmers is understandable, there is also a 10 to 1 difference in productivity among software organizations.”
  • A study on developer performance showed workplaces with larger dedicated personal workspaces which are quiet, private and interruption free performed much better and showed a reduced defect rate
  • A study of development showed how developers spend their time:
    • Working alone 30%
    • Working with one other person 50%
    • Working with two or more people 20%
  • Working alone requires Flow Time –  a near meditative, uninterrupted state where time flows unconsciously and developers are at their most productive – work output flows. It takes time to get into the zone (15+ minutes) which is mostly unproductive time and nothing kills Flow Time like being interrupted (by a colleague, phone, email, instant message, loud noise etc) or having a workplace which doesn’t understand and design for Flow Time.
  • There is a simple forumula to work out if you’re environment is setup for Flow Time called Environment Factor (EF). An EF of ~40+% should allow developers enough flow time and enable enough time to work with others and in groups:
    • Environment-Factor  = Uninterrupted Hours / Body-Present Hours

3. The Right People

  • Peopleware formula:
    • Get the right people.
    • Make them happy so they don’t want to leave.
    • Turn them loose.
  • Leadership as a service; leaders are enablers of knowledge workers who in large can self-manage. A leaders job should be to foster and grow teams, networks and aim to attain goal alignment. “The manager’s function is not to make people work, but to make it possible for people to work”.
  • Employee turnover is very expensive. It generally costs about 4.5 to 5 months of total employee cost to replace an employee and takes approx. 3-5 months for the employee to become fully productive.

4. Growing Productive Teams

  • A jelled team, aligned behind a common goal with momentum can be unstoppable. “The purpose of a team is not goal attainment but goal alignment”. A jelled team is usually has a strong sense of identity, a name, a brand, a catch phrase and a good, well known reputation.
  • Teamicide is a list of things that will likely prevent team jelling:
    • Defensive management
    • Bureaucracy
    • Physical separation
    • Fragmentation of people’s time
    • Quality reduction of the product
    • Phony deadlines
    • Clique control
    • Motivational posters, plaques & accessories
    • Overtime & weekend work
    • Internal team competition, performance reviews  (stack ranking, manage by objective etc), excessive personal praise & rewards
  • Overtime & weekend work – “That negative impact can be substantial: error, burnout, accelerated turnover, and compensatory undertime.”
  • Full transparency, delegation with trust, support, a safe environment where failing & learning is rewarded and open dialog helps teams and organisations gain great outcomes; to be properly effective an organisation has to have this at all levels. “This Open Kimono attitude is the exact opposite of defensive management. You take no steps to defend yourself from the people you’ve put into positions of trust. And all the people under you are in positions of trust. A person you can’t trust with any autonomy is of no use to you.”
  • Great teams build networks and this are not driven through hierarchies; “The structure of a team is a network, not a hierarchy. For all the deference paid to the concept of leadership (a cult word in our industry), it just doesn’t have much place here.”

5. Fertile Soil

  • Organisations tend to focus too much on certified methodologies rather than trusting its knowledge workers to setup systems and processes best placed for their work at hand;  “There is a big difference between Methodology and methodology. Small m methodology is a basic approach one takes to getting a job done. It doesn’t reside in a fat book, but rather inside the heads of the people carrying out the work. Big M Methodology is an attempt to centralize thinking. All meaningful decisions are made by the Methodology builders, not by the staff assigned to do the work.”
  • “Voluminous documentation is part of the problem, not part of the solution.” Big M methodologies often lead to:
    • A morass of paperwork
    • A paucity of methods
    • An absence of responsibility
    • A general loss of motivation
  • Better ways to achieve convergence of method are:
    • Training
    • Tools
    • Peer Review
  • Risk management within organisations is often seen in two extremes; non-managed, or managed so strongly risk adverse as to accomplish nothing of greats, transformational value; “The Peopleware premise—our main problems are more likely to be socio- logical than technological in nature—applies nowhere more strongly than in the area of risk”. “The risk we tend not to manage is the risk of our own failure.”
  • “The ultimate management sin is wasting people’s time.”
  • Starting projects with a full team – early overstaffing, rather than a slow ramp up during the start of a project planning & design phase most often wastes time and money
  • The cost of creating and consuming email should not be underestimated. Where possible avoid sending out corporate spam and grow a self-organising and coordinating culture without needing email as a centralised coordinating function.
  • “Experience gets turned into learning when an organization alters itself to take account of what experience has shown. Learning is limited by an organization’s ability to keep its people.”
  • Middle management is often the first to get downsized and can often have a direct and significant impact on organisational memory and the ability for an organisation to learn – “successful learning organizations are always characterized by strong middle management.”. To maximise organisation learning, middle management must work closely with each other in effective harmony, avoid bureaucracy, silos, have common aligned goals, have clear communication lines and frequent interaction. Ensuring management are operating as an effective team is critical.
  • Aristotle’s five interlinked Noble Sciences that together make up Philosophy:
    • Metaphysics: the study of existence, the nature of the universe and all its contents
    • Logic: the ways we may know something, the set of permissible conclusions we may draw based on our perceptions, and some sensible rules of deduction and inference
    • Ethics: what we know about man and what we may deduce and infer (through Logic) about acceptable interactions between pairs of individuals
    • Politics: how we may logically extend Ethics to the larger group – humans and the community made up of humans
    • Aesthetics: the appreciation of symbols and images of metaphysical reality
  • Fostering and environment where community and culture grows is one of the most important roles of managers and leaders

Meetings

  • Some organisations have a culture of meetings, which are considered more important than work and other organisations have an extreme no-meeting culture – you need to meet somewhere in the middle. As organisation age, their meetings tend to get more frequent, and longer.
  • Some dysfunctions of a meeting:
    • People in attendance but not present (ie using technology) or engaged – perhaps because they’re not getting value
    • Inviting more people than needs to be present to make a decision. Fewer people the better and meeting costs should be calculated – “The cost of the meeting is directly proportional to the number attending.”.
    • “A meeting that is ended by a clock is a ceremony”. A meeting where no decisions are necessarily made, and where most of the conversation is conducted between two-people (ie the boss and round-robin people speaking) with other attendees siting idle can be considered a status-update / FYI meeting and considered a waste of peoples time – can be replaced by one-on-ones.
  • The very nature of working meetings are ad-hoc and called when necessarily to reach a decision; a frequent, reoccurring meeting is normally a status meeting – “The need that was being served was not the boss’s need for information, but for reassurance”.
  • Start each meeting with an outcome in mind and the question – “What ends this meeting?”. Once the meeting has achieved its goal, end the meeting promptly.

Change Management

  • The hardest pert of change management is dealing with people (not necessarily technology) – “The fundamental response to change is not logical, but emotional.”
  • Different personas to change (increasing in resistance):
    • Blindly Loyal (Ask no questions.)
    • Believers but Questioners:
      1. Skeptics (“Show me.”)
      2. Passive Observers (“What’s in it for me?”)
      3. Opposed (Fear of Change)
      4. Opposed (Fear of Loss of Power)
    • Militantly Opposed (Will Undermine and Destroy)
  • Celebrate and acknowledge our old ways of working as enabling this new change
  • “You can never improve if you can’t change at all.”
  • Change involves are the very least 4 stages and two key events:
    • Old Status Quo –> [foreign element / event, catalyst for change]
    • Chaos –> [transforming idea / event]
    • Practice and Integration
    • New Status Quo
  • Often with new changes you’ll go through a learning curve and dip in performance, before mastering the new ways and (hopefully) improving
  • “Change won’t even get started unless people feel safe—and people feel safe when they know they will not be demeaned or degraded for proposing a change, or trying to get through one.”

6. It’s Supposed to Be Fun to Work Here

  • Work should be fun, introducing some chaos into the mix can help with empowerment, ownership, innovation, boosting productivity, enable team-work, help with change management and introduce novelty. It can be done via:
    • Pilot projects
    • War games
    • Brainstorming
    • Provocative training experiences
    • Hack-days / Hackathons
    • Training, trips, conferences, celebrations, and retreats
  • When brainstorming, encourage quantity over quality – sometimes the sillier the idea the better. As idea generation slows, you can try the following strategies:
    • Analogy thinking (How does nature solve this or some similar problem?)
    • Inversion (How might we achieve the opposite of our goal?)
    • Immersion (How might you project yourself into the problem?)

You can review and purchase Peopleware: Productive Projects and Teams on Amazon.com.au.