Jan 10, 2014

The Creatives on Agile and QA teams

“If you are not willing to risk the unusual, you will have to settle for the ordinary.” — Jim Rohn

In a recent Slate article about bosses rejecting creativity and thinking outside the box,Berkeley professor Barry Staw is quoted on why no one really wants Creatives on their teams, despite the celebration of successful innovators that abound, especially in IT. To be clear, these are not the common idea of IT Creatives who are UI designers or who otherwise deal primarily with aesthetics. Staw describes creative team members as those who share these characteristics:
• they are risk takers, willing to try an unproven solution
• they are non-conformists, willing to defy convention and authority in their search for an optimal, rather than barely satisfactory, solution
• they are persistent, particularly in the face of frustration or repeated failure
• they are flexible and willing to reformulate a challenging problem rather than give up
• they demonstrate a high degree of focus, potentially to the detriment of social niceties, in their obsession with the challenge at hand

Staw argues that we really don’t want too many of these types or to reward them significantly, perhaps with justification, since organizations rely on rules and respect for power structures to maintain control and keep people on a unified path. However, if we eliminate them from our teams or overly discourage them, we increase our risk of several well-documented biases that sabotage our quality and ability to innovate.

Risk taking
If our organization is struggling with an ongoing issue, perhaps with quality or timeliness of delivery, how do we expect to improve if we continue to do as we always have? The unproven alternative may or may not work, but trying it does help us discover more about the relative value of our different options.

We are by nature risk-averse and much of the time, this is a good thing. Teams need diversity to really excel though, so a sprinkling of those that challenge us to take a chance help us continue to learn and improve over time.

An ongoing challenge in any organization or team is to structure those things you really need to do in order to have smooth coordination and communication among the team members, while not being so restrictive that new ideas and personal innovation are stifled. The Creative may be the one who makes sarcastic jokes in scrum, outright asks “What if we did this instead?”, or “What will happen when we get to the end of the year and they want to do an annual report, but all the data doesn’t come in until mid-January?” . These kinds of questions may lead to some discomfort and intense discussions. I maintain that these are great signs that we have identified something we really should be talking about sooner rather than later.

When we resist these provocative questions, we tend to blame the messenger for being the one to bring up what others also know but are hesitant to mention. (Margaret Heffernan has a great TED talk on the dangers with the issue of Willful Blindness.) These challenges can be what save us in the long run from being forced to address the issue later in the project when it is even more costly and difficult to mitigate.

The Creative on your scrum team is the person who looks intrigued and offers to take a look at the latest bug that has everyone else doing the “stare at the floor and maybe they won’t ask me to take that bug” thing. You know the sort of bug I mean: – it’s the kind where people look a little stunned perhaps because they hadn’t thought of that use case and they don’t really even know where to begin, but they agree it is “Not A Good Thing”. I have also seen this with bugs that have been “fixed” and re-opened multiple times because the fixes really don’t get to the heart of the problem. This is a particular challenge in older legacy systems where the function under scrutiny may not be well understood and no one really dares touch it for fear of making things worse.

The Creative’s flexibility, though, allows them to consider different angles and possible causes. They never seem to lack for an idea to try or another place to do some research. Some of their questions or proposals may trigger quite puzzled looks as others try to figure out how on earth they came up with that idea, but when you are faced with a stumper or a chronic impediment, those tangents are often just what the doctor called for.

IT is full of situations where we need to figure out a solution to frustrating new and well-aged problems, so an ability to persevere in the face of finding things that don’t work is a definite strength in this field. The key is to balance time constraints from a business perspective against the value of the solution. However, giving up at the first roadblock tends to lead to lower quality and user experiences. If it seems easier and acceptable to leave a known issue in place now when we are time crunched to leave a known issue in place, after the release it can be far worse to try to resolve the issue once it is in front of the customer and, more to the point, far more difficult to erase the impact to the application’s reputation.

For testers and dedicated QA members, persistence in the face of failure is particularly valuable. It is common for testers to be viewed as trying to “break things” in their quest to discover what the application under test can and cannot do. The irony of this is that the more the tester “fails” at this objective, the more confidence we as a team have in the system. When a tester brings up a possible problem and the resolution is that it is not a bug, this is a good thing for the team, even as the tester may feel like they wasted peoples’ time and energy on a non-issue. Being able to take those “failures” in stride and see their value to the whole team takes a certain kind of tough skin and willingness to keep trying

Extreme Problem Focus
The team Creatives are also subject to a kind of environmental blindness as their attention is wrapped around a particularly interesting challenge. (Okay, the odd problems are almost always interesting to these sorts, I will admit.) They may need to be coached to know how to interact better with the rest of the team and those outside of the team, or you may be able to let them sit in their corner and stay focused on their issues. They may consistently bring their laptops to meetings and seem a thousand miles away when asked a direct question (assuming they make the meeting at all since they missed their meeting reminders). Their scrum reports and emails may be overly detailed since it only makes sense to them that people want to understand the issue as deeply as they do.

This focus is great for keeping them on task and you know that if you give them a tough problem, they will chip away at it to the best of their ability. Hopefully your team is supportive and diverse enough in character that this can be absorbed as just another curiosity or your Creative has enough interpersonal skills to know when they need to get their head back in the world.

Agile and QA teams both have their compliment of Creatives who don’t fit the mold yet provide tremendous value to the team through their ability to see things in a different way, to persevere in the face of frustration, to stay focused in the middle of myriad distractions, and take a chance on the unproven path that many would not be willing to take. Staw has valid points about the need for non-Creatives in organizations to provide stability and predictability, but we are far less able to innovate, to learn, and to improve if we forget to throw in enough Creatives to keep the environment dynamic and growing.

About the Author

Object Partners profile.
Leave a Reply

Your email address will not be published.

Related Blog Posts
Natively Compiled Java on Google App Engine
Google App Engine is a platform-as-a-service product that is marketed as a way to get your applications into the cloud without necessarily knowing all of the infrastructure bits and pieces to do so. Google App […]
Building Better Data Visualization Experiences: Part 2 of 2
If you don't have a Ph.D. in data science, the raw data might be difficult to comprehend. This is where data visualization comes in.
Unleashing Feature Flags onto Kafka Consumers
Feature flags are a tool to strategically enable or disable functionality at runtime. They are often used to drive different user experiences but can also be useful in real-time data systems. In this post, we’ll […]
A security model for developers
Software security is more important than ever, but developing secure applications is more confusing than ever. TLS, mTLS, RBAC, SAML, OAUTH, OWASP, GDPR, SASL, RSA, JWT, cookie, attack vector, DDoS, firewall, VPN, security groups, exploit, […]