Day two started with another quick planning session. This one went a lot faster. We had fewer topics suggested and everyone was more familiar with the format. This allowed the first sessions of the day to get started a bit early. Of course, following the Rules of Open Space, "Whenever it starts is the right time." So I suppose everything started precisely on time.
I started the day with a session on refactoring. This was a good session; well attended and well presented, but I was in the mood for a little more interaction, so I followed the rule of two feet and wandered into a discussion on introducing Agile in a Hostile Environment. Right up my alley. I failed at this numerous times before my first successes, so I had plenty of experience to draw upon. The attendees were primarily developers and leads who were sold on Agile, but found it difficult to introduce into their teams. I could empathize with them. Each of their attempts was met with a lot of resistance.
We discussed approaches that involved avoiding too many buzz words, identifying one likely ally, or simply leading by example. But the best advice had little to do with Agile and more to do with simple human nature. Listen to your team. Get to understand their personal pain. And then help them relieve that pain. While you may genuinely believe that TDD will solve a lot of problems for the team, if their immediate pain is with the build, then get CI stood up first. People are usually far less resistant to change than we give them credit for. The problem is often that they are already uncomfortable. Sweeping change is too big, too vague, and too risky.
I do have another piece of advice for those we are struggling in environments that are highly resistant to change. Leave. Sometimes it is better to change the people you are around rather than try to change the people around you. I am not suggesting we all quit at the first sign of resistance. But sometimes there comes a point when one realizes they are merely tilting at windmills.
My next session was on User Experience and User Centered Design (UX/UCD) in an Agile environment. My objective for the discussion was to find practices that served UX/UCD well and mapped to iterations. The predominant thinking is that UX/UCD is an up-front activity that must be complete prior to development. I'd like us to continue to challenge that thinking.
A great deal of the early discussion was around Contextual Inquiry as a part of requirements gathering and User Testing during the development cycle. We shared stories of success, stories of near success, and stories of sheer frustration. But we struggled to come up with additional techniques or insights. I was enjoying the discussion, but felt the session was coming to an early end. We were covering the same ground with no new insight.
And then Jeff Patton spoke. Quiet. Unassuming. Jeff stated that there are essentially three facets to the user experience. He drew a pyramid and separated it into three horizontal sections. At the base, he wrote "Utility" and explained that this is what the system does. Contextual Inquiry helps us define this. In the center section, he wrote the word "Usability" and explained that this is how the system is used. User interviews help us define this. Finally, at the top he wrote "Aesthetics" and explained this is presentation. It is important to understand the practices and how and where they apply.
You need to have Utility covered first. This does not make it the most important, but if the application cannot perform the intended function, it is a failure. It does not matter how usable or pleasing it is.
You need to have usability covered next. If an application is capable of performing the task, but is difficult to use, you will have less success. If users have alternatives, you risk losing them to something easier to use. If your users are a captive audience, you will see increased costs in training and re-work or they will do everything they can to avoid using the software.
Finally, you need aesthetics. This is where the psychological aspect is most significant. If people are pleased with the interface, they may actually tolerate a lack of usability. Jeff used Apple as an example. Design (aesthetics) are very important at Apple. While their products are not always easier to use, you do not mind the minor inconvenience. You are pleased to use the iPhone. It is ok that you have to scroll over three pages to find the app. The WAY you scroll the pages is kinda fun.
There are plenty of applications that prove Utility and Usability are sufficient. Craig's List is so anti-aesthetically conscious, it seems the lack of design IS the design. People don't care that it is plain; it does exactly what they want and it is easy to use.
Jeff's points resonated with me. I knew these things, yet failed to consider them as I was looking for techniques that could be mapped to iterations. If you don't understand how the practice applies and why you're doing it then it doesn't much matter if you do it before, after, or during an iteration. You're probably going to get it wrong. Figure out what you're trying to achieve, then figure out how.
I really enjoy conferences like these. Low ceremony, high value.
There are three ways to learn; push, pull, and share.
Push is where you sit in a class or session and someone walks you through a lesson or seminar. This is typically low signal to noise. You are going to get a lot of information, only some of which you are currently interested in or can use.
Pull is where you seek out the data and gather it for yourself. This is better signal to noise. You can control the flow of information and can target the information to your specific interest or need.
Share is where two or more people freely exchange ideas. This is my favorite form of learning. Everyone learns and if the conversation is truly a balanced and free exchange, there is all signal and no noise.
SDTConf and other open spaces are Share learning.
