Quality Assurance and Quality Control are often used interchangeably. Many development teams have one or two members designated as “testers” or “QA/QC.” Unfortunately, this is a symptom not knowing the difference between Quality Assurance and Quality Control. Most likely, these teams have a consistent bottleneck between development and testing activities. This causes frustration with the customer because they’re only getting new functionality delivered every few months vs. after each iteration.
Quality Assurance are the processes and activities that ensure something is built well. This means it’s something everyone practices. Test-driven development (TDD) is an example of “baking in quality.” Instead of creating something and then testing it, we test and build at the same time.
I like to think of quality assurance like safety in a factory. A factory may have a “safety officer” who’s in charge of the overall program, but safety is everyone’s responsibility. It’s not the job of the safety officer to make sure you’re not misusing any equipment; the safety officer is charged with teaching practices about safety and creating a culture of safe practices. This is because the safety officer can’t be everywhere at once. Instead, it’s everyone’s responsibility to enforce safety and call out violations when they see them. It’s not to punish or harass, but to save lives and save the company from liability.
The same goes for your QA people. They shouldn’t sit over the shoulder of developers like hawks, inspecting every line of code. They don’t have the bandwidth or technical knowledge to carry out that task — and it’s not effective either. Instead, QA should be inspiring a culture of quality and encouraging creativity. QA should be helping with process improvement and identifying ways to remove waste and promote quality.
They shouldn’t sit over the shoulder of developers like hawks, inspecting every line of code. They don’t have the bandwidth or technical knowledge to carry out that task — and it’s not effective either.
Quality Control – Marking The Checkbox
Where Quality Assurance relates to “how” the software was made and making it everyone’s responsibility, Quality Control is the activities related to formally documenting and inspecting the product. This is where standardized documentation can help. Use just enough documentation as it makes sense, to ensure conformity to the
specifications of the client. This can be baked into the quality assurance process as well. Returning to our example of test-driven development, once a component is complete, saving the results of the unit test can be used as evidence of functionality. The combination of multiple components and testing their functionality is an integration test. Again, saving these results is evidence of interoperability via integration testing. Pushing new code into the existing code set and examining how the system reacts is called regression testing and we can save these results as well. I think you’re starting to get the idea though
Thanks for taking the time to read. I’d love to hear your thoughts on quality management. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!
As the adoption of Scrum continues to grow, non-technical people begin to fill the role of Scrum Master or Product Owner. This is a great thing, as it helps the business align with Information Technology. The organization’s IT unit isn’t seen as a service any longer; instead, they become business partners. Conversations break through company silos as Developers learn the business lexicon and Line of Business personnel learn how to build better software. Processes form to create quality. Quality software is beautiful.
Quality Systems Are Anti-Fragile
So what’s quality? It’s one of those things we know we need. But, what are we talking about when we say, “bake in the quality?” There’s so many definitions that exist today, but I like to think of quality as “anti-fragile.”
What do I mean by “anti-fragile.” It’s a concept developed by Professor Nissim Nicholas Taleb in his book called Antifragile. He describes “systems,” whether those systems are processes, organizations, software, or even cultures, that can withstand the stresses of the environment which act upon them. Anti-fragile is much more than “resilient,” meaning it stays the same despite what the environment throws at it. In software development, we strive to produce more with less effort. We strive for business agility. We pivot and adjust our processes as the environment throws things at us and we are anti-fragile. We use feedback loops, like retrospectives, Six Sigma, and Continual Integration.
We give developers freedom and autonomy by giving them “what” needs to be done, they tell us the “how.” Antifragile means being adaptive. Selection of the right tools and technology for the right job — versus prescriptive.
Anti-Fragile As An Analogy
Professor Taleb uses a great analogy in his book. He asks you to picture something in your home that you’d consider “anti-fragile.” This might be something like the remote control for your television or even your sofa. Of course they can break, right? But, they’re designed to take a bit of punishment. They’re designed to conform and adapt as they are used — they are serving a function and withstanding inputs from the environment. In fact, your sofa tends to feel more comfortable over time as it conforms to your body.
Now picture something in your home that you’d consider “fragile.” This might be something like your grandmother’s china or an ancient grandfather clock. They’re usually tucked away in the safest part of the house and are rarely touched. Why? Because we’re afraid we’ll break them. They’re designed to be aesthetically pleasing — serving a function and withstanding stresses from the environment were not considered in their design. These objects are fragile and saved for “the special occasion.”
Beauty In The Anti-Fragile
So what approach should we take to software development? Should we design something that’s large and complex but liable to break whenever a code commit is pushed? When there’s a tight schedule, should we spend our effort designing something beautiful to the eye but doesn’t serve our purposes? No, we shouldn’t.
I contend that there’s beauty in software when it just works. There’s beauty in software when it serves our users and solves their problems. There’s beauty in software when it gets better over time — not when it falls apart.
Thanks for taking the time to read. I’d love to hear your thoughts on quality or anti-fragile. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!
The Agile Manifesto Teaches Individuals and Interactions Over Processes and Tools
There’s a common misconception, especially among those new to Agile, that the relationship between people and processes is one of friction — that it’s a dichotomy. The subtlety of the language used, “individuals and interactions over processes and tools” implies that both need to exist. The framers of the Agile Manifesto even state, “while there is value in the items on the right (Processes and Tools), we value the items on the left more (Individuals and Interactions).” I agree with this and would also argue that processes and tools are an input to productive interactions among individuals. We know what is more valuable according to the Agile manifesto but, which one is most important? People or Processes? Maybe we’re thinking about it all wrong?
Chinks In The Armor
Asking, “what’s more important, people or processes?” is a fair question to ask when you’re new to Agile. Especially since most organizations looking to “go Agile” start with Scrum (by the way, practicing Scrum does not mean you are Agile. It’s a great start as long as the leadership team continues to stay open minded and doesn’t limit the organization to just Scrum). Usually, a handful of developers, project managers, business analysts and line of business managers are sent to a two-day class scrum class; they receive a certificate dubbing them newly minted “Certified Scrum Masters/Product Owners/Developers” and are given a small project to show a “proof of concept” with the
new framework. It’s chaotic and exciting at the same time; however, the organization’s weaknesses begin to show up (Scrum has a way of shedding the spot light on the problems that have existed in the organization for a long time). I call these the “chinks in the armor.”
The biggest chink I’ve seen most teams discuss in their retrospectives are the People vs Process Dependencies. Invariably, team members and managers dig in their heels about which one is better. This is because people default to what they know best. They use what has worked for them in the past. Change is hard, even when there’s clear evidence that what they’ve been doing will not work anymore because of changes in the business environment.
As a coach, it’s important to understand the pros and cons of the people and process dependencies. It should be explained clearly with not only your teams but, with the management team too. The organization will have to move past striking a balance and figuring out which areas need the most improvement. Instead, they should assess the parts of each dependency and figure out what works best for them today. Below are some extreme examples of each dependency to illustrate the pros and cons of both.
People Dependency
Pros
It gives workers satisfaction – employees feel satisfied when they know they are valued
Flexible – employees are empowered to perform work in the way they feel is best
Adaptable – the ability to pivot and make changes is the hallmark of business agility
Efficient – unnecessary steps in a process are avoided
Helps to retain high-achieving, confident, people – people stick around because they know they are important and are good at their job
Cons
Less repeatability – changing processes are not repeatable and leads to waste
Makes customers nervous – customers feel comfortable when there’s visibility on the process
Can provide a “false sense” of a high degree of control – processes are measurable. What get’s measured gets done. When managers rely solely on the self-reporting, certain messages may get filtered and there is no data to verify.
Turnover impacts are much greater – institutional knowledge can walk out the door or get hit by a bus
Higher risks – for the reasons listed above
Process Dependecy
Pros
Repeatability – repeatability helps with predictability
Easier to improve – a documented process is easier to improve with less risk to the organization
Less people dependent – automation of easily repeatable tasks frees up resources for more value added activities
Predictability – it can be measured objectively and relied on as a lever for control in the organization
Brings new personnel up to speed faster and with less risk of poor performance
Cons
Paperwork can overshadow the task – processes that are overly complex distract from value added work
Resources must be spent enforcing or ensuring compliance – managerial debt is incurred. Managers spend less time removing impediments and more time micromanaging processes.
Someone must own and manage the process
Less “thinking” is needed – employees and managers can become complacent if there’s no impetus for process improvement. This leads to waste.
Processes Come First But They Should Not Be Valued
I know I’m going to rub a few people in the Scrum community the wrong way (and probably piss of a few of the business process analysts too) But, processes should come first but they should not be valued in the same way we value our people and interactions. It’s easy for managers to regard processes as instruments for control. Some managers finely craft their business processes. They labor over them and build complex systems for the organization. But only effective processes facilitate people. Not complex ones. If you require a practical rule of me, I recommend you murder your darlings.
“Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it — whole-heartedly — and delete it before sending your manuscript to press. Murder your darlings”
I argue that people and processes should not balance each other. Many representations of this balancing act builds a false dichotomy. It implies that they are of equal value. Like the framers of the Agile Manifesto, I do not value them the same way.
Processes should support our people and facilitate their interactions. Processes are either operational, supporting, or management oriented. If they do not provide value. Murder them. It’s up to the teams to decide which processes they need most and which ones can be forgotten. Each organization is different. Each darling should be judged accordingly — but retain the ones that still add value. Don’t throw the baby out with the bath water. Don’t assume that just because you’re “doing Agile” that processes no longer needed to exist. No, processes are still important. They unlock your people’s ability to work at a higher level. But it’s time to end the love affair with processes and value your people.
Share your thoughts in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!
I recall my first software development project as both exciting and nerve racking. Luckily, I was paired with an extremely talented Business Process Analyst who’s approach to requirements gathering was both methodical and like watching an artist at work. He introduced me to several ways of thinking about organizations — what I now call the 5 P Pyramid Model. This model has helped me analyze business processes and has been a wonderful tool for change management and exercising business agility. I continue to refine his ideas and accumulate my own knowledge, however, I would like to share his lessons with you by using the Scrum Process as an example.
“When eliciting requirements or attempting to document information from your stakeholders, keep the following items in mind:
The 5 P Pyramid Model
Policies,
Processes,
Procedures,
People, and their
Personalities”
Policy
Policy is about understanding the landscape you operate in and those affected by your decisions. Policies guide decisions and provide rationale for their existence. Well written policies describe the what — they do not describe how an organization will fulfill the requirements of the policy. Generally, you can bucket your policies as external and internal. Internal policies also have two characteristics: De jure and de facto.
External policies are the laws and industry standards your organizations must adhere to. These include international, federal, and state laws you must adhere. In the case of Scrum, a government agency has policies regarding purchasing. Here is a great article regarding public-sector purchasing using Agile.
Internal policies are the policies related to the organization’s vision, mission, and goals. Whether undergoing business projects or internal IT projects, policies regarding how products and projects are delivered also exist. In the case of Agile, an organization’s policy describes the use of iterative and incremental development techniques vs. gated and sequential development.
De jure internal policies: Have been formally evaluated, approved, and adopted by the organization. Usually, they are easily accessible, understandable, and “written in stone.”
De facto internal policies: Have been widely adopted and accepted by the organization, however, they are not written and documented — leaving room for interpretation. Finding and documenting these policies can be difficult. At times it can feel like you’re on a journey to find the tribal leaders who can teach you the “song of the tribe.” It becomes increasingly difficult to find the tribal leaders to teach us their “songs” as more people retire and the trend for job hopping continues to grow.
Process
Business processes are the high level activities that an organization accomplishes in order to fulfill policies. They can and should be analyzed at different degrees of resolution. Think about the saying, “Give me the 30,000 foot view” vs. “At the ground level.” They should be assessed and dropped into three different categories:
Operational processes are the processes related to an organization’s value chain. They are the core business activities that organizations engage in to deliver their goods and services. Using the processes that our Scrum teams use, we can see that the Sprint Review and Pushing Code to Production directly add value to our customers because this is where our stakeholders review and accept the code (sprint review) that was developed during the iteration and the delivery team makes it available to for use (delivery of shippable code).
Supporting processes are the secondary functions that exist within the organization. They support the core business processes but do not provide value to the customers directly — Sprint planning and the daily scrum is where our delivery team plans what will be worked on (planning) and discusses the work being done over the past 24 hours to address any impediments to meeting the sprint goals (daily stand up).
Management processes help coordinate the operations and supporting processes. They drive for business efficiency and success. The sprint retrospective is used by the delivery team to inspect and adapt their daily work to improve efficiency and product backlog grooming is for prioritization, addressing dependencies, and writing effective user stories before the next planning meeting.
A 30,000ft view of the Scrum Process
Procedures & People
Procedures are the steps that need to occur in each process to reach desired outcomes. They are normally fulfilled by a combination of people & technologies and are sometimes referred to as standard operating procedures. Let’s look at the procedures in our Scrum processes as an example and identify the people involved.
Sprint Planning
Scrum Master: Opens the planning session, sets expectations, announces the agenda, and enforces a “time-box” throughout the planning session.
Product Owner: Presents a prioritized and groomed product backlog to the Delivery Team and states what business objectives the stakeholders want attention during the iteration.
Delivery Team: Examines the high priority user stories, asks clarifying questions with the Product Owner, identifies potential risks & dependencies, and helps refine acceptance criteria.
Scrum Master and Delivery Team: Reviews the velocity from the last few iterations and plans their capacity for the coming sprint.
Delivery Team: Uses relative estimation to size the user stories.
Delivery Team: Uses their past velocity to benchmark how many user stories should be responsibly committed to.
Product Owner and Delivery Team: Finalizes the Sprint Goal together.
Daily Scrum (aka. Daily Stand-up)
Scrum Master: Ensures the meeting occurs, ensures no management interference on the free flow of information and discussion, and enforces a 15-minute “time-box” on the Daily Stand-up.
Delivery Team: Conducts the meeting and discusses the progress towards the Sprint Goal.
Product Owner: When available, attends the meeting to answer questions for the Delivery Team and makes decisions when needed.
Scrum Master: Makes notes of any impediments that the Delivery Team is facing and immediately takes action following the Daily Stand-up to resolve impediments.
Sprint Review
Scrum Master: Opens the Sprint Review, sets expectations, announces the agenda, and enforces a “time-box” throughout the review.
Delivery Team: Presents their work in accordance with the acceptance criteria agreed upon during the planning meeting to both the Product Owner and any stakeholders invited to the meeting.
Product Owner & stakeholders: Once the Delivery Team has finished presenting their work, the Product Owner and stakeholders are invited to ask clarifying questions and interact with what was built.
Product Owner & Delivery Team: Takes notes of any issues, risks, or concerns from the stakeholdersrelated to what was built or will be built in the near future.
Product Owner: Accepts or Rejects each user story the Delivery Team worked on during the sprint.
Delivery of Shippable Code
Teams and organizations have their own way of pushing their code into their production environments. Due to the various best practices that exist, a separate blog post will be posted to address this at a later time. Seriously! This could be a ph.D thesis!
Sprint Retrospective
Scrum Master: Facilitates the meeting, enforces a “time-box” and “sets the stage” –all information shared during the Retrospective stays within the meeting. I call this the “Vegas Rule” because what happens in Retro stays in Retro.
Scrum Master: Starts with an ice-breaker if the Delivery Team is new and reviews past velocity with the team. The Scrum Master may also reminds the team of all the impediments that occurred during the sprint if the Delivery Team faced any during the sprint.
Scrum Master and Delivery Team: The Scrum Master facilitates “Data Gathering” activity and the Delivery Team produces the data.
Scrum Master and Delivery Team: The Scrum Master facilitates an “Insight Creation” activity and the Delivery Team creates the insights.
Scrum Master and Deliver Team: The Scrum Master facilitates a “Prioritization” activity and the Delivery Team prioritizes what they want to improve.
Scrum Master and Delivery Team: Decides how they will improve their own processes (either operating, supporting, or managerial processes) and creates a realistic plan to execute on. Scrum Master may need to coach new Delivery Teams about developing SMART Goals or some other goal setting techniques.
Product Backlog Grooming
Product Owner: Prioritize the Product Backlog based on business objectives.
Product Ownerand Scrum Master:Gathers the requirements from stakeholders and writes preliminary User Stories and Acceptance Criteria
User Stories: As a <some role or person>, I want to <some procedure>, so I can <achieve a business outcome>.
Acceptance Criteria:
Functional
Non-Functional
Performance
Security
Product Owner, Delivery Team, Scrum Master and invited stakeholders: Scrum Master and Product Owner facilitates an activity for the stakeholders and Delivery Team to refine the user stories and acceptance criteria.
Personalities
The personalities of our employees influences their effectiveness for their role(s). Selecting the right people with desired personalities ensures that the procedures and processes are completed correctly and in a manner that matches the organizational culture. While I won’t go into the different “types of personalities,” I will speak to the types of characteristics and traits that make an effective Scrum Master, Product Owner, and Delivery Team member.
Scrum Master
Ability to coach others with empathy.
Ability to resolve conflict and communicate with empathy.
Deep understanding of Agile and Project Management.
Facilitation skills and creativity.
Servant Leadership.
High level IT skills and knowledge.
Business acumen.
Product Owner
Strong leadership.
Ability to prioritize work and competing demands.
Ability to make decisions independently.
Ability to gather business requirements and elicit information from stakeholders.
Understanding of Agile and Project Management.
Domain knowledge.
Tactful communication skills.
Delivery Team Member
Ability to work well with others.
Openness to coaching.
Strong communication skills.
Strong technical skills.
Ability to analyze and solve problems.
Honesty and integrity.
Understanding of Agile and Project Management.
I’d love to hear your thoughts on the 5 P Pyramid Model in the comments below or if you’d like to have a discussion about Business Process Analysis, please contact or connect with me on social media!
jeremy brien 