A "Quality" Debate - Rethinking the mindset for non-negotiable Quality in Software Products

One of the key reasons for embracing agility is faster feedback which helps improve the perceived quality of a software product. And every team is focused towards delivering quality, no one wakes up in the morning with an idea to introduce defects, we naturally ideate to solve problems. Unknowingly though, dysfunctions always creep in and identifying a dysfunction is extremely difficult especially when you are a part of the dysfunction.

In this 45 min talk, I discuss about the importance of quality and how it's no longer negotiable even if Project Management principles tell us otherwise. I share stories from my past experience, and from organisations ranging from GM to Mumbai Dabbawalas that have embraced the "Quality is not Negotiable" principle and seen the difference.

I present the context of defect severity and how these may create an illusion of quality; how accountability of a single person (e.g.: Product Owner) may result in a "Lack of Commitment" dysfunction; and how cost is not really proportional to quality especially when it comes to delivering virtual products and services related to it.

I end the talk with practices that help build in quality and in the interest of an interactive session, many of these scenarios turn out to be debates since the context may differ; these debates are always good ways to solve problems (moving away from "Fear of Conflict").

This talk is based on my article titled The Entropic Future of Software Quality

 
 

Outline/Structure of the Talk

  • Explain the concept of perceived quality and its importance with agility
  • Consider a baseline for the debate (Project Management Triangle)
  • Present examples from my past experience while receiving the views from the audience
  • Highlight the dysfunctions of defect triage
  • Highlight the dysfunctions of a single owner of quality
  • Highlight the dysfunctions of skill-cost relationship
  • Revisit the essence of quality with software development

Please view the associated video for the flow of this topic as presented at the Pune UnConference 2018.

Learning Outcome

  • Understanding the perceived nature of quality
  • Highlighting the dysfunctions that affect quality
  • Mention simple practices to avoid pit-falls
  • Building high quality products that customers love

Target Audience

Developers, Project Managers, Product Owners, Product Managers, and anyone responsible for maintaining Quality.

schedule Submitted 1 year ago

Public Feedback

comment Suggest improvements to the Speaker
  • Arijit Sarbagna
    By Arijit Sarbagna  ~  1 year ago
    reply Reply

    Dear Vishal,

    Thanks for your proposal.

    Is this presentation same as the video shared by you? If so - this could perhaps be covered in lesser time. I fear 45 minutes may take out the excitement.

    Also, there are confusions around how quality is interpreted in the discussion (intentionally or unintentionally). Ideally, we need to put it in the surrounding of an "ideal" Agile way of working & then show the deviation. But if we present a skewed situation (e.g. defects prior to review) and then compare against it - that causes more confusion, that clarity. 

    Do you think it will be possible to share your thoughts on:

    1. Time-box for the session
    2. Updated outline of the presentation e.g. how do we wish to illustrate dysfunctions (I couldn't find concrete justification in the attached video)

    Thanks & regards

    Arijit Sarbagna

     

     

    • Vishal Prasad
      By Vishal Prasad  ~  1 year ago
      reply Reply

      Hi Arijit, thanks for your comment.

      Yes, the presentation is the same as the video shared by me, it's from the same event. So far I've always taken at least 40 minutes to deliver this talk and although I'm reworking on the content it's difficult to say if the duration can be reduced as of now since I've not made any dry runs. Rest assured, the excitement doesn't reduce with this talk due to loads of open discussions (the video has a few parts and exercises edited out).

      The talk is story telling based so it may be difficult to identify the dysfunctions unless to listening to the talk and viewing the slides at the same time. The way I wish to convey dysfunctions is by highlighting certain repetitive actions that teams take which results in poor software quality or the experience of delivering software, the 3 that I address in the talk are:

      1. Time lost in managing defect triage & severity (if proven that this is waste, can this be eliminated)
      2. Making PO responsible for critical quality decisions (instead of the team being accountable for it)
      3. Thinking cost is proportional to quality (it is, excluding the context of craftsmanship)

      Hope this helps.

  • Tathagat Varma
    By Tathagat Varma  ~  1 year ago
    reply Reply

    Vishal, the topic and your past talk is a great discussion topic. However, I am not sure of the learning outcomes. Can you articulate what exactly will be the key takeaways? my concern is that while it is good to have such open-eneded conversations, if we don't converge them into some very tangible and close-ended , crisp and close-ended takeaways, they tend to have low utility value (and high entertainment value). So, we need to put some constraints around it in terms of these takeaways. 

    Also, it will be equally important to describe the problem statement and why it exists so that attendees are able to relate to rest of the session. The current deck might need to be reworked for that.

    • Vishal Prasad
      By Vishal Prasad  ~  1 year ago
      reply Reply

      Thanks for the feedback TV and apologies for the late reply. I agree with you said, regarding the take-aways, actually there's one and only one take away from this talk and that's "Understand what is Extreme Ownership of High Quality with regards to Software Craftsmanship". The problem is that quality is very difficult to pin-point to just a few outcomes. I'm in the process of refining the presentation slides and will upload the new one soon.

      The way I wish to convey this key take-away is by highlighting certain repetitive actions that teams take which results in poor software quality or the experience of delivering software, the 3 that I address in the talk are:

      1. Time lost in managing defect triage & severity (if proven that this is waste, can this be eliminated)
      2. Making PO responsible for critical quality decisions (instead of the team being accountable for it)
      3. Thinking cost is proportional to quality (it is, excluding the context of craftsmanship)

      The idea is to use these 3 points with examples as in the slides to shake and shape the view of quality. In order to achieve this, I do need to take the audience occasionally on an open-ended path in order to rethink the view of quality and then converge to "Understand what is Extreme Ownership of High Quality with regards to Software Craftsmanship" which would be the purpose of this talk (may not be called a problem statement).

      Please let me know about your views regarding this.


  • Liked Vishal Prasad
    keyboard_arrow_down

    Vishal Prasad - SLICE - The Experimentation Mindset

    Vishal Prasad
    Vishal Prasad
    Lead Consultant
    ThoughtWorks
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    Agile Principle # 12 defines that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. From Scrum to Kanban and other agile frameworks, this is accomplished through retrospectives and continuous improvement processes. The key to being a successful agile practitioner is to identify areas of improvement and then experiment ways of improving it. But it doesn't stop there; positive improvements ultimately become success stories for other teams and motivates them to experiment with newer ideas which eventually leads to innovation. A negative outcome isn't bad either since it adds to the experience of situations where ideas may not apply. Thus the key to this process lies in being a child, an explorer, and inculcate an experimentation mindset. The SLICE framework addresses this in the following way:

    • S hare: Share an area of improvement
    • L earn: Explore the area for ways of improvement
    • I mplement: Search & apply the learning to identify the success factors
    • C ollateral: Publish blogs, white papers, presentations, etc. as observations of the implementation
    • E xpansion: Grow, Seed, and Split in order to explore new venues for success

    In this talk, I create an environment that inculcates an experimentation mindset and utilise the SLICE framework to drive the exploration.

  • Liked Nilesh Kulkarni
    keyboard_arrow_down

    Nilesh Kulkarni - Enterprise agility with #noframeworks

    45 Mins
    Talk
    Intermediate

    Many companies in today's VUCA world are planning to bring enterprise agility. While many frameworks are available in market, what is missing is the mindset, culture and organizational design that is needed to bring enterprise agility. It also demands coordination across entire value chain and various business process that are part of, or impact the software development life cycle. This session will focus on larger context of enterprise agility and what is needed to bring life to agile enterprises.

  • Liked Rucha Ramchandra Kapare
    keyboard_arrow_down

    Rucha Ramchandra Kapare - Embracing Performance Kaizen

    45 Mins
    Case Study
    Intermediate

    Every organisation hopes / expects / demands high performance from their employees and teams. It's not very long ago when most effective organisations in the world had a ritual called yearly goal - setting. Many organisations still continue with this where the HR cascades a set of goals set by the organisation's leaders for their employees. This is usually followed by a quarterly to yearly review cycle which with most organisations are linked with incentives. In general terms, there ain't any flaw with this system; goal setting is an efficient way to continuously improve oneself. However, the execution of this process may be flawed and may lead to unoptimized results.

    With the advent of business agility, this focus shifted towards continuously learning & improving organisations. This meant that faster feedback was highly recommended for performance improvement and the idea of year-long goal setting seemed a talk of the yesteryears. Many organisations embraced this change by completely abolishing the yearly goal setting practice and instead relying on mentor relationships for an individual's performance improvement. This did improve relationships at the same time hindered transparency since the organisation goals were no longer directly accessed by every employee.

    When seen from the perspective of game theory, it's evident that optimum results are obtained when employees achieve goals which are highly beneficial to them at the same time aligned with the organisation's goals. With the former approach explained above, it's pretty clear that the employees in the first case were aware of the organisation's goals, even if the goals were not aligned with their personal goals. Whereas in the latter case, the lack of transparency meant that the individual's goals were highly focused and may not be in-line with the organisation's objectives.

    This is where Performance Kaizen aligns these two systems with a flavour of Management 3.0 in order to create an optimum setup where high performing individuals, teams, and organisations can thrive. In this session, we present a case study of this implementation at Springer Nature along with our results and learnings; followed by a brief hands-on exercise for the attendees.

  • Liked George Ukkuru
    keyboard_arrow_down

    George Ukkuru - Continuous Quality Monitoring

    George Ukkuru
    George Ukkuru
    Head of Testing
    UST Global
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Continuously monitoring of application quality in production with a purpose of continuous improvement and reduce production support cost. The approach is to collect the data from sources such as social media, app store, and production ticketing solutions. The objective is to analyze the data to provide insights into key quality parameters such as functional performance, security, and usability. The approach helps to holistic view of the application and helps in providing alerts to the development and test teams proactively.