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!