software solutions / project leadership / agile coaching and training

Expanding the concept of “team”

Posted on January 4, 2016

What happens when a user of your application makes a mistake that has negative repercussions? Let’s say this was not a conscious mistake or an act of negligence, it was just an accident, a simple typo, or clicking the wrong button. Whose fault is it?

Is it the user’s fault for being too careless? Is it the developer’s fault for designing a system that doesn’t protect against such mistakes?

What if we’re asking the wrong questions?

This happened to me recently and a light bulb went off in my head. The reason I was asking the wrong questions was due to the way I was viewing my relationship with the users of my application.

Go read those two questions again.

Is it the user’s fault for being too careless? Is it the developer’s fault for designing a system that doesn’t protect against such mistakes?

The key word is fault. We get so obsessed about figuring out who is responsible for a mistake. What if my mistake was not expecting fallible people to make mistakes?

We say things like, “It’s the users’ job to make sure the data is correct.” Maybe it’s their primary responsibility to make sure the data is correct. But when the data is wrong, IT ends us getting partially blamed.

He’s the crux of the matter – you and your users are on the same team. This changes everything.

Shared responsibility

Everyone is responsible for quality, whether that’s the quality of the code, the way that the system is used, or how people consume the data downstream. This doesn’t mean that it’s all on you, but as a member of a software development team, you are a part of the process.

With that being said, what can you do to ensure that the system is used correctly? You could build checks into the system, write audits to check for issues, educate users on how to use the system better, and be aware of how changes to the application might affect people that use it or consume the data. More importantly, you care about all of these things and don’t dismiss things as someone else’s problem.

Care about what your users care about

You know that feeling you get when the smartphone app that you love releases a new version with a fancy UI redesign, more features, and promises of rainbows and unicorns, yet you hate it because it’s slower and the new features make it harder to use it in the way you like? This happens to me all the time!

That’s probably how your users have felt more than a few times. You probably didn’t mean to do it. But it probably happened because you didn’t know the repercussions of your design decisions.

I just spent two months being a user of my application. Not as a tester or a coder, I joined the users’ team. I sat on their floor, I went to their meetings, I did their job along with them. Now I often used SQL to solve problems, but I lived their life and watched how they did things. I had several moments where I groaned because I had to wait for the next release for something to be fixed, and I realized there are many situations where the system doesn’t allow a user to do something the “right” way and they have to find less than optimal ways to get their job done. I saw them spend days doing mind numbingly boring repetitive tasks because IT didn’t have time to help them.

The reason I ended up joining the users’ team is that we wanted to break down the walls that caused all of these inefficiencies. Many of you have had the aha moment when your developers and testers start communicating and owning quality together and you are able to drastically streamline the software development process. We applied to same principle of working together to drastically streamline the business process as well. And along the way, it shifted my mindset as well.

I’m not there yet, but I’m starting to get a better grasp (maybe even a good grasp) of what my users care about. I’m not sitting with them doing their work anymore, but now I go up and ask them a lot more questions, we’re doing more training and user acceptance testing, and I can relate when they have struggles. But even more importantly, the users are starting to realize that I get it.

Prioritize your users

One thing that surprised me when I sat with the users is how many system issues they knew about that I had no idea existed. “Why didn’t they just tell us?”, I would think. Sometimes they would create tickets for us to fix them, sometimes they might send an email, but the tickets often got lost in the backlog and the issues wouldn’t get resolved. So they just stopped telling anyone about the issues because they felt that no one was listening.

How frustrating! Believe me, in IT we were getting A LOT done. But we weren’t prioritizing our users, and they didn’t think they could count on us.

The other day, I got an email from one of the users explaining some problems they were having. I was ecstatic! They took the time to write that email because they actually think that it might do some good.

I can’t always drop everything to cater to their every whim, but we need a process that will allow users to raise issues and get them resolved. What’s the point of releasing all kinds of new functionality if the existing functionality isn’t sufficient?

I’m hoping to be much more available to the users so that they see me as someone that they can count on. That doesn’t mean just waiting for them to raise issues, but also proactively trying to find issues, show them how they can use the system better, and even volunteering to assist when I see a way that we can use technology to help them do their jobs.

1 Comment »

  1. [...] Expanding the Concept Of “Team” via Jon Kruger [...]

    Professional Development – 1/1/16 – 1/10/16 – The Software Mentor — January 11, 2016 @ 6:06 am

Leave a comment





SERVICES
SOFTWARE SOLUTIONS
I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
PROJECT LEADERSHIP
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
PROCESS COACHING
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
PRESENTATIONS
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010