Traditionally Project Managers make decisions for the horde of software developers what features should be attacked in the long release. Yes, this approach frees busy developers brains from the mind boggling task of thinking about the business. But developers no longer get business context – why features should be done and what is important for the business. In addition, long releases detach developers from the product market results and inhibit learning and adaptation to the customer needs.

Agile Development

Agile fixes these problems with three important practices – The Whole Team, Small Releases and User Stories. Customers and developers are one team that frequently discuss features face-to-face and create User Stories together. Important User Stories become part of the new release, others go to Backlog. The team releases features frequently and learn from customer feedback and implementation.

User Story is done when it is:

• Code Complete and Working
• Tested
• Accepted by customer

Agile is wonderful process! Developers work closely with business providing speed, accurate interpretation of requirements and intellectual contribution (surprise!) in translating business vision and needs into the concrete software system.

The Customer accepts the User Stories at the end of frequent iterations, provides feedback and change future User Stories based on experience with this real working system. In short, the customer steers the direction of the project instead of being a hostage of the unruly slow development machine.

However, one big problem remains – everything depends on the customer’s ability to get brilliant ideas, correctly read the market and envision what set of features will succeed. Unfortunately, it is almost impossible to get right. Business geniuses (except Steve Jobs), smart analysts or even consumers themselves cannot reliably predict how people would react, what they really need and will like next. And developers can contribute more to the market discovery and quality of business decisions.

Market-oriented Development

Lean startup movement, Facebook and Toyota  have some interesting ideas that can be applied to the development process and improve chances of software market success.

Market-oriented Development has three distinctive characteristics:

1. Requirements goal is to maximize learning, reduce risks and uncertainty
2. Build-Measure-Learn Feature Cycle
3. Delivery Mechanism – Continuous Deployment and Flow

1. Requirements – Business Model Canvas and Customer Development

Maximize learning (about what’s riskiest) per unit time. Systematically eliminate risks.

- Ash Maurya, Running Lean

Your software system carries more than just technical risks:

• product risk – do you solve right problem in right way?
• customer risk – do you know who has the problem and how approach them?
• market risk – can you build effective business and make money?

Each software system feature (reflected in User Story) has similar risks on the smaller scale. Every new feature is an attempt to improve software system and business. The process should breed successful and eliminate failing features.

Business Model Canvas is an excellent source of requirements  - define areas of risks and opportunities to focus on what features should be built next.

Another great source of requirements is Steve Blank’s Customer Development process that helps to discover, validate and create customer’s needs.

The initial result is Minimum Viable Product (MVP) described with User Stories. Developers help to cross a bridge between business models and feasible technical implementation to form MVP.

2. Build – Measure – Learn Feature Cycle

Selected User Stories are transformed into Minimum Marketable Feature (MMF) for the release.

Use Scientific Method
Build features as experiments in proving hypothesis. An experiment is valid when you can definitely measure if hypothesis has succeeded or failed.

Follow Build-Measure-Learn Cycle

theleanstartup.com

MMF Extended Lifecycle:

1. Generate ideas (Theory) with Business Model Canvas and Customer Development – feature should improve business or increase learning
2. Survey (before development) – what are feature chances of acceptance and success (customer interview, surveys, marketing site traps for potential users)
3. Build Feature as Hypothesis avoiding expensive and long effort. Technology is not so important at this stage – inefficient or even manual solutions are ok.
4. Probe (run experiment) with
   • beta testing
   • usability testing
   • flip feature for a limited group
   • A/B testing
   • internal / close preview
5. Measure market success (validate with users, use analytics, get feedback, do cohort analysis)
   • If no clear market success (traction, positive feedback) – hypothesis is not confirmed, refine it
   • Outcome: validated learning – the feature is marketable!
6. Release (marketable feature) to wide audience
7. Adopt and Scale – make the feature reliable part of the core product
8. Monitor and Optimize – improve quality and performance of the feature
9. Improve feature and continue evaluating
   • Is it still good, marketable and usable?
   • Does it still confirm to 80/20 rule?
   • Does it escape over-complication and bloating after rounds of improvements?
   • Should it be replaced with something better and new?

MMF is done when it is :

• Code complete and Working
• Tested
• Accepted by customer
• Proved to be Marketable – users want and like this feature, and it can bring money / increase value

The Market-oriented Developers should target in parallel three completely different goals:

1. Traditional - design a solid system and lay stable foundation for the system expansion and usage
2. Agile - build a simple optimal system that can be adapted for the future changes
3. Market - create a minimum quick solution to prove viability of feature early and reduce product, customer and market risks. Be ready to radically change or scrap unsuccessful features.

Developers work with two types of features: Hypothesis and Core (proved by market). As a result two kinds of development activity streams run in parallel

• Form stable core for proven features – high quality, refactored and optimized
• Build isolated hypothetical features with options to flip or remove completely (without consequences). Lower quality and shortcuts are acceptable. The main goal is to prove the feature with minimal effort and system disturbance.

3. Delivery Mechanism – Continuous Deployment and Flow

Startups that succeed are those that manage to iterate enough times before running out of resources. Time between these iterations is fundamental.

- Ash Maurya, Running Lean

The software team that practice Continuous Deployment should be disciplined, professional and focused. Developers work in advanced mode – frequently release a system woven from features on different life stages instead of rarely releasing big slumps of monolithic frozen codebase.

The Flow

Input

• Business Model Hypotheses
• Core Feature Improvements

1. Develop

• Build in small batches – less disruption, easier to swallow
• Reduce work in progress – focus on features that can be completed and released in short time (otherwise reduce feature scope)
• Eliminate waste - keep only value-added code and activities

2. Test

• QA is the part of the development process, not a separate phase
• Automated Testing and Continuous Integration are core mandatory practices
• Jidoka – no failing tests, zero defect totlerance – stop and fix if a problem arises

3. Deploy

• One click deployment and rollback
• Feature flipper system (e.g. Flickr, Facebook Gatekeeper)
• Integrated Operations and Development – both teams are part of the whole process from requirements to launch

4. Monitor

• Build a Signal System that detects, alerts and recovers software system from errors
• Genchi Genbutsu – Go and See -thoroughly and objectively understand problem before making decisions
• Remove root causes – tolerate unexpected problems only once – use Toyota 5 whys and Kaizen.

This delivery mechanism enables fast product cycles for market validation, refining product and eliminating risks.

Outcome

Three mental shifts:

1. Each Feature should improve a business model or increase learning about it.
2. A new feature is a Hypothesis about solution that should pass Ultimate Marketability Test to become Core.
3. Create lean continuous flow to achieve just-in-time delivery.

A market-oriented team goes beyond regular development practices. Developers are not only building good software system focusing on technology, but they are improving product market chances, and become active contributors in the quest for repeatable and scalable business model.

Isn’t this kind of development the best process for any business?

Books

Related posts:

1. The Elements of Pragmatic Programming Style. Composition.
2. When should you Release Early and Often?
3. The Secret of Building Effective Software Systems

The main architecture goal is to strengthen and align system ideas, muscles and structures in areas most impacted by stress, changes and expansion.

In short, architecture covers every important aspect of the software system.

A good thoughtful software developer is torn apart by conflicting approaches  for architecting complex software system:

1. Heavy upfront system design leads to rigid, costly and over-engineered solutions
2. Ignored business and technical perspectives cause  business irrelevance or failure
3. Poor reliability, performance or flaws could kill promising beautiful software system

What is the best approach to build a sound and successful system?

Problems

Let’s consider several architecture challenges that a software team faces during system development.

1. Idealism (assumed known knowns) – mostly theoretical views, lack of practical experience, illusions. We often exaggerate our intellectual abilities to find right solution theoretically.
2. Open problems (known unknowns) – problems or needs without foreseeable solution. These evil inconvenient unknowns could seriously impact the course of the project
3. Uncertainty (unknown unknowns) – low predictability of the future in technology, business and Universe. Many good decisions could turn to be wrong after some time.
4. Over-complication – over-engineering for domain problems because of over-thinking, misunderstanding, lack of information or technical enthusiasm. Over-complication steals development time and increase cost and complexity.
5. Fragility – poor system quality (performance, reliability, uptime, security, etc.). Neglecting quality could cost reputation and harm system success.
6. Complexity – complex structures, unpredictable behavior and states that turn a system into the Ball of Mud.
7. Inconsistency – dissonance of the system approaches and parts; fragmented and incomplete knowledge in heads. Development teams produce incoherent system without coordination of ideas and implementation.
8. b- difficulties to introduce disruptive changes (for business, users, operations). People and established processes resist changes and have inertia that is difficult to overcome.
9. Misalignment – with business goals, existing systems, infrastructure. Building a software system without considering business vision, existing IT landscape is the path to disaster.

Three Architecture Answers

There are 3 useful approaches to Software Architecture that address these challenges:

1. Strategic
2. Technical
3. Evolutionary

1. Strategic Architecture

“Plans are nothing; planning is everything.” – Dwight D. Eisenhower

Question: What are direction, constraints and external factors?

How: dedicated architecture group moves ahead of the main development activities to align ideas for business, development, infrastructure and partners.

Attacks challenges

• Misalignment
• Inertia

Outcome
Strategic Architecture defines a system playing field:

• Vision: system goals, purpose and desired end-state
• Domain: business needs and problems to solve; describe models and processes
• Constraints: budget, time and resources; acceptable system qualities
• IT landscape: existing infrastructure, required integration with internal and partner systems; standards and API
• Coordination: release planning, deployment and all necessary steps to build and operate successful systems.

Approach

• Business Canvas – strategic tool for business models
• Domain Driven Design – implementation of core business concepts
• Enterprise Architecture – organizing logic for complex business and IT fields.

2. Technical Architecture

“Vision without execution is hallucination.” – Thomas A. Edison

Question: How to build a solid well-engineered system?

How: Developers predict (based on experience and preliminary information) possible challenges and future requests and implement architecture elements early (system layers, databases, security, caching) keeping system consistent and meeting required system qualities.

Attacks challenges

• Complexity
• Fragility
• Inconsistency

Outcome
Technical architecture proactively cares about building an excellent engineering solution:

• Technology: technical and development platforms
• Organization: well structured software system, where all elements fit together without excessive dependencies and side effects
• System Qualities: reliability, performance and other quality targets; protection against failures and security threats
• Integrity: consistency in developers heads, their approaches and system implementation

Approach

• Architecture patterns and principles: open-closed, single responsibility, separation of concerns, dependency inversions, etc.
• QA; failure  and performance testing
• Pair Programming, code reviews and threat assessment

3. Evolutionary Architecture

“In theory there is no difference between theory and practice. In practice there is.” – Yogi Berra

Question: How to find the most optimal design and adapt the system to unknown?

How: Architecture emerges as a result of iterative development and refining the system for the most important business needs and optimal design.

Attacks challenges

• Idealism
• Uncertainty
• Open problems
• Over-complication

Outcome
Evolutionary architecture grows a system by quickly adapting for new discoveries, changes and feedback

• Quick validation and refinement of ideas
• Optimal design – well-refactored system based on the best development practices and design principles
• Fast learning

Approach

• Agile practices: iterations, refactoring, continuous integration
• Start small with end-to-end simple, but working solution and grow based on learning what is needed and important
• Lean startup with ideas adaptation and validation

Selecting right Architecture Mix

The choice is not what kind of architecture is needed, but what is the right mix

One cannot embrace the unembraceable and deeply focus on all architectural dimensions at the same time. However, you can tailor your approach to your current situation and most pressing challenges.

Right architecture mix will greatly increase chances of your system success!

Related posts:

1. The Secret of Building Effective Software Systems
2. The Role of Software Architecture: Taming a Monster.
3. Evolutionary Software Architecture or Why Developers Are Not Janitors

The software system in the period of active growth is a really wild beast. Excited developers with creative minds and feature obsessed marketers consistently add the fuel to this fire of software creation.

Uncontrollable growth, race for features and engineering wonders sometimes give rise to a monster – a software system bloated with useless features, over-engineered internals and erratic behavior.

At some point, developers stop understanding the system and start fearing it while doing less and less productive attempts to fix and grow it under pressure from screaming users and management.

What is happening during this transformation of the bright promising software idea into a scary monster system?

Here is a complete state diagram of a wild young software system growth:

The root reason of this scary transformation is get-out-of-control complexity. Eventually, Success Loop dries up and Failure Loop takes over and lead the software system to disaster.

What could prevent this pitiful descent and ensure long-term health of the software system?

Here comes Architecture!

The primary goal of the software architecture is taming complexity of the functionally growing software system under physical load from demanding users, harsh environmental impact and psychological pressure from managers. Architecture attacks and reduces effects of the software development Failure Loop.

Good architecture strengthens and aligns system ideas, muscles and structures in areas most impacted by stress, changes and expansion.

Three Architecture Responsibilities:

1. Explain and carry The Theory of the system. Align new ideas and needs with system realities.
2. Guide system Organization. Enable fast growth and modifications.
3. Support required system Qualities (stability, performance, security, etc). Make system behave well.

1. Architecture Carries The Theory of The System

A theory is the more impressive the greater is the simplicity of its premises, the more different are the kinds of things it relates and the more extended the range of its applicability. – Albert Einstein

Creating Software Architecture means building a common theory that explains the software system. It is an attempt to join many fragmented pieces into a package that is consistent and easy to digest for human brains Architecture creates bird’s-eye view on mundane torrent of code details, states and behaviors.

Architecture is the essence of what, why and how of the software system. It is a set of ideas and explanations that allow humans to make sense of the system. A small system require little help to understand. A large complex system requires a lot of explanation – volumes of information, pictures and tales from people who had firsthand account of the battle for the system.

 Concerns

1. Simplicity - fight complexity on every possible level. Simple systems are easy to grow and maintain. More complex system lead to stressed minds and broken hearts.
2. Clarity - tune everything about the system (ideas, design, code, documentation, etc.) for better digestion by human brains.
3. Interpretation - how close the system reflects the business concepts in implementation. Is it direct translation that guides system organization and logic or irrelevant pile of technical ideas?

Methods

1. Domain Driven Development is an excellent approach for translating customer domain into relevant architecture
2. Conceptual models translate vague business ideas into formal description of the problem space.
3. Metaphors and abstractions bring disjointed ideas into coherent whole that is easier to digest.
4. Shared language and domain-driven naming synchronize customer domain and technical ideas.
5. Storytelling, user personas and usage scenarios help to convert overwhelming information massives into easy to remember chunks that are friendly for developer’s brains.

2. Architecture Guides System Organization

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery

The software system is a system (not surprisingly) with elements, structures, connections. All this stuff is a projection of the theory into practice.

Concerns:

1. Flexibility - ease of change without painful struggle, breaking the system and causing unexpected butterfly effects (side-effects).
2. Integrity - alignment and good fit of parts with each other and overall theory of the system that create coherent tight assembly.
3. Preservation - ease of keeping original system intent and healthy organization without hacks and workarounds.

Structure and Dependencies

Complexity and problems are often coming from internal mess and tangled dependencies.

Methods

1. Separation of Concerns – breaking down and taming smaller groups of related elements reducing overall complexity of the system (modules, hierarchies, layers, etc.)
2. Restrain dependencies – reduce elements connections (with isolation) and side-effects (with orthogonality).
3. Generalization - rely mostly on abstractions and interfaces, hide concrete implementation on lower level.
4. Federation of specialized components – favor reusable smaller components with narrow responsibilities to big rigid elements or procedures suited only for one scenario.
5. Design and Architecture patterns are an excellent source of design ideas and their trade-offs.

Minimization

Every piece of knowledge must have a single, unambiguous, and authoritative representation within a system. – The Pragmatic Programmer

Producing more code inevitably increase complexity and reduce mental control. Architecture helps to focus on keeping clean minimal codebase for needed functionality.

Methods

1. Use 3d party – integration with existing libraries, components and services could significantly reduce system codebase and required effort. Certainly, there are some risks and shortcomings.
2. Maximize reuse & follow DRY – avoid duplication and cloning
3. Refactoring – continuously improve system design to keep it in minimal, optimal and clean state
4. Abstraction - synthesize system concepts and elements to avoid different solutions to similar problems.

Extensibility

A system should be open for extension but closed for modification – The Open Closed Principle

A software system should provide an easy way to extend and add new features without invasive surgery on already tested and working parts. Architecture helps to consciously establish this way.

Methods

1. Published API – stable and officially endorsed set of interfaces that open ways for safe and supported way to manipulate a system.
2. Extension points – clear definition of intent to extend through interfaces, inheritance, etc.
3. Pluggable architecture – allow to add elements in formalized way with open framework infrastructure and component specifications (WordPress, jQuery)

3. Architecture supports System Qualities

Better to be rich and healthy than poor and sick. – Russian proverb

Correct, secure and responsive system is much better than buggy, vulnerable and slow. However complex software systems under heavy unpredictable usage could easily degrade to a pitiful state of sick unruly monster.  Proper architecture could prevent this bad behavior and keep the system within borders of correct, well-performing and stable state in most situations.

There are three important characteristics: Stability, Performance and Protection.

Stability

1. Resilience and self-healing – ability to survive and recover from surges and failures
2. Elements packaging and release management – the way to package and release elements to avoid disruptive shocks to the system on updates.
3. End-to-end testability, automated testing and sandbox environments – ability to completely simulate the system live behaviour in short time before release into wild
4. Freeze published interfaces and provide legacy support for dependant subsystems
5. Monitoring,  signal system and self-assessment – promptly alert when something goes wrong
6. Operational manageability and control - easy to manage and configure

Performance

1. Optimize processing, data flows and storage - achieve right balance between fresh data and cache, throughput and latency, processor cycles and memory.
2. Scalabiliy - ability to scale the system with increased load (replication, distribution, partitioning / sharding)
3. Elimination of bottlenecks and easing of stress lines

Protection – from threats, disasters and surges

1. Security, proactive defence, threat assessment and detection - resist hackers and vandals
2. Backups, standby reserves / redundancy, multiple locations - avoid single points of failure and have ability to fully restore in case of bad crashes and losses.
3. Prepare for worst - closely monitor points of failure; simulate and train people to recover from disasters.

Raising Architecture

As any theory, software architecture could be bad or great, helpful or misleading, clear or convoluted. Architecture directly impacts the fate of any non-trivial software system.

The real architecture is not a static theory or prescription how to build the software system. This is a theory that emerges with the growth of the system, refined by discoveries and failures. Developers adapt this theory to fit harsh realities of the external world, confusing requirements, management pressure and user demands. And in return, good architecture helps to keep the system consistent, stable and controllable over the time.

The main benefit of architecture is ability to effectively grow the system that embrace demands, bring market success and makes people happy. Tame your software monster and make it obedient machine!

Related posts:

1. The Secret of Building Effective Software Systems
2. Evolutionary Software Architecture or Why Developers Are Not Janitors
3. Do We Need Software Architects? 10 Reasons Why Not

What does a customer wants?

Usually your customer wants to know a simple thing – when your team will deliver working software based on agreed requirements. They naively want to safely bet on highly uncertain future outcome – delivery of the complex never created before system that completely fulfil their dreams.

The customer wants reliable McDonalds experience, but with a little tweak – they want to hand in their own exclusive menu, often created by people who don’t have any idea how to cook.

In short, the customer requires creative flexibility of Cooking Master Chef fortified by ability to predictably deliver hamburgers as McDonalds.

But, is it possible in our development reality to chase two opposing goals – Predictability and Flexibility in the same time?

Predictability vs Flexibility

The best way to achieve predictability is standardization – formalize process, nail-down rules, follow and optimize them mercilessly. However, standards have negative effects – lower morale, inhibited creativity, reduced flexibility and slower response to changes.

Rapid adaptation is the best way to to be flexible – eagerness to quickly regroup and self-organize to address new challenges and creatively solve new problems. However, constant changes and creativity sparks lead to unpredictable and ad-hoc results without much opportunity to stabilize and optimize delivery.

Standardization is a crystallized answer to past events – how to repeat effectively something that was solved before and proved to work.

Adaptation is the response to current events – how to embrace unforeseen requests, challenges and events.

Standardization has own cost – processes and rules should be maintained, reviewed and optimized otherwise they will become source of overhead, rigidity and frustration. But if there is no standardization, lessons and best practices could be lost or not followed.

It is difficult, but possible to chase these two contrary goals in the same time. Build standards to solve repeating problems and optimize recurring activities. Adapt to meet new challenges.

Team Maturity Matrix

Development teams have different capabilities to strike both predictable and flexible delivery.

• Amateurs – do even simple things… unpredictably
• Explorers – capable of solving complex non-standard problems, but cannot guarantee time and budget (Ph.D guys)
• Mechanics – very efficient with standard solutions, but struggle with new stuff (anal-retentive guys)
• Regulars – predictability of delivery lowers for more challenging problems
• Strike Force – deliver reliable results for any type of problem

Any team should grow from Amateur status, but rare team could become Strike Force that mastered both – predictable and flexible delivery. Than what direction of growth to choose? It depends on nature of projects and problems the team tackle.

Finding sweet spot

Predictable delivery requires reduced variations in development process: uniform, ordered and consistent approach with focus on high efficiency.

Flexible delivery requires increased variations in the process: enabling more options, wider range of responses to improve fitness in changing environment.

These 2 goals could compliment each other. Predictability (with standardization) could bring consistency and stability in volatile and evolving development ecosystem. Adaptation helps to improve and find better standards and ideas for established processes.

So, can team deliver as McDonalds, but using exclusive menu? Yes, if they not only excel in programming, but also excel in the way they work – persistently re-evaluating approaches and improving both predictability and flexibility.

There are three simple requirements for the team

1. Follow standards (minimal, adhering to principles)
2. Challenge standards (not relevant, rigid, impeding, excessive)
3. Introduce and Improve standards (from lessons learned, best practices, enhancing flexibility and value stream)

And you will build powerful development machine that continuously transforming to embrace fluid reality while keeping steadiness and predictability as McDonalds.

Related posts:

1. How to rescue failing software projects: The Toyota Way
2. The Elements of Pragmatic Programming Style. Composition.
3. The Secret of Building Effective Software Systems

Hit the road

Related posts:

1. Pair Programming: To Do or Not To Do
2. The Elements of Pragmatic Programming Style. Approach.
3. The Elements of Pragmatic Programming Style. Composition.

Related posts:

1. Programmers are lazy capricious pseudo-intellectuals. Really?
2. Three Dimensions of a Software Programmer: How to get things done
3. Five Big Personality Traits of a Programmer. Do They Matter?

A. Life Challenges and Systems

Your life continuously presents new challenges. And your success directly depends on your ability to meet these challenges. You can choose various approaches – react on problems as they come, appeal to supernatural forces or seek for advise.

But how many times

• you didn’t understand why thing happen and what to do
• you found that reality and challenges are more complex than they seem
• your solutions create new problems and make things worse

Welcome to the messy world of complex systems that encompass your life and compose our Universe.

1. You can be the master of your life if you can understand and influence systems involved in your challenges. That means that you should become the Master of Systems Thinking.

• what problems should you solve?
• should you reframe the problem?
• what would be an ideal solution?
• what systems should be considered?
• what belongs to these systems?
• what is out of scope?

2. Model – come up with a model that describe the problem and a preferable solution

• what is the structure of the involved system?
• what are goals and known system behavior?
• what system parameters can be influenced?
• what can be a solution – the system of responses and actions?
• what outcomes can be predicted?

• target feedback loops - amplify stale beneficial, minimize unstable harmful feedback (e.g. increase customer feedback, reduce team interruptions)
• stability - to remain unchanged, system should change: the system should effectively respond to various situations – even unknown!
• interconnections - you cannot change only one thing and you cannot change everything.
• beware of opposing reaction - The System always Kicks Back (Le Chatelier’s principle)
• avoid new systems - they always cause new problems
• evolve existing working solutions - it is better strategy than introducing new complex solutions
• the first solution is imperfect - be ready to scrap it after learning and building better models
• probe / stress test - try to run trial to assess impact of the changes before committing to intervention
• design signal / sensory systems for measuring result of intervention and establish clear information paths

4. Review results of intervention

• how well did intervention work?
• did you meet challenge or at least improved situation?
• did you create new problems?
• are you sure you’ve got objective and full information?
• have you got feedback from all participants?

5. Learn – analyze the gap between model and reality. Why did it work this way?

• studying mistakes and bugs
• evaluating prior predictions
• assessing assumptions
• dispelling delusions and biases
• exposing flaws of the model
• detaching yourself from the system for better perspective
• realizing real system goals, functions and interests (for humans)

Go to step 1 of the dance until you like results or run out of time and energy.

Finally remember: “Today solutions are tomorrow problems” [Fifth Discipline]

E. Circle of Influence

5. Focus on important challenges that you can really meet.

Proactive people focus time and energy on things they can control (Circle of Influence) instead of reacting to or worrying about conditions over which they have little or no control (Circle of Concern). – Stephen Convey

1. You can be the master of your life if you can understand and influence systems involved in your challenges. That means that you should become the Master of Systems Thinking.
2. Ability to predict and influence future is the most important skill of the Master of Systems Thinking
3. Inability to understand systems is the most serious obstacle for the Master of Systems Thinking. Unfortunately, most systems are complex and the master will not understand them.
4. You can still master complex systems if you realize that you cannot change complex systems as you wish and get predictable results.
5. Focus on important challenges that you can really meet.

You cannot change Universe laws and can barely affect economical situation, but you can make a difference for your projects and life by becoming the Master of Systems Thinking and mastering systems under your control.

Related posts:

1. How to become an Expert. Embrace Reality.
2. The Secret of Building Effective Software Systems
3. How to Become an Expert. The Effective Way.

Seasoned project managers will tell that delivery of software is result of many trade offs. The main trade off is between Time (when project will finish) and Scope (how much will be done). This post will show that using right tools you could gain improvement for both variables.

While it is possible to create orderly step-by-step process for increasing productivity of software teams, it will never be ideal – too many variations and situations will hinder it usefulness. I believe in set of useful tool that could be combined to craft custom optimal solution.

Strategies

There are several strategies that lead to increase in productivity – how many units of scope software team can produce within fixed time.

1. Increase Capacity (Capacity) - increase capacity by hiring more people or increasing work hours
   • productivity is increased as result of more resources and hours available
2. Improve Value Stream (Value) - increase added business value on each step and reduce waste and overhead
   • productivity is increased as result of optimized delivery of value
3. Adaptat to Reality  (Adaptation)- learn from practice and mistakes, validation of ideas by reality, adapt to changing situation
   • productivity increased as result of early corrections and improving how things are done
4. Empower Individuals (Individuals) - boost people knowledge, skills, morale and focus
   • productivity is increased as result of higher individual performance and motivation
5. Enhance Communication (Communication) - improve communication and mutual understanding inside and outside of the team
   • productivity is increased as result of availability of necessary information, clarity of what should be done and exchange of ideas for implementation
6. Organize Better (Organization)-  structure team and assign roles for better coordination and decision making
   • productivity is increased as result of better decisions and focus on important areas
7. Expand Expertise (Expertise) - increase range of skills and services offered by team
   • productivity is increased as result of better execution of necessary project activities
8. Scale Externally (Externality)- outsourcing and involvement of external communities
   • productivity is increased as result of involvement of more people outside of team
9. Tame Complexity (Design)- manage complexity and provide simple and well designed solutions
   • productivity is increased as result of reducing complexity burden on software development
10. Preserve Quality (Quality)- use defensive tactics to ensure high quality
    • productivity is increased as result of preventing system flaws and reduced effort to fix bugs

• People-oriented – people are the creators of software and have major effect on output
• Process-oriented – the way how people work has significant impact on outcome
• Development-oriented – development practices and approach to the system implementation matters a lot

People-oriented tools

Strategies: Capacity , Expertise , Communication ,  Organization

New people increase volume of possible work within the same time and new expertise increases range and quality of tasks. However, the increase in output is not linear and quickly diminishes, because more people cause communication and coordination overhead. In addition, compensation increase make this tool expensive and less attractive.

Resources:

• Methodology and Team Size, Alistair Cockburn
• Team Size Matters, schmula

2. Motivate

Strategies: Individuals , Quality

Happy motivated people are more productive, focused and concerned about quality and end result. While there is no common receipt for each individual, I believe there are some strong motivators: interesting and meaningful work, fair compensation, control over own tasks and outcomes, ability to learn and professionally grow, comfortable workplace and adequate tools, empathetical and caring management and so on.
Daniel H. Pink in Drive thinks that people are motivated by three elements:

• Autonomy: People want to have control over their work.
• Mastery: People want to get better at what they do.
• Purpose: People want to be part of something that is bigger than they are.

• Professional Growth

Tips: Motivate individually, but set also group targets to encourage cooperation

• Drive, Daniel H. Pink
• The Ideal Software Company. Utopia?

3. Professional Growth

Strategies: Individuals , Expertise , Quality , Adaptation

Software professionals should learn a lot to become productive and proficient. People learn in several ways and learning from mistakes is the most memorable, but expensive way. Learning by self-study, formal training and coaching by experienced colleagues are more effective ways. Encourage and direct learning to grow high performance experts and team. And certainly, continue learning as much as possible from mistakes and practice.

• How to Become an Expert. Top 7 Qualities
• How to Become an Expert. The Effective Way

4. Overtime

Strategies: Capacity , Individuals , Quality

Nobody recommends involuntary overtime for a long time as benefits will disappear quickly when a stressed team lowers quality and starts breaking apart.

5. Right leaders

Strategies: Communication , Organization

Good leaders jell teams, align people with goals, boost energy and remove barriers. Leaders vary from commanders to visionaries and each style has merits under specific circumstances. Right leaders are essential for the project success.

Tips: Adjust leadership style to situation

• What is The Best Leadership Style for The Software Team?

Strategies: Expertise , Organization

A software team requires range of skills and involved in different activities to achieve end goal – implemented software system for customer needs. Beyond software implementation the team deals with a customer domain, company vision, market demands, technologies, operation environments and other project aspects. The team is involved in research, analysis, coordination, design, architecture, usability, testing, deployment, hosting and other activities. Therefore team players should be able to play different roles and have expertise to cover various aspects to ensure good end results.

Resources:

• Why specialization in Software development is bad for business

Strategies: Capacity , Expertise , Externality , Organization , Communication

Tasks and challenges should match skills and experience of team players. It doesn’t make sense for backend developers to convert Photoshop files into html or conduct marketing research and focus groups. If team cannot afford to hire a permanent specialist, they should try to find professional mercenaries who will do work faster on higher quality level.

Strategies: Individuals

Flow (or Immersion) is a state of mental focus so intense that awareness of the real world is lost, generally resulting in a feeling of joy and satisfaction. When learning and tasks are too easy, people become bored. If they are too complex they become stressed and frustrated. Flow happens when perception and understanding are challenged near capacity without being exceeded.

• ability to focus
• clear goals
• immediate feedback
• control over actions, activities and the environment

• Flow: The Psychology of Optimal Experience, Mihaly Csikszentmihalyi

Strategies: Quality , Organization , Individuals

Few people will be always disciplined no matter what and few will always violate rules. Majority are context sensitive – relax than discipline is low and work hard when discipline is enforced. Build a minimal set of rules approved by majority and stick to these rules.

Resources:

• Lost Personalities: How our company alters us

Process-oriented tools

10. Increase feedback and early practical use of ideas

Strategies: Adaptation , Quality , Value

Reality is complex, fluid and unclear. Many assumptions and plans quickly go bust. The process that has built-in mechanism for signaling problems and self-correction is the most effective. Rapid feedback is the core part of such process.

Tips: Iterative development is one of the best examples of the process that relies heavily on feedback.

11. Build alignment

Strategies: Communication , Organization

People jump significant gaps to understand each other – sometimes without much success. Clear vision, smart priorities and honest evaluation allow team players moving in unison and enforce each other. Good understanding focus people on right goals and reduce wasteful activities. Communication and trust are important for alignment.

• vision – project direction and top-level goals
• interests – mix of personal, customer and companies interests (sometimes conflicting)
• understanding – clarity about what others mean
• trust – confidence in other people intentions and promises

12. Integrated decision making

Strategies: Communication , Quality , Adaptation

See Also:

• Self-organization

As project progresses you will find problems, wrong assumptions and challenges. You will have better experience and understanding. Even brightest ideas, best practices and excellent analysis and design could become outdated and ineffective. Continuously look for improvements, eliminate waste and bottlenecks.

Resources:

• How to rescue failing software projects: The Toyota Way
• Theory of Constraints
• Kaizen

Strategies: Individuals , Quality , Value

Highly productive team shouldn’t waste time on routine or non-core activities. Routine work should be automated and non-core work outsourced or covered by external components. The team should focus on high value-added distinctive work for business and application domain – this will bring maximum business results with minimal development effort.

• system thinking
• understanding what really matters and what are limitations
• broad vision and out-of-the box thinking
• knowledge of environment, context and system outside relations
• synthesis of concepts, information and experience

Strategies: Capacity , Expertise , Externality , Organization

Strategies: Value , Communication

You can better understand and change scope of application if you actively work with customers and become partners

• establish ubiquitous language – for better understanding of ideas and translation them into code
• tap into experience and get better insight for business domain and processes
• transform ideas – simplify and find better alternatives

• reducing scope
• simplifying solutions
• finding good enough alternatives

• Pareto Principle
• Ubiquitous Language
• Software Development is The Flow of Ideas. The Rest is Secondary

18. Select Right Process Flow

Strategies: Organization , Value

Select most optimal process for creating value.

• real-time flow –  immediately push tasks for implementation (continuous development flow for highly organized co-located teams)
• pull systems (Kanban) – pull tasks when previous batch is finished and the team is ready to continue (iterations and backlog)
• schedule the workload (Heijunka) – create schedule for contributors with limited availability (outside consultants or shared specialists as designers)

Tips: Use different flows for distinct stages of software creation. For example, a team process can internally use real-time flow, with external teams – Kanban and with consultants Heijunka.

Resources:

• The Toyota Way and Development Process

19. Self-Organization
Strategies: Communication , Individuals , Adaptation , Value

Tips: Not every team can self-organize – it requires maturity. And loss of direct control could be a problem for management if a project departs from company strategy and desired parameters (as budget, standards, resources).

• What is The Best Leadership Style for The Software Team?
• Organizing Self-organizing Teams
• Agile Self-Organizing Teams

Development-oriented tools

20. Increase reuse

Strategies: Design , Quality , Adaptation

Reuse code  (components, libraries, solutions) as much as possible to speed up development and minimize code base. Reuse will bring familiar tested solutions and prevent frequent re-inventions of the wheel.

See Also:

Tips: Design for reuse requires skills and time. It is easy to overly complicate the system by pursuing reusable code. Evolve and refactor code to achieve practically good reusability. Sometimes custome solutions are lighter and better suited for specific purposes than generic and reusable.

21. Generalize and Simplify
Strategies: Design , Quality , Communication

Complexity and poor understanding of the system is one of the worst problems in development. Design, code and concepts should be as simple as possible and clearly understood by the team. Simplicity and clarity are difficult to achieve and require special effort. It is much easier to produce convoluted over-engineered solution for complex problem (Ball of Mud) than simple and elegant solution.

Tips: Great design achieve simplicity by abstracting numerous details into simple concepts in process of solution evolution and learning from implementation.

• Big Ball of Mud, Brian Foote
• 11 Laws of The System Thinking in Software Development
• The Elements of Pragmatic Programming Style. Approach.

Innovation is expensive, uncertain and leave you with custom solutions on your own for support and future development. Piggyback on actively involving products, especially for non-core problems where good and proven solutions are available.Tips: Innovate to gain business advantage or solve serious technical challenges if you have an outstanding team and well-defined problems.

Resources:

• Should An Effective Developer Innovate, Imitate or just Integrate?
• Selecting The Best Strategy for Software Teams: Retreat, Evolution or Revolution

23. Domain Specific Design

Strategies: Design , Communication

Keep technical ideas and code concepts close to the customer domain. You will achieve consistency, better sync between system and business concepts. You can easier translate customer ideas into the system and customers will understand your implementation better.Tips: Domain Driven Designis one the best approaches to achieve synthesis of technical and business ideas for complex domains.

Resources:

• Domain Driven Design, Eric Evans
• The Secret of Building Effective Software Systems
• The Elements of Pragmatic Programming Style. Composition.

24. Evolution

Strategies: Adaptation , Value , Design

Start with the simplest primitive solutions, enforce early use and seek for feedback. Adjust and improve design before continuing adding new features. Look for better ideas and abstractions. Delay fundamental design decisions until you are confident about system development direction and validated ideas on practice. Do not over-engineer and add unnecessary features.

Tips: Evolution main deficiency is slowness. Modern businesses often don’t have time for many improvement cycles – they want results now.

Resources:

• What can Software Development learn from Biological Evolution?
• Ideas in Software Development: Revolution vs. Evolution. Part 1.

• How a beautiful software system becomes Frankenstein

25. Open architecture and API

Strategies: Externality , Design

Open your solution for external developers who can extend and add more useful features. If you are lucky, you will get much more functionality than you can build internally while still controlling a core solution (iPhone is a perfect example).

Also Open API (convenient and supported by good documentation) give developers eligible ways to interact with you system without hacking or completely ignoring it.

Tips: Once Open API is used it becomes liability – next design decisions will be affected by compatibility and legacy concerns.
Resources:

• API

26. Follow Design Principles

Strategies: Design

Some of design principles

• You should be able to extend system without modifying it
• A class should have one, and only one, reason to change
• Depend on abstractions, not on concretions.
• Make fine grained interfaces that are client specific.

Famous design patterns are built around these principles. Follow sound design principles to build flexible, easy to expand system.

Resources:

• Principles of OOD, Rob Martin
• The Elements of Pragmatic Programming Style. Approach.
• The Elements of Pragmatic Programming Style. Composition.

27. Shared Code, Ideas and Standards

Strategies: Design , Expertise , Communication , Quality

The team should collectively own code and pursue consistency and use of best practices. Otherwise the system will become clash of isolated impassible code islands – scary for people who didn’t build them. Share code and learn from each other to build outstanding system with high quality and integrity of every component.

Tips: Pair Programming is one the best ways to share code, ideas and best practices
Resources:

• Collective Code Ownership
• Pair Programming

 

28. Use Better technology and tools

Strategies: Individuals , Design , Value

Tips: Obsession with new technologies and race to use them is dangerous for project. Keep sanity until new technology is proven to be beneficial

• http://www.sdtimes.com
• http://www.computerworld.com

Guide for increasing team productivity

Questions

Related posts:

1. The Secret of Building Effective Software Systems
2. How to rescue failing software projects: The Toyota Way
3. Comparing Intelligent Software Evolution to Chaotic Biological Evolution

What is the best strategy for an effective developer – innovation, imitation or integration? Should you introduce new creative solutions, adapt other people ideas or just integrate existing components?

Software Development is an exciting intellectual endeavor without physical barriers. It is easy to start innovating – come up with new ideas and quickly submerge into their implementation. And I don’t mean here fundamental breakthroughs. I consider as innovation building of any non-trivial solution that is not directly stemmed from Google search results, development resources or available examples. And certainly, I pose the dilemma – innovate or not innovate – to skillful developers who are quite capable to innovate and who enjoy meaningful creative work.

Discount Machine

Lets start from a tournament organized by Kevin Laland of the University of St Andrews to find out what strategy works best to gain maximum pay-off:

• innovation - a new behaviour randomly acquired by individual learning;
• observation - a new behaviour acquired by learning from others or imitation;
• exploitation - using a previously learned behaviour to gain pay-off.

The participant had to build a strategy that their virtual agents would use to decide between these options in a computer-generated world. The challenge was to create the strategy that generated the most successful agents.

Therefore, a tournament showed that the best strategy is keeping up-to-date by learning what others are doing and using their successful solutions most of the time.

Strategies

You have three main strategies for approaching a new problem in software development

1. Integrate into the system existing software product, component or service – commercial or open source (for example, Payment Gateway as PayPal, Blog Engine as WordPress, CMS as Drupal, UI Components as Telerik and so on)
2. Imitate good enough solutions and adapt to your problem (Architecture Patterns as MVC, available code examples and guidelines as MSDN, borrow ideas from blogs, open source projects, Starter Kits, SDK and so on)
3. Innovate and create new solutions or make significant improvements to existing approaches

	Integrate	Imitate	Innovate
Time to market	Fast, if effort to integrate with other system components is low	Slow, but predictable, if not many hidden pitfalls or adaptation problems are encountered	Unpredictable as any innovative work
Cost	Low, if components are reasonably priced and not much integration work needed	More expensive and depends on complexity and adaptation effort	Unpredictable
System integrity (with system architecture and environment)	Acceptable if new components don’t screw and over-complicate core architecture	Good, if developers adapt ideas to existing architecture	Solution is built to match core architecture and customer needs
Required Expertise	Not much specialized expertise is required, usually external support is available for integration	Good developers can effectively adopt good ideas that are explained well	High level expertise, creativity and specialized knowledge are required for good innovative solution
Control over code and future development	Little control and you are on mercy of external developers	Good control if ideas are applied well and not over-engineered	Full control
Competitive advantage and uniqueness	Not much for the standard solution that many can use	Depends on quality and creativity in adaptation	Innovation is an excellent opportunity to gain advantage
Maintenance, support and improving capabilities	Work is outsourced to dedicated external developers who fix, support and improve the product	Your effort is supported in original source of ideas if you are lucky	Completely your own effort
Learning curve, tacit knowledge, help	Usually supported by help, tutorials, training and community involvement	Partially supported by original source, however can drift far as the result of internal implementation	Should be covered by you to enable effective support and future development by existing and new developers

(*) Disclosure: I should confess that the table above has some assumptions. I assume that external components for integration have good quality, work as advertised and are backed by solid support and team . Also, I assume that internal developers involved in implementation have good skills and experience. They follow good practices and are motivated to do great job and know what they are doing. I fully realize that life is not simple, and my assumptions could be completely wrong and this would change the table and the whole game

• Improvement and simplification of the system design to make it easier to evolve and support
• Removing technical constraints and solving technical challenges to make the system faster, more responsive and reliable
• Introduction of important business features where no standard solutions exists
• Significant improvement of users experience
• Reducing cost of development and support

• Developing system features or properties that are not required
• Building alternatives for good available solutions (reinventing the wheel)
• Playing with interesting ideas without customer awareness

The Effective Way To Build Software System

1. Understand purpose of the system, essence of customer needs and desired outcome
2. Break downthe system into components and research if
   1. standard solutions exist (for integration)
   2. implementation ideas exist (for imitation)
   3. innovation is required
3. Can you change needs and requirements? Transform customer needs and architecture ideas to minimize development effort
   1. by moving from innovation to imitation strategy
   2. by moving from imitation to integration strategy
4. Evaluateeach component from the system and business perspective
   1. Should you avoid integration and use imitation if:
      • System integrity under the threat and the component is part of the system core
      • Control over code and future development is required
      • Competitive advantage and uniqueness are important
   2. Should you still go with innovation because of unresolved contradictions, challenging and unmet needs?
5. Build prototypes clearly separated from mainstream development to confirm selected strategy

Becoming an effective software developer

1. Systematically study other solutions in your area of specialization (at least a couple in a month – understand strengths, weaknesses, high-level architecture and interesting tricks)
2. Learn concepts and language of your business domain to be able to understand customers and shape their needs together
3. Enhance abilities to find and brainstorm alternatives (improve techniques, make them essential part of your process)
4. Become an expert in Google search and fast evaluation (no kidding, these skills become very important for any modern developer)
5. Master rapid prototyping, apply solutions in practice and seek for rapid feedback (answer in short time if proposed solution is good, learn and correct if you made a mistake)
6. Develop a holistic view and knowledge of the system, infrastructure and environment (understand subsystems, connections, integration options and trade-offs)
7. Keep up with latest software development trends, technologies and approaches (subscribe to blogs, magazines and other sources)

1. Achieve deep specialization in your core technical area and business domain (extensive experience and deep knowledge are great assets for innovator)
2. Continuously develop creativity and problem solving (the post about creative problem solving)
3. Enhance architecture and fundamental programming expertise based on own practice and ideas from others
4. Master Evolutionary and Domain Driven Design

Related posts:

1. The Secret of Building Effective Software Systems
2. How to Become an Expert. The Effective Way.
3. How to become an Expert. Embrace Reality.

• Improving relationship
• Flying to space to be the first man on Mars
• Overweighting and health problems
• Winning bodybuilding or beauty contest.
• Procrastination
• Learning new technology
• Making more money
• Building next Facebook or Twitter
• Raising kids
• Boosting career growth
• Becoming Olympic champion or billionaire
• Making the world a better place
• Planning a dream vacation
• Seeking for happiness…

We often are inconsistent in solving problems and cannot find a good solution. This post focus on effective and creative problem solving by offering systematic approach and wide range of techniques.

Beginning

There are four main elements of Creative Problem Solving:

1. Problem - any question or matter involving doubt, uncertainty or difficulty
2. Solution - set of actions that solves a problem
3. You – your knowledge, beliefs, emotions and abilities
4. Context -forces, people and environment

And there are seven strategies:

1. Knowing - you know how to solve the problem in practice
2. Copying – copy and adapt working solutions
3. Logic - follow reasoning and step-by-step approach to find a solution
4. Lateral thinking - solving problems through an indirect and creative approach
5. Psychology - use intuition and subconscious to pop a solution
6. Dialogue - engage brains of other people
7. Trial and errors - make guess, verify and refine by experiments

Before you start finding a solution, you should board the problem – understand and accept it.

Boarding a problem in 3 steps

Step 1. What is the core of the problem?

• Essentials - What are symptoms, facts, key points, players, context?
• Root Conflict - Why is this a problem? What is the core of a problem? What is not a problem? Ask 5 whys
• Clarity - What is still unknown and unclear? Do I need more information?

• Feasible - Is the problem real and you can solve it? Continue by asking critical questions about the problem
  • Is it logical? Does the problem make sense for the rational part of my brain?
  • Is it subjective? Is it possible that problem exist only in my mind?
  • What are emotions and feelings? How do they contribute to my perception of the problem?
  • Is the problem based on hard facts and proven information?
• Fit - Why is it necessary to solve? Should I really solve this problem based on my
  • needs
  • priorities
  • values and principles
  • resources (time / money)
  • potential benefits / risks?

• Purpose - what is the purpose of solving the problem?
• Stretch - should I solve bigger problem?
• Squeeze - should I solve only part of the problem?
• Model - what are elements and parameters of the problem? What are forces?
• Question - use CIA Phoenix checklist of problem solving questions

Ideal solution

• Find contradictions that can be resolved - I want more money, but also want to work less and impossible - I have to be in two places in the same time. Use them as a creative stimulus to define an ideal solution.
• Understand when you can stop, what is good enough outcome and how much time, energy and money you are willing to spend on resolving a problem
• What are potential harms and cost of the solution?

Knowing

1. Is the situation same?
2. Should you improve or change something from your previous solution?
3. Can you come up with better alternatives?

Copying

1. Can you trust sources? Do they provide full unbiased information?
2. Do you pay attention not only to glorious outcomes of the solution, but also to problems?
3. Can you use this solution for your specific problem, situation and abilities?

Logic

Reorganize - break down the problem into elements or parameters and manipulate them. You can use SCAMPER method defined by Bob Eberle. (Example: a problem with failing relationship)

• S - Substitute - components, materials, people
  • substitute something in your behavior or find another partner
• C - Combine - mix, combine with other assemblies or services, integrate
  • start doing some things together
• A - Adapt - alter, change function, use part of another element
  • change your home responsibilities
• M - Modify - increase or reduce in scale, change shape, modify attributes (e.g. colour)
  • communicate more often, change your tone
• P - Put to another use
  • use your partner as a tennis or chess opponent, engage as an assistant in fishing
• E - Eliminate - remove elements, simplify, reduce to core functionality
  • separate or stop doing things that annoy your partner
• R - Reverse - turn inside out or upside down
  • say opposite to what you said before

• Think about a specific topic you want to cover. Find out how people start blogs in general, what works and what are common pitfalls. Apply to your topic and situation to grow successful blog.

Analyze Variations (Example: Develop and promote new Content Management System)

1. Parameters of a problem - list variations, combine differently
   • cost, time, features, people, quality, vendors, etc; time vs features, in-house vs outsourcing, quality vs speed
2. Attributes list - list attributes of the object (or problem) and try to improve them (Attributes analysis, Morphological Analysis)
   • architecture, design, performance, scalability, security, reusability, networking
3. Matrix - create related keywords in main areas, mix and match keywords to form new ideas (Leonardo da Vinci Ideabox)
   • solutions (blog, company website, e-commerce, news, social connections), needs (inform, advertise, sell, support), markets (individuals, companies, non-profit, schools, small social groups), technologies (web, video, mobile, aggregation), services (hosting, installation, support, training). For example, what could be opportunity in combination: blog + inform + schools + video + hosting

Change Context / Process / Forces (Example: Career advance)

1. Force field analysis - maximize positive forces, minimize negative (Force-Field Analysis)
   • find how to use your strengths more and avoid negative impact of weaknesses
2. Substitute rules, principles, people, places
   • change job responsibilities or job itself
3. Anti-action - compensate harmful effect by specific action
   • minimize overtime or uninteresting work by changing how you accept your tasks
4. Preliminary action - pre-arrange or change problem context in advance
   • build consensus with potential opponents before important meeting
5. Theory of Constraints - find the worst bottleneck and improve until it is no longer a bottleneck, continue with the next bottleneck (Theory of Constraints)
   • find what are limiting factors of your growth, work on reducing their impact and increase your abilities and potential
6. Eliminate waste
   • eliminate wasteful activities at work to boost your productivity
7. Lemonade from Lemons - use waste or harmful effect to achieve a positive effect
   • learn from your mistakes and use them to improve and become better next time. As Friedrich Nietzsche said: “What doesn’t kill us makes us stronger.”
8. Feedback - introduce or increase feedback to improve action or process
   • seek for feedback and objective evaluation of your performance to advance faster by fixing your shortcomings

Explore future scenarios - project future scenarios to find unexpected opportunities (Alternative Scenarios) (Example: Deciding where to invest money)
“The best way to predict the future is to invent it” – Alan Kay

1. Identify forces
   • identify current economic forces and your personal situation
2. Come up with 4-5 scenarios - good and bad
   • what could happen in the future with both economic and you?
3. Search big opportunities in each
   • find how you can benefit from investment in each of scenario

Lateral thinking (Creative Spark)

Challenge assumptions, break away from obvious perspectives (Assumption Busting) (Example: Raising troubled teenager)
“The significant problems we face cannot be solved at the same level of thinking we were at when we created them. “ – Albert Einstein

1. Expose and challenge all assumptions
   • challenge your beliefs about role of a parent
2. Reverse problem in some way (Reversal)
   • praise for something you was punishing before
3. Paradox - opposites exist simultaneously (True and False)
   • accept that you and your teenager are both right about controversial topic. Try to negotiate from this position
4. Provocation - wishful thinking, thought experiments
   • unleash your imagination, go for crazy ideas about solving a problem
5. Changing viewpoint - think from different perspective (Six hats)
   • imagine that you are a bird or live in another time. How would you resolve your relations with kid?
6. Finally, challenge any part of the problem – ask why for anything

Force Associations (Example: Starting your own software business)
“Creativity is the power to connect the seemingly unconnected” – William Plomer

1. Random keywords - select any word from dictionary and try to connect to your problem (Random Words)
   • For example, how a tree can be related to your new business?
2. Words of great thinkers - use their quotes and wisdom to associate with a problem.
   • For example, how can Oscar Wilde’s quote: “Be yourself; everyone else is already taken” helps with business ideas?
3. Free associating with common attributes - select 12 attributes, choose random 2, consider separating and combined (Combinatory Play)
   • break down into areas – finances, sales, development, clients, technology, usability, etc. Start pairing randomly
4. Metaphors - similarities and connections of your problem with other distant area
   • How analogies of railroad or tropical forest can help with business idea
5. Hieroglyphs - use Egyptian hieroglyphs to associate with your problem
   • arrange randomly hieroglyphs from The Book of Dead to find clues for creating business

Visual clues (Example: Designing web user interface for the new complex domain)

1. Diagram to explore, organize and analyze (Lotus Blossom, Mind Map, Concept Fan)
   1. Explore – search for new areas that can be related to the problem
   2. Organize – put together as one picture what you know about the problem
   3. Analyze – go deep into a problem to find missing details and relations
   • Draw these 3 types of diagram for web site and business domain: put web site purpose in the center, start drawing branches for big ideas and aspects, branch for smaller and so on
     
2. Draw and link abstract symbols for attributes
   • create symbols for web patterns and business concepts, shuffle and find ideas in random associations
3. Drawing - draw anything that can be related to your problem; lets your subconscious drive your hand (Doodling)
   • just draw any screen ideas

Psychological tools

“Everything you can imagine is real.” – Pablo Picasso

Use intuition and subconscious to find answers. Our subconscious is a large scene where conscious thought is a spotlight. Try to elicit ideas from these dark corners of the most powerful part of your mind. (Example: Finding new kicking-ass website idea)

1. Intuition - ask and listen to your intuition
   • come up with website ideas without thinking
2. Incubation - best ideas come than you don’t expect them, just don’t miss them
   • deeply dig into a problem, put into your mind and forget, and probably soon you will jump from the bath and run to the street screaming ‘eureka!’
3. Fantasies - unleash unreal or crazy questions, suspend judgment and answer them (Crazy Ideas)
   • what if you build site for aliens? now you can think about usability for complete dummies, space design, navigation as a star system, etc.
4. Dreaming - capture ideas from dreams
   • set questions before you sleep, try to recover answers from dreams immediately after you wake up
5. Drink beer - to slip into different mind state. I don’t suggest becoming drunk or use something stronger or illegal
   • drink and start thinking about website, don’t foget to record your thoughts early enough
6. Surrealistic images - find association of hypnogogic imagery with your challenges
   • relax, quiet mind and eyes, become almost unconscious- record experiences immediately after they occur
7. Guided imaginary scenarios to find ideas in unexpected places (Imaginary Excursion)
   • choose scenario (e.g. going to camp and lost in the forest) and while you experience the journey in the head, search for clues
8. Psychosynthesis - spiritual advisers (Role-playing)
   • invite Bill Gates, Sigmund Freud or Karl Marx to talk with you inside your head about the kicking-ass website
9. Streaming - writing out what is in your mind to associate later with the problem
   • hide in a comfortable place and start writing – smart thoughts or gibberish. Find how it could be related to the new website later.

Dialogue

1. Talk with strangers
   • ask about vacation ideas people you don’t communicate often and you’ll get plenty of new ideas
2. Brainstorming - exchange ideas and suggestions without judgment, evaluate and revise ideas later (KJ Brainstorming)
   • ask group of people to generate as many as possible vacation ideas without discussion
3. Brainwriting - parallel generation of ideas in silence (index cards); exchange and develop each other ideas in turn (Brainwriting)
   • everybody in group writes vacation idea on card, give to the next in circle who continue refining this idea
4. Survey - collect ideas from large group of people (Crawford Slip Method, Delphi method)
   • post survey (e.g. Facebook or surveymonkey.com) for vacation ideas
5. Storyboarding - put ideas on the wall as a group works out problems
   • post vacation ideas on the wall and let anybody to contribute (add or extend idea)
6. Socratic dialogue - have a conversation with a smart person and probe various dimensions of thinking: purpose, evidence, reasons, data, claims, beliefs, interpretations, deductions, conclusions, the implications and consequences of thought, response to alternative thinking from contrasting points of view, and so on.
   

Trials and Errors

Solving a problem by trial and error is an expensive, but reliable way to find a solution. In science it called scientific method. Most scientific discoveries are done using this method. (Example: Becoming happy)

1. Ask a Question
   • form a problem statement – what is happiness for you?
2. Do Background Research
   • learn what other people think about happiness
3. Construct a Hypothesis
   • what could make you happy?
4. Test Your Hypothesis by Doing an Experiment
   • try your ideas in practice
5. Analyze Your Data and Draw a Conclusion
   • are you happy now? should you change a hypothesis and start again?
     
6. Communicate Your Results
   • share your results – help other people to become happier

Summary

Your life success depends on your ability to choose right problems and solve them. Do not give up or settle for an ineffective solution. Use the power of your mind to creatively solve problems the best way possible. Control your life.

“He is able who thinks he is able” -Buddha

References

• Thinkertoys: a handbook of creative-thinking techniques, Michael Michalko
• http://www.mycoted.com/Category:Creativity_Techniques
• http://creatingminds.org/
• http://www.mindtools.com/pages/main/newMN_CT.htm
• http://www.creativethinking.net/WP03_Techniques.htm

Related posts:

1. How to Become an Expert. The Effective Way.
2. How to become an Expert. Embrace Reality.
3. How to Become an Expert. Top 7 Qualities