Agile Data Science

Agile based processes have proven to deliver valuable and high quality traditional software based solutions to business users in a timely manner. Over the last few years, data science related projects are becoming more and more important in every industry. Software engineering has tried different development methodologies - waterfall, Scrum, XP, etc. and data science can learn from the experiences of the software engineering. 

In this post, I will try to identify the most important and applicable values, principles and practices from agile that can be used in a typical data science project. We will start with a brief overview of software engineering, agile, data science and conclude with some recommendations on how to incorporate agile into data science projects.

Software Engineering

Before agile or iterative software development methodologies, software engineering projects typically followed waterfall approach where activities are scheduled one after the other. If during testing or after deployment if the product was found not to meet the expectations of the business users, the whole process is repeated in sequence.

Waterfall Approach

Because of the sequential nature of the waterfall approach, the individual roles of the team members are fixed.

Agile

In agile development methodologies[1,2], teams go through the traditional software engineering activities in a time boxed (typically 2 weeks) iteration and a software project will have multiple such iterations. What's different from the waterfall approach is that at the end of every iteration, the team delivers/deploys something of value to the business. This allows for the business and team to make adjustments along the way while delivering something of value every iteration.

Iterative Agile Approach

Agile teams are cross functional in nature having all skills required to deliver and deploy a working software product. Also, there is a flexibility in individual roles with team members playing multiple roles as needed by the team.

Data Science 

A typical data science project, goes through following stages. Just like in traditional software engineering projects, there is a tendency to do these activities in sequence: acquire/prepare/cleanse all data needed before exploring data or building models. 

Typical Data Science Pipeline

Though the Cross Industry Standard Process for Data Mining (CRISP-DM)[5] was developed 20 years ago, its concepts and phases are still relevant for data science projects. Microsoft is defining a team process for data science that's based on CRISP-DM[7]. Though CRISP-DM does talk about these phases are cyclical in nature but some projects may end up following them in a sequential and waterfall approach.

CRISP-DM Process Diagram by Kenneth Jensen

Roger Peng talks about iterative process that is applied to all steps of the data analysis in his "Epicycles of Analysis" [8].

From The Art of Data Science, Roger D. Peng and Elizabeth Matsui

Similarly, there have been attempts to define values and principles for data science [3, 6] similar to agile values and principles [1].

Agile Data Science

"In preparing for battle, I have always found that plans are useless, but planning is indispensable." 

–General Dwight D. Eisenhower 

Though software engineering and data science are two different disciplines with each requiring different set of skills, one could draw parallels between software engineering and data science. Most of the data science project deliverables can be considered as data products offering insights for the business stakeholder. Data science projects are typically non-linear in nature, one may learn something along the way that requires changes. Agile methodologies have built in practices and process to allow for such changes. 

Values

Values are fundamental and are guidelines for the behavior of team members. Agile manifesto [1] values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Data Science manifesto [2] values:

• Minimal Viable Products over prototypes
• APIs over databases
• Clever use of computation over convenient assumptions
• Dashboards over reports
• Validation, scrutiny and repeatability over convention and ad verecundiam 

Important values to focus on:

• The concept of Minimal Viable Data Product (MVDP similar to MVP in Software Engineering) that is working and delivering insight/value to business is something that's central and important. 
• Reproducibility which allows independent validation is critical to data science projects. 
• Working model 
• Collaborate and interact with end user frequently
• Plan ahead but accept change
• Automate as much as possible

Minimal Viable Product (MVP)

Principles

Principles can be described as rules or "truths", arising from experience, knowledge, and (often) values. Principles are guides to behavior.

Agile principles[2]:

• Satisfy the customer through early and continuous delivery.
• Welcome changing requirements
• Deliver working software frequently
• Business people and developers must work together
• Build projects around motivated individuals
• Team face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development
• Technical excellence  and good design enhances agility.
• Simplicity--the art of maximizing the amount  of work not done--is essential.
• The best architectures, requirements, and designs  emerge from self-organizing teams.
• Reflect at regular intervals.

Data Science principles[2]:

• Aim to completely remove manual intervention (automate).
• Data science is about solving problems, not models or algorithms.
• All validation of data, hypotheses and performance should be tracked, reviewed and automated.
• Prior to building a model, construct an evaluation framework with end-to-end business focused acceptance criteria.
• A product needs a pool of measures to evaluate its quality. 
• Even research can be broken down into clearly defined tasks. 
• Don’t neglect assumptions in models. 

Some important principles to adopt:

• Reflect at regular intervals and adjust
• Automate as much as possible
• Focus and solve business problems
• Deliver and demonstrate working models frequently
• Simplicity in design and models
• Accept change and learn

Practices

Agile methodologies strongly recommend good team and engineering practices that allow principles and values being acted and followed. 

Product, Sprint (Iteration) Backlog

Agile practices:

• Time boxed iteration (or sprint of 2/4 weeks) to deliver working model that provides value
• Backlog of priority items to work on next
• Review backlog frequently to prioritize
• Iteration planning 
• Daily stand up - quick 10 minute review of progress and any blocks
• Team board to show status
• Source control and continuous check ins to allow other team members to use one's work
• Automated builds
• Continuous deployment
• Work in pairs (four set of eyes)
• Iteration retrospective to review what worked and what didn't work

Data science project will definitely benefit by implementing some of the agile practices:

• Source control with hosted Notebooks
• Backlog of priority items
• Regular review of iteration (daily)
• End of iteration retrospective
• Status board to show team's progress
• Automated processes for builds, deployments
• Snapshots/versions of data (training data, test data)

Tools

• Source control (Git, SVN)
• Agile process tools like JIRA
• Notebooks (e.g., R Notebook, Jupyter Python Notebook, Zeppelin) are good for self-documentation, reproducibility with code and also with visualizations that both data scientists and business users have access to. Hosted notebooks are preferred.
• Good data pipeline engineering platforms/workbenches for big data platforms (e.g., CASK, Cloudera, Trifacta)

References

1. Agile Manifesto: Values and Principles
2. Agile Principles and Values, by Jeff Sutherland, MSDN
3. Data Science Manifesto
4. Successful Data Teams are Agile and Cross-Functional, John Akerd
5. CRISP-DM
6.  Ten Simple Rules for Effective Statistical Practice, Kass RE, Caffo BS, Davidian M, Meng X-L, Yu B, Reid N.
7. Team Data Science Process, Microsoft
8. The Art of Data Science, Roger D. Peng, Elizabeth Matsui

Mis(sing) Behaviors in Agile?

Human behaviour flows from three main sources: desire, emotion, and knowledge

- Plato

Agile methodologies and frameworks outline values, principles, and practices (rituals) that form the foundation of these frameworks. The Agile Manifesto [3] outlines four core values and twelve principles behind the agile movement. Each agile methodology approaches these (and other values) slightly differently and has developed specific processes/practices to foster the values [6]. 

Business is a human enterprise, and people develop software. Humans are naturally inclined to cooperate, but their behavior is influenced by various factors such as organizational culture, leadership, individual genetics, traits, and attitudes. Norms (institutionalized or informal) influence and govern individual behavior, facilitating cooperation among individuals to achieve a common goal.

Since behaviors are important to an organization's overall productivity, I believe we need to formally incorporate them into any agile framework. In many organizations, moving to agile is both a good time and an excellent opportunity to incorporate cultural and behavioral transformations. 

Framework for Agile Methodologies

With behaviors included as one of the pillars of any agile framework, we will have the following four dimensions to explain agile methodologies:

• Values
• Principles
• Practices
• Behaviors

In this article, we will define the above four dimensions and how they relate to each in general. In future article(s), we will formally study them in detail in the context of SCRUM.

Values

Values are sets of beliefs about good and bad, right and wrong, and many other aspects of living and interacting with others in society. Values are fundamental beliefs. Values are our guidelines for living and behavior.

Kent Beck defines values as [1]:

Values are the root of the things we like and don’t like in a situation. Values are universal - values at work are exactly the same as values in the rest of one’s life.

Examples of values:

Agile Values

Principles

Principles can be described as universal rules or laws. Principles are fundamental scientific, logical, or moral/ethical "truths", arising from experience, knowledge, and (often) values, on which we base our actions and thinking [8]. Principles are guides to behavior.

Kent Beck defines principles as [1]:

Principles are domain-specific guidelines for life.

Jim Highsmith defines principles as [2]:

Principles are the simple rules of complex human adaptive systems.

Practices

Practices are evidence of values [1]. 

Jim Highsmith defines practices as [2]:

Practices are how principles are acted out - practices vary from team to team but principles remain constant.

Behaviors

Values need to be anchored to guiding principles in order to have a clear understanding of the ideal behavior they want to see in their organization [7]

Individual behavior can be explained by three major sources[4]:

• basic human nature (via universal psychological processes)
• culture (via social roles)
• personality (via individual role identities)

Cultures influence individual behaviors[4]. A company’s culture includes the collective behaviors within the organization [7].

Two types of behaviors are important in the context of enterprises: Pro-Social and Anti-Social [5].


Anti-Social/Toxic Behaviors

The following behaviors have been identified as toxic, antisocial, or anti-collaborative in an IT enterprise [5]. I have highlighted some of them (in bold) as more applicable in the context of agile software development.

Anti-Social Behaviors

Pro-Social/Collaborative Behaviors

The following behaviors have been identified as pro-social or collaborative in an IT enterprise[5]. I have highlighted some of them (in bold) as more applicable in the context of agile software development.

Pro-Social Behaviors

How Are They Related

Kent Beck [1] talks about "principles" that bridge the gap between "values" (though universal in nature, may sound too abstract) and "practices" (though important, may appear ritualistic). To extend Beck's bridge analogy further, "behaviors" are like the  high-tensile-strength cables supporting a suspension bridge.

References

1. Extreme Programming Explained: Embrace Change, Kent Beck, Cynthia Andres, 2005
2. Agile Project Management, Jim Highsmith, 2009
3. Agile Manifesto: Values and Principles
4. Culture, Context, and Behavior, David Matsumoto, 2007
5. Transforming It Culture: How to Use Social Intelligence, Human Factors and Collaboration to Create an IT Department That Outperforms, Frank Wander, 2013
6. Agile Principles and Values, by Jeff Sutherland, MSDN
7. Some thoughts on guiding principles, values and behaviors,  Mike Stoecklein
8. Some Core Principles, Assumptions, and Values

Quotable Quotes (Part 2)

Ed Catmull, Podcast

Companies are now realizing that they have to involve technology ..., for me, the model is that you know you are an integrated company if you can't draw a line between ...

Sir Ken Robinson, TED Talk

If you are not prepared to be wrong, you will never come up with anything original.

Lew Cirne (New Relic), Podcast

Every business is a software business.

Simon Sinek, Start with Why

If you follow your WHY, then others will follow you.

There are only two ways to influence human behavior: you can manipulate it or you can inspire it.

Fear, real or perceived, is arguably the most powerful manipulation of the lot. It's not the statistical probability that one could get hurt by a terrorist, but it's the fear that it might happen that cripples a population.

Though positive in nature, aspirational messages are most effective with those who lack discipline or have a nagging fear or insecurity that they don't have the ability to achieve their dreams on their own (which, at various times for various reasons, is everyone).

Søren Kierkegaard, Danish Philosopher

Boredom - a sense of emptiness, not an absence of stimulation but an absence of meaning. An idea that also explains why it is possible, today more than ever, to be overstimulated but existentially bored.

Peer pressure works not because the majority or the experts are always right, but because we fear that we may be wrong.

People don't buy WHAT you do, they buy WHY you do it.

Decision-making and the ability to explain those decisions exist in different parts of the brain.

When you compete against everyone else no one wants to help you. But when you compete against yourself, everyone wants to help you.

US Marine Corps Leadership Manual

An individual's responsibility for leadership is not dependent on authority .... the deep-rooted assumption that authority should equal responsibility is the root of much organizational evil. I believe misunderstanding around this issue is rampant, problematic, and runs so deep in our consciousness that we don't even realize it.

Peter Drucker

Good intentions are no excuse for incompetence and lack of results.

Gregory Chaitin in Proving Darwin

Societies that suppress creativity temporarily gain increased stability, increased efficiency, but they are not flexible enough to deal with a changing environment.

Teddy Roosevelt, Citizenship in A Republic, 1910

It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, and comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows the great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who know neither victory nor defeat.

Jeff Sutherland in Scrum, 2014

No one should spend their lives on meaningless work. Not only is it not good business, it kills the soul.

In software development there is a rule, borne out by decades of research, that 80 percent of the value in any piece of software is in 20 percent of the features.

Just because everyone has always told you that's the way the world works doesn't mean they are right. There is a different way of doing things - a different way of working.

Time makes up your life, so wasting it is actually a slow form of suicide.

John Maxwell, Videocast

The difference between winners and whiners is: winners they know they have to do the right thing and then they feel good and whiners they want to feel good before they do the right thing.

Laugh at life, but be sure to laugh at yourself because someone else already is.

Thomas J. Watson

The ability to ask the right question is more than half the battle of finding the answer.

Tom Rath, StrengthsFinder 2.0

You cannot be anything you want to be-you can be a lot more of who you already are.

Anthony Robbins

Quality questions create a quality life. Successful people ask better questions, and as a result, they get better answers.

John C. Maxwell

Good questions inform; great questions transform.

Good leaders listen, learn, and then lead.

Bernard Baruch

Millions saw the apple fall, but Newton was the only one who asked why.

Rick Warren

Humility is not denying your strengths. Humility is being honest about your weaknesses.

Samuel Johnson

Almost every man wastes part of his life in attempts to display qualities he does not possess.

Henry Ford

If you think you can or you think you can't, you're right.

Sadhguru Jaggi Vasudev

Unless you do right things, right things will not happen to you.

Weston H. Igor

Intuition is what you know for sure without knowing for certain.

Joyce Brothers

Trust your hunches. They're usually based on facts filed away just below the conscious level.

Marie Kondo, The Life-Changing Magic of Tidying Up

If you tidy your house all at once, you'll rebound. It is better to make it a habit to do little at a time.

People cannot change their habits without first changing their way of thinking.

Captain Marquet 

The goal of a leader is to give no orders. Leaders are to provide direction and intent and allow others to figure out what to do and how to get there.

Ram Charan, HBR IdeaCast

A leader who does not produce other leaders is not a great leader.

High-performance leader is different from high-performance individual. And the difference is a high-performance leader gets things done. A high-performance individual does the things in terms of himself or herself.

No Titles, Only Roles - Agile Way?

Everyone a technologist - McKinsey

Every business is a software business - Lew Cirne

Information Technology (IT) has become important to overall success of an enterprise: 

• "technology is no longer simply a budget line or operational issue—it is an enabler of virtually every strategy" [3]
• "the IT organization can help make the entire enterprise more agile by helping it build modular components that can be quickly combined into “solution architectures” for specific opportunities" [7]

Despite aligning IT with business has been a key priority for IT executives [1], the rift between IT and business organizations still exists and numerous authors have stressed the need for brining IT and business teams together:

• Organizations need to cultivate in-house talent for roles that require intimate knowledge of the business and the organization and ... is to open career paths between the IT and business sides [2]
• Large, complex software projects are better served by work cells—cross-functional teams with end-to-end ownership of application modules. In a work cell, business analysts, developers, and testers work together as a tightly knit group and take responsibility for the whole process—definition of user requirements, development of code, functional testing, rework, user-acceptance testing, and the ultimate delivery of functionality to the customer [4]
• Smart Creatives are the product folks who combine technical knowledge, business expertise and creativity [5]
• Today, companies are competing across product categories, and with the rise in integrated solutions, silos are merging. Employees must be able to easily navigate functional and product boundaries to achieve the collaboration needed to deliver these more holistic solutions. Then, as boundaries begin to dissolve, and once-separate groups combine into single teams (a services, sales, and engineering team, for example), roles will need to be redefined [5]
• Digital initiatives ... call for dedicated [digital-speed] teams that are staffed with jacks-of-all-trades rather than specialists. The ideal candidate for the digital-speed team is not an IT specialist but rather a jack-of-all-trades who has both excellent technical skills and functional knowledge [8]

Though some organizations have tried to have formal job titles for business-technolgists, by and large, it is difficult for most organizations to come up with job titles that allow people to perform different roles as needed. But the job titles (and by extension, tribes/groups the individuals belong to) are sometimes the main reason that make it difficult for business and IT professionals to collaborate to achieve success on most projects. 

If enterprises adopt agile frameworks, it is possible to achieve alignment of IT and business without changing the formal HR job titles of the individuals since agile calls for cross-functional and autonomous (self-organizing and self-managing) team where a group of individuals come together to become a team by playing different roles as required and demanded by the team.

Using SCRUM/XP as an example, the following roles are typically needed on software development teams using agile: 

• Product Owner, Product Manager, Business Analyst
• Scrum Master, Project Manager
• Developer/Programmer, Tester
• Technical Writer
• Stakeholders (Customers, Sales, Marketing, and other members from business)

As Kent Beck explains in [9], 

Roles in a mature XP team aren't fixed and rigid. The goal is to have everyone contribute the best he has to offer to the team's success.

I think it is possible to achieve the goal of aligning business and IT by adopting agile methods since it doesn't require changing organization structures and official job titles - individuals play roles (different from their titles) and collaborate more effectively across organizational boundaries when they belong to "single" team given a common goal to achieve.

References

1. Can the IT-Business Marriage Be Saved, Susan Cramm, Harvard Business Review, September 2008
2. Developing talent for large IT projects, Francine Debane, Katya Defossez, and Mark McMillan, McKinsey Quarterly, August 2014
3. Management intuition for the next 50 years, Richard Dobbs, Sree Ramaswamy, Elizabeth Stephenson, and S. Patrick Viguerie, McKinsey Quarterly,  September 2014
4. Achieving success in large, complex software projects, Sriram Chandrasekaran, Sauri Gudlavalleti, and Sanjay Kaniyar, McKinsey Quarterly, July 2014
5. How Google Works, slideshare.net
6. Transforming Technology Companies: Putting People First, Nicole Bennett, Ruba Borno, Sebastian DiGrande, Jim Hemerling, and John Wenstrup, BCG Perspectives, November 2014
7. IT-Enabled Business Agility: A Sports Analogy, Stefan Deutscher, Antoine Gourévitch, Stuart Scantlebury, and Wolfgang Thiel, BCG Technology Advantage, March 2012
8. Two-Speed IT: A Linchpin for Success in a Digitized World, Antoine Gourévitch, Benjamin Rehberg, and Jean-François Bobier, BCG Technology Advantage, August 2012
9. Extreme Programming Explained: Embrace Change, Kent Beck, and Cynthia Andres, 2005

What is Quality in Agile?

Members of software development teams define the quality of their team's software as conformance with user/business requirements. Mike Cohn [2] prefers Joseph Juran's definition of quality as "fitness for use," which is broader than conformance with requirements. 

Total Quality 

Jim Highsmith [1] defines quality in a much broader sense. In his view, total quality has two aspects:

• Extrinsic Quality (Value to Client, Observable, Objective)
• Functionality
• User Experience
• Intrinsic Quality (Subjective, not Visible Immediately)
• Reliability
• Adaptability
• Reducing Technical Debt [4]

Quality - Personal View

John C Maxwell [3] defines Quality as: I haven't cheated you, I haven't cheated myself and I have done my very best. 

Adapting John Maxwell's definition of quality to an agile team for software development:

• We have professional/moral obligation to the business to deliver good quality software (not cheating the business)
• We have introduced fewer bugs and have not increased technical debt (not cheating ourselves)
• We should be satisfied that we did our best as a team (doing the best)

Quality Involves More Than Testing

It is important to note the difference between quality assurance and testing. Testing usually involves ensuring that the software built conforms to requirements and is reasonably fit for use. Ensuring that the end product is of good quality involves a lot more than testing (including continuous testing) - good architecture, good design, good code, good team, and good process.

Quality - Holistic View

In Agile teams, the following principles illustrate that we need to take a broader and holistic view of quality:

• Product is fit for use
• Everyone tests, and testing is a way of life, and it is done continuously
• Quality is the responsibility of the entire team (you don't need a separate Quality Police)
• Quality has to be built in from the start - idea, architecture, design, coding, testing, to delivery
• Quality should be built into the process - it is not something done at the end of the process
• Platform/Product reliability and adaptability (to future changes) are not compromised to meet a deadline
• Simplicity, emergent design, continuous striving for technical excellence - principles that help in building quality implicitly

Overall, the best proof of quality is when the team has enjoyed the journey and is proud of what they delivered.

References

1. Agile Project Management by Jim Highsmith, 2010
2. What is Quality, Mike Cohn's Blog
3. John C Maxwell Minute Video
4. Technical debt

Why starting with WHY makes sense?

Why start with WHY?

Simon Sinek [1][2] talks about the importance of asking WHY since it helps one understand the purpose, cause, and belief behind an organization. He talks about "The Golden Circle" (Why > How > What), the correct order in which one should approach decision making or communication or marketing. He provides examples of companies and leaders who have the perfect balance: clarity of WHY, discipline of HOW and consistency of WHAT.

Most of the companies, organizations and individuals approach what they do in the order of What, How and Why. Whereas, starting with Why, then How and finally What provides a clear way to communicate to others and helps a company in winning its customers. Simon talks about Celery Test for decision making - starting WHY not only helps you know which is the right advice for you to follow, but also to know which decisions will put you of balance.

Agile Software Development 

I started thinking about how this applies to software development teams specifically to teams adopting agile development methodologies. I extended Simon's Why, How, What with When and Who, which are very appropriate in the agile world.

Most common order in which people would approach:

But I believe (based on Simon's idea), the correct order in which we need do is:

Why approaching each sprint, story and task with the above framework of mind is beneficial to the organization:

• everyone in the team from Product Owner to tester to user understand the context, purpose and importance of Minimum Viable Product (MVP) that is will be delivered 
• everyone on the team have a clear filter for decision making (everything should pass the Celery Test!)
• empowerment of the team and distributed control are very easy
• team will be motivated and will be committed to delivering it since everyone on the team understands
• understanding why will help architects, designers, developers, testers and documentation writers do their job easily since they have a clear context and purpose

In my opinion, teams should not take on something until everyone understands the WHY!

References

1. How Great Leaders Inspire Action, Simon Sinek TED Talk
2. Start With Why, Simon Sinek, 2009

Review of Book: SCRUM: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

Every business is a software business 

- Lew Cirne

Though, Jeff Sutherland's new book, SCRUM - The Art of Doing Twice the Work in Half the Time is written for general audience (people outside software development industry), it is an excellent read for folks who are involved with software development.

Inspired by the Harvard Business Review paper, "The New New Product Development Game" (Hirokata Takeuchi, Ikujiro Nonaka, 1986); drawing ideas from the Toyota Production System (Taiichi Ohno, 1988); following the US Air Force training of doing four things - Observe, Orient, Decide and Act (OODA); and employing W. Edwards Deming's PDCA Cycle (Plan, Do, Check, Act), the SCRUM development process developed by Jeff Sutherland and Ken Schwaber, has revolutionized the software development process in numerous companies across the world. 

In this book, instead of just explaining the SCRUM methodology, the author takes the reader through ideas and best practices that are central to SCRUM: 

• great teams (transcendent, autonomous, and cross-functional) and small teams (7 +/- 2)
• time box it, demo it or kill it
• it is crime to waste to build things that no one is going to use
• doing it right the first time
• measure output not hours
• plan reality and plan what you need to
• happiness is predictive and future-looking metric, it leads to success
• what actually make people happy: autonomy, mastery and purpose
• prioritize things
• deliver Minimum Value Product (deliver 20% of features that hold 80% of value as a fast as possible)

Stories need to meet the INVEST criteria:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Jeff rightfully stresses the importance of Product Owner and identifies four essential characteristics of a product owner:

1. Knowledgeable about the domain
2. Empowered to make decisions
3. Available to the team, explains what needs to be done and why
4. Accountable for the value

Some interesting quotes from the book:

• Time makes up your life, so wasting it is actually a slow form of suicide.
• ... multitasking not only wastes your time but makes you stupid.
• Doing half of something is, essentially doing nothing!
• People aren't happy because they're successful, they're successful because they're happy
• Complacency is enemy of success
• Cherish the "Wise Fool" who asks uncomfortable questions or raises uncomfortable truths

In summary, SCRUM tells us to apply the following simple things to anything we do:

• Prioritization
• Single tasking
• Cross-functionality
• Review rituals

Overall, it is a very easy, interesting and inspiring read. I strongly recommend it to everyone, especially all software development professionals whether they are using agile methodologies or not. Great book!