Assessing your #agile mindset

Why is #visibility so important in #scrum or in any #agile team?

The ability to react to a fast and ever-changing environment, deliver ongoing changes to high quality working software is not only about having the right tools or establishing the right process. It is also crucial to  establish the right mindset or culture, no matter what tool or processes we employ.
Visibility is only one of those mindset tools we need to esquire. However Visibility is a powerful tool. Correct usage of visibility can create the expected behavior. We expect everything that can point us in the right direction or provide early feedback to be plainly visible.

Visibility - A powerfull #agile mindset tool

The ability to react to a fast and ever-changing environment, deliver ongoing changes to high quality working software is not only about having the right tools or establishing the right process. It is also crucial to  establish the right mindset or culture, no matter what tool or processes we employ

Visibility is only one of those mindset tools we need to esquire. However Visibility is a powerful tool. Correct usage of visibility can create the expected behavior. We expect everything that can point us in the right direction or provide early feedback to be plainly visible.

Let’s illustrate the value of visibility with an example: Pretend that in your town, there’s a problem of speeding drivers. And as you are a responsible driver yourself, you know that’s dangerous.

To solve the problem, police set up hidden speed cameras in strategic locations. According to them, this is meant to catch dangerous drivers who exceed the speed limit, and so reduce the number of accidents. But as it turned out, drivers didn’t actually drive any slower, as they didn’t see any visible deterrent (hidden speed cameras, remember?)

So was there any value in setting up the cameras? Apparently not. Our taxpayer money was spent on buying and installing them, but the actual driving speed didn’t go down. So there was a challenge (speeding drivers) and a quick reaction (hidden cameras), which didn’t actually produce any value.

But was there ANOTHER value in setting up the cameras?

Yes, and you can probably guess what it was. With the hidden cameras in place, the police department (and the town council) made buckets of money from collecting fines.

The problem, of course, is that’s not what we were looking for. We wanted to reduce the number of accidents by making people drive slower. THAT was the intended value.

When the hidden cameras were taken down, and VISIBLE cameras were set up, people started slowing down. And that reduced the number of accidents.

See? Value, and the value we were looking for.

The following is an example of changing driving speed by means of clear visualization:

The following is an easy way to control large crowds:

Control your inventory easily:

Control your child?

And here is how it looks like when you deal with DevOps. Everything is visible, and the relevant information that needs to change is presented:

For further reading about the agile and Devops mindset

Are they selling you “Agile” tools or individuals and interaction?

How many "agile" companies want to only sell you a tool? How many consultants want to sell you a process? There's nothing wrong with tools and processes as long as you understand that Processes and tools fits only with Individuals and interactions otherwise you are in the path of destruction. The trouble is that process and tools gets all the press because they are more tangible and easier to describe. 

In this new agile world, producing software requires us to be social. And that’s not something that’s going away even if we have the best tools and the best process intact.

Our constraints are just stories we were told once.

How many of us refuse to attempt something new or challenging because of our so called MINDSET? Here are some Stories about mindset which may help us realize how constraints are only something in our heads. If we change the story, we change the outcome.

The F1 Agile/Lean mindset - "you just don't know how good you are until you get there." Jean Alesi

"Qualifying is less than 2 hours away and missing Q1 means that you’ll start at the back of the grid(or not at all), a disaster for the championship. The car has got to be repaired and back out no matter what. Your call to action.

It’s a familiar story in racing and to the casual TV viewer the repaired car normally appears clean and polished for qualifying as if nothing had happened. Easy eh? Wrong, it’s far from easy, and it’s situations such as this when the Formula 1 mindset is most evident. What goes on inside those pit garages during times like these is truly, truly impressive teamwork."

'Real life' Scaling Agile (Across the Enterprise) explained from the tranches

Visual studio (MS) employees  explains the mindset and techniques of scaling agile a cross the organization.

Which one is the mindset for success? Fixed or growth mindset?

The good news – especially if you just recognized yourself as being someone who holds the Fixed Mindset worldview – is that it is possible to change from one to the other. Growth mindset can benefit you anywhere. From personal aspects, organization and team performance areas.  I’m sure that, after reading this, you can grasp for yourself that having a growth mindset will only benefit you in achieving ultimate goals and success.

Top 10 Characteristics of an Agile Organization:

@RallySoftware

Are you limited by Yesterday’s Tester Job Defininition?

Automated testers?! Everything changes for them. What is that new mindset expected form them? How are they expected to integrate a good automation framework with agile concepts? what are the “new” skills needed?  and how do they deal with all types of tests in the agile environment?  JoEllen had this to say: "Be aware of the change in mindset/culture. Experiment with modern tools. Keep the big picture of the application in mind and consider individual user stories within the bigger context. Think holistically, and encourage the rest of the team to do so as well."

Car Wash Line - There is a Lean Way Too

As a lean fan I tend to look at any line of production with the lean eyes. I can’t help it. The car wash line is one example of a very annoying one to the customer when it is not efficient. Car washing is not all about the washing machine; It has a lot to do with the process and the ability to improve according to business value requirements. The machine looks great in the videos, but does it alone provides the quality of service the customer need?  Without a doubt, the lean principles can be applied to this businesses. Here’s a short collection of machines and a short process view.

The agile mindset

What is this mindset thing anyway? how do we reach it and why?

Testing With an Agile Mindset

The Agile testing mindset may be considered to be one of the important things when implementing Agile quality and testing methods. While many see “Agile testing” as just “having the QA and development part of one team”, actually it is much beyond. Agile testing challenging the core mindset of the organization regarding the role of the QA. Without dealing with the agile testing mindset , we may achieve a limited or, in most cases, a costly, quality outcome, whereas we could have performed better and cheaper.

Visual thinking - What is it?

Visual thinking, also called visual learning, is a proven method of organizing ideas graphically - with concept maps, mind maps and webs. Scientifically based research demonstrates that visual learning techniques improve memory, organization, critical thinking and planning.

The Agile Testing Mind-Set Maturity - Part #1

The Agile testing mindset may be considered to be one of the important things when implementing Agile quality and testing methods. While many see “Agile testing” as just “having the QA and development part of one  team”, actually it is much beyond. Agile testing challenging the core mindset of the organisation regarding the role of the QA. Without dealing with the agile testing mindset , we may achieve a limited or, in most cases, a costly, quality outcome, whereas we could have performed better and cheaper.

Moving into Agile methodologies often demands adopting a new set of knowledge and at the same time a new set of behaviors. after all, from the starting point where quality people perceived as “bug hunters”,act  as quality defenders, standing in the last frontier line to “save the nation”, usually as separate “independent” unit that need to be “objective”, from such mind-set we move to collaboration, “all team approach” , we are all quality defenders and we are all the frontiers.

but before we will drill into the “new mind-set” , lets ask ourselves, What is a mindset?

From Wikipedia:

"A mindset is a set of assumptions, methods or notations held by one or more people or groups of people which is so established that it creates a powerful incentive within these people or groups to continue to adopt or accept prior behaviors, choices, or tools. "

In other words, changing practices without changing mind-set will not make the change lasting!

Now, what exactly is an Agile mindset?

 Since agile aims to deliver something that can go live, in a relatively short period of time it is clear that we must shorter the cycle time between code developed to code tested, we need to better react for immediate changes that pop-up as we learn more and  we need more effective and faster communication channels than documents, as such - we must work together.

We can identify mindset in various concepts and behaviors. It's enough to take a look at the Agile manifesto or the Agile principles to understand that the Agile mindset is one that brings people to act together in an ongoing working system.

So what happens to the testing mindset ?

We cannot achieve quality if only the testing unit are quality oriented. we can do it only when the entire manufacturing chain is quality oriented and committed to other chain units quality. This is a serious thinking fixation change.  To ensure this, we need to change the mindset of the testers as well as the team and the PO so they will be able to truly cooperate, share practices, and together be accountable for a good working quality delivery software.

We want to bring the testers to collaborate with developers, and we want developers to understand quality issues and to act upon them as such they need to sit together or at least have daily direct communication.  We can no longer leave the product owner far from development and leave the testing as the last resort.  The time frames are mach smaller ,the feedback is given early and frequent and decisions needs to made faster and easier. Development , product and testing needs to communicate more frequently so small portions of code can be developed and tested into small working business software units.

PO,development and testing is a collaborative triangle that needs to be understood as a main agile mindset factor.

From “quality police” testers become professional support for the PO and the development so all together as a team reaching quality goals. We want also the QA to better understand the business and expected behavior and the PO to understand system and quality impacts of his ideas, as such QA move to the beginning of the process, acting as the right-hand of the PO during requirement definition and of-course development. 

The product owner is also becoming a key collaborative factor for the agile team. If it's not working (Meaning also tested and accepted by the PO), then it's not done, then it is not  "a working system".

We need to get used to working closely with product , getting and giving continuous feedback.

The following are example of  mindset statements which should act as the incentive of changing the actual daily behaviors of developers, testers and product owners .

1. “We are all in this together ", “Whole team approach”, “collective testing ownership”, “A testing mindset is a team mindset.”  “No more Us vs. Them. “ :

Testers aren’t expected to adopt quality and testing mindset alone. We are all expected to do so. We all share the end-to-end concern of delivering 'working software’. We are all accountable for quality. No more" here are your requirements, let's meet in three month and see what you delivered".

Another aspect of this mind-set statement is that as the team (QA, Dev) share same goals and commit together on scope and quality there is less attitude of “I am a developer so I will not

do QA work such as execute test plan …”, or PO that do not have time to approve or even

write the test scenarios that cover the user story’s expected behaviour.

it is a collective testing ownership approach with developers and product. (while of course the tester bring the testing expertise and developer the development but share ownership on the final result - high quality software).

2. “ Development = Coding +Testing”, “We are building quality in “ : We deliver working software. It's not done if it's not tested.  testing is part of the project , on a daily basis , it is no longer a phase . This is an easy mind set for testers to adopt but it is a hard mind set for developers to adopt.

Do they need to start testing now? how can we test the system ASAP? And why ? Who tests? When, what kind of testing? These are all practical and mindset changes questions.

We are not waiting for the end of development to verify or validate our quality.

We share quality activities throughout the product life cycle, from coding standards, code review, unit testing until early system and non-functional test. basically we didn’t finish any task if we didn’t validate the quality. (quality activity is the “done” criteria  to measure project progress from day 1). this approach alone dictates a change in the entire testing practices to fit ongoing testing feedback , ongoing quality feedback.

3. “Continuous integration”, Don’t wait to the “integration hell period” at the end of project, where the integration is big and heavy with a lot of details and defects. In fact, working in small pieces is always better. Thinking small. Dividing a change to small pieces and cope with small changes one at a time make the stabilization of the entire system much easy. Furthermore, when the cycle time from code change, defect detection, code fixing and system validation is short the waste (cost) is much lower.

quality is not measured in scoped to the end. it is not a huge defects reports used in the testing phase. it is an ongoing production of working software Small pieces are tested continuously. Tests are integrated into the development process. we need to think testing (and quality) at every step we do.Developers and product are also expected to think testing first, not only to review and examine testing planes and results after requirements and coding are set.

4. “Communication is a key to our success”. we can no longer communicate at the beginning of development or at the end. we need to develop ways of ongoing communication, face to face communication so we can produce early feedback.

5. “Visibility across entire team members” is a primary aspect to our work. No more" I am coding and be finished in 7 days ..." every one needs to know what everyone doing .

6. “Customer collaboration”.”Testers are business oriented”  they represent the business inside the team.

Why not share information with the customer or the customer representative (such as the product owner, system analyst etc)? We are only developing what the customer needs, not what we think he might need. Customer involvement in early phases is the best way to develop software.

7. One of our goal is always working software (besides satisfying our customers). This is our primary KPI.  we need to understand that in each and every development task , and a small business unit , we can not count any development progress if it was not tested. we are measuring the progress of done software only.

8. Continuous improvement. we are expected not only to deliver but also to think about how we do things and to be proactive in changing them.

Although testers are part of the team ,they are a speciality, they are committed to constantly learn and improve their testing and quality domain. In addition to improve their expertise as testers, QA needs to lead the big Q thinking in the team (helping the scrum master), to advocate for using metrics and implement team rules as defined following effective retrospective and other process improvements beyond finding defects ...

Obviously, this mindset does happen in a day, it mature, it is a process and it should be. A mindset is something that evolves and matures along with practices, and skills, and team maturity. Testers cannot mature alone. Mindset is one of the things that, in order to mature in it for testing, we need also a team maturity.

How does it mature? what are the practical behaviors that goes with it ? What is the manager role? All coming soon in the next posts…

References:

Agile manifesto or the Agile principles

From Wikipedia

Agile testing .by Lisa Crispin and Janet Gregory.