Downloaded 50 times
![Notes/ key points
So how does QA lead an agile transformation? That was what I said I
was going to talk about, wasn’t it?
I often hear "Bring QA in early to help with quality." So QA gets invited
to meetings. And they sit in meetings and when it's their turn to
talk, say, "We still don't have [requirements|code|environment]. That is
all."
Get QA involved early means involved. QA professionals, you have to
take the lead here. No one else gets QA - you have to educate them. Be
ready to speak up and take the lead.
You’re the unsung heroes, remember? You know everything.](https://image.slidesharecdn.com/coqaaepics-111115145512-phpapp02/75/QA-s-lead-role-in-agile-transformations-20-2048.jpg)
Uploaded byDave Ungar
QA's lead role in agile transformations
This document provides an overview of quality assurance and agile principles from the perspective of a QA professional. It discusses how QA's role is to influence both processes and people to build the right product. It emphasizes that people are more important than processes because people can change more easily. The document also notes that the Agile Manifesto echoes many of the principles of QA. It provides suggestions for how to build influence through finding shared values and goals, increasing knowledge, and learning both relevant and irrelevant topics. It encourages QA professionals to take a lead role in agile transformations rather than just sitting in meetings. It stresses the importance of showing value, even if that means taking a leap of faith at first to get others engaged.
More Related Content
Similar to QA's lead role in agile transformations
QA's lead role in agile transformations
- 1.
- 2. Story 0 Why are you here?
- 3. Story 1 What is a QA professional?
- 4. Notes/ key points Quality assurance is about making sure we are building the right product from the very beginning. We do that using processes people and tools. QA's role is partially to put good processes into place - repeatable success. But the more important role is influencer - influencer of *people*. Now let's put these two things together, people and processes. ...
- 5. Story 1A Process vs people
- 6. Notes/ key points """worked in my environment"" .. Process is important - but process is predictable and reliable. People are more important - because people can change so easily - what they're thinking, whether or not they're going to support an idea, how hard they're going to work, what's important to them & what their priorities are .. Especially when you have bad leadership. But even great leadership can't compensate for the human wildcard. “ You don’t have an environment to yourself. It takes collaboration to make things/ ideas work in everyone’s environment.
- 7. Story 2 Agile Manifesto IS QA
- 8. Notes/ key points I remember when agile started to emerge - (2002) - there was a lot of resistance in the QA field - it was perceived as eliminating the need for QA & rigid testing. But look at the manifesto. Each of those points screams QA…. (THINK DEMING!) "1- Individuals and interactions over processes and tools 2- Working software over comprehensive documentation 3- Customer collaboration over contract negotiation 4- Responding to change over following a plan
- 9. Story 3 Building Influence
- 10. Notes/ key points " How do you build influence? By building trust. You’ll find lots of answers in the world for how to build influence. But here’s the essential one people miss. Here's what people respond to - the familiar. Simon Sinek has a great video about this - are you friends with everyone in Columbus? No. But when you meet someone from Columbus in Berlin you have a connection. Or you research what type of laptop to buy - and then your friend says, ""naw, buy the lenovo..."" (have you heard that people don't like change? At the root of that is that it's unfamiliar. People are uncertain about expectations or how to do something or what the outcome will be. ) So how do we put that idea into action? ….
- 11. Story 3A Find Shared Values, Vision, Go als
- 12. Notes/ key points Shared values - Having a common purpose is critical. Whatever it may be - producing a product, correcting a problem - you can't build trust, influence or momentum toward a nonexistent goal. Figure it out – what’s your purpose? And always be positive about it. Sure you might grippe occasionally - but you have to defend your purpose. Don't get sucked into the negativity - turn it around. Reassure your team that we can be successful and what we're doing is important. (But you have to believe it. So get religion.) Authenticity matters.
- 13. Story 3B pattern matching
- 14. Notes/ key points How else do you find the familiar? Increase your knowledge set to gain better pattern matching. (you don't stick your hand in a blender - even though you have never done it before, you know that the outcome would be bad.) This applies to more complex problems too. Diverse knowledge is an important tool. Not just in problem solving, but in developing relationships. (People & interactions!)
- 15. Story 3C learn something irrelevant
- 16. Every organization isdifferent, every team is different, every person is different, every interaction is different. (“works in my environment”) So can I stand up here and give you a laundry list of tools and techniques that you can plug in? I can try, and maybe it'll be useful 10% of the time. So the trick isn't to have a prescribed way of ""this is how you _____"" .. Same goes with agile - agile is a state, not a method. The goal is flexibility and adaptability, improved performance, higher satisfaction, higher quality - not use of tools. You need to get out there and learn. Not just learning your current role - QA is the profession that knows everything. QA are the unsung heroes in the organization who can connect what's happening over here to what's happening over there. (Pattern Matching.) And to be good at that, you have to be inquisitive, knowledgeable, insatiable.. Learn about QA. Learn about development. Learn about business. But also learn about music, chemistry, cheese making. Volunteer with a nonprofit and learn what they do and how they operate. Talk with children - what solutions are you looking for? Ask a kid. They'll teach you how to think differently.
- 17. Exercise Good, better, hor rible
- 18. Don't stop withthe first answer you find. But don't search either.. Think. Don’t search. When faced with a question, don't immediately jump to google. Use your brain. Use your colleagues. Think about possible answers first. And part of being able to do that is to learn new things daily - in pursuit of knowledge & wisdom for its own sake. (Not just when you need a specific answer.) Learn something irrelevant! 4 volunteers… 1 – problem statement 2 – good solution 3 – better solution 4 – horrible solution Why is it bad? What would it take to make it work? Explore the possibilities. Collaborate.
- 19. Story 4 QA leads the way
- 20. Notes/ key points So how does QA lead an agile transformation? That was what I said I was going to talk about, wasn’t it? I often hear "Bring QA in early to help with quality." So QA gets invited to meetings. And they sit in meetings and when it's their turn to talk, say, "We still don't have [requirements|code|environment]. That is all." Get QA involved early means involved. QA professionals, you have to take the lead here. No one else gets QA - you have to educate them. Be ready to speak up and take the lead. You’re the unsung heroes, remember? You know everything.
- 21. Story 4A Step up, step outside of your comfort zone
- 22. Notes/ key points ""do you think I know what I'm talking about?...."" I wasn’t sure if this idea for a presentation would work tonight. But I wanted to take a different approach. It worked in my environment! Don’t be afraid to fail. People WANT you to succeed when you get in front of them. So when you speak up in a meeting, (#1 - be succinct - no one likes a blabbermouth) most of the time, people are giving you the benefit of the doubt that you know what you're talking about. Especially in a group with a leadership vacuum. 1. If you have a strong leader - talk to that person privately about allowing you to contribute more in your area of expertise. 2. If you have weak leadership - become the leader. Everyone's waiting on someone/anyone to step up. The only thing worse than trying and not being the ideal leader, is sitting back while everyone watches nothing happen. And if you don’t know what you’re talking about and other people do – ask questions. Lead by asking, not by telling.
- 23. Story 5 Show the value
- 24. Notes/ key points Show the value - this is last. While agile is all about value, it's first about transition, philosophy & people. (remember that agile is not a process, but a state of being.) Sometimes that's a leap of faith. Whether you can prove the value or not, you need people to follow you. Build influence and trust. .. In truth, that’s a circle. (PDCA, yes?)
- 25. Notes/ key points Pause – questions or comments on the human side of agile?
- 26. Story backlog What challenges are YOU facing?
- 27. Story how to release plan
- 28.
- 29. Story how to sell agile to management
- 30. Notes/ key points Ugh – this one isn’t easy – depends on a lot of environmental factors. #1 – don’t try to sell it. Just do it. Pretend like everything is normal. Work for 30 days, get a lot done – show progress to skeptics.
- 31. Story what is TDD? (test driven development)
- 32.
- 33. Story how does estimation work?
- 34. Notes/ key points Q: any one of these epics could be a three day class. So how do you scope something big and estimate it? A: define the value to the user and the fidelity of the solution. In this session, we are just going to give a cursory answer to questions, indicate media for further study, set people on the right path. If that’s all we’re attempting to do, we know we can deliver *some* value in under 5 minutes. (Or we can deliver major value in 3 days.)
- 35. Story how does test planning change?
- 36.
- 37. Story basic agile principles
- 38.
- 39. Story basic scrum practices
- 40.
- 41. Story Agile tools
- 42.
- 43. Story Agile metrics
- 44.
- 45. Story Zero defects?
- 46. Notes/ key points Remember the cost of quality
- 47. Story What is “technical debt?”
- 48.
- 49. Story measuring velocity
- 50. Notes/ key points Don't set velocity targets - velocity measures what you can realistically do. It is a measurement, not a goal. Instead, look for ways to improve delivery.. Use velocity to assess whether process improvement is moving the needle.
- 51. Story Quality -vs- fidelity/grade
- 52. Notes/ key points "Attractive Quality and Must-Be Quality .... Neutralization -vs- differentiation --> neutralize fast, differentiate as soon as you can. Neutralize 'good enough' and spend more time on differentiation. Don't go for zero defects -> cost is too high. Use a hackathon or bang out fixes for neutralization. (don't compromise quality, but keep the grade low.)"
- 53. Story Structuring testing
- 54. Notes/ key points •Product Teams break Epics or Features into Stories: QA helps by first writing out some very basic conditions of satisfaction •Once the conditions are agreed upon, QA writes the Acceptance Criteria •Story is fleshed out by the Product Team •Core team now has very specific criteria to make tasks and code to •Business Rules include a certain amount of traceability to the acceptance criteria
- 55. Story s
- 56.