Cleveland GiveCamp 2013

This past weekend, I joined 200 developers, designers, project managers, and other volunteers at Cleveland GiveCamp to get tech things done for Cleveland area non-profit organizations. As a truly collaborative group, we successfully created 18 out of 18 solutions that made people cheer!

I work in a relatively quiet environment. We have cubicles and people whisper a lot. It's a pretty closed off and not very conducive to collaboration. This arrangement was a decision the owner made when he designed our new building after getting input from a wide variety of people within the company. To be fair, most of the people that gave him input (including me) have never really worked in any other type environment.

Spending the weekend working for a non-profit in a crazy collaborative environment like the LeanDog boat was an experience that will change how I do things for the rest of my life.

I started the project a bit early by meeting with Mary Kay, the Director of Malachi House, two weeks before the event. I talked to her and her staff about their mission and their message and received a tour to help me understand who they are and what they do. Everyone was great; they were prepared for this with tons of information.

After meeting with Mary Kay, I got in touch with Russ, the guy that handles all of their hosting needs, and he was able to get us up and running with the latest install of WordPress and MySQL. He was super helpful and this gave us a big leg up on our project.

The Friday of GiveCamp arrived and I was excited, like a kid on Christmas morning. A little bit happy and a lot nervous - this was definitely outside of my comfort zone! A handful of us from work were volunteering. We all left about 3pm to get ready and head up to Cleveland to begin our volunteering.

At 5:30, we went through initiation and learned what this was all about and left to meet out teams. Everyone was given a letter on our name tag and pointed to a map with locations that corresponded. I was on Team I and we were in the bow of the ship.

We had a great team - Hank, Joel, Adam, James, Kyle, Mary Kay, and myself. Communication was great. Collaboration was amazing. Mary Kay worked her butt off. I teased her a few times about the fact that she thought she was going to come in and relax - watch a movie or read a book - but she was in high gear, answering questions, giving feedback, detailing content, and so on. She hung tight with us until well after midnight on day one and stayed on with the team the next night as well.

I could get into the details of what we did and how we did it and that would be interesting but suffice it to say that we put in a lot of work over a very small window of time to provide a new content management site for a non-profit that does amazing things for people that have nobody else.

I learned that I need to get out of my comfort zone more often and that environment may be the most important element of collaboration. The workspace provided by LeanDog is open and inviting. Very few walls and not a cubicle in sight. Occasional music pipping from somewhere. A constant hum of busy people. Laughter and a conflict being resolved here and there.

In the end, this was a great experience for everyone that I spoke to. Watching team after team proudly display the results of their project, non-profits beaming and the occasional tear of gratitude; this was one of the best experiences I've ever had the pleasure of being involved in.

I already put next year's GiveCamp on my calendar...

--
Ciao

Anecdotes or Data?

W. Edwards Deming said "In God we trust, all others bring data." We work in an environment where our training and support staff have historically had a lot of input on our end product. Everything from business needs to user interface to deployment strategy.  The struggle we have is that this input is almost completely anecdotal. The stories are dripping with empathy that our support staff (rightfully!) feel for the clients calling in with problems. The end result is, we get software that is easier to support or train instead of software that is easier to use.

Deming and many others since him have put a lot of emphasis on data driven decisions above emotional decisions. It is easy to make emotional decisions and then spend time digging up the facts that support that decision. It is a difficult task to gather all of the data and look through it with an open mind; with no prejudice. I have been involved in medical education for well over a decade so I have a lot of history and collective knowledge. One of the most common mistake I make is thinking that I know what the user wants before I ask her. As a former developer, now business analyst, if I neglect to ask, I tend to steer toward software that is easy to develop.

User driven development is important if you want software that is easy to use - and you do. If you are designing software for a student, talk to the student. If you are designing software for the master, talk to the master. If you are designing software for everybody, narrow down your audience and then talk to them. And after you talk to them and design for them, measure your success. Interface analytics like Clicky give you user data, not anecdotes. Implementing a survey is a great idea. Be careful how you do this or you can end up with a lot of information that isn't helpful. Using the Software Usability Scale allows you to collect data. These things allow you to make informed decisions to create great software that your target users will enjoy using.
--
ciao

photo credit: mkandlez via photopin cc

A [sorta] brief introduction to how I got here

In 1999 I started working in a small start-up software company. We were agile without knowing it. The salesman/CEO would show our product to a prospective client. They would ask if it did X and he would say “It doesn't now but it will tomorrow!” and hang up the phone. He would rush into the next room to the development/training/support/marketing department (which consisted of me and two other guys) to tell us what the new client needed and we would make it so in very short order.

Fast forward a handful of years and we grew up pretty fast. We hired people with “experience” to make us a better company. We hired a VP who in turn hired developers with more experience in making software and as a result, we formalized many of our processes. I became a business analyst (which is still my job title today) and we began to write formal specifications. As I look back, the amount of writing that took place before the start of a project is a little depressing! Our experienced developers made sure that we analysts told them every detail that they needed to know including how the page should be laid out, where the new pieces resided in the navigational scheme, the content, even colors.

Despite all of this, we were successful beyond our dreams. We snared 30%, 40%, eventually 50% of our potential market. We celebrated our wins, all the while, wondering how we could improve efficiency. Stop writing about things we never did. Stop spending man-months doing work that was, in the end, not ever looked at again.

A few more years into this journey and my fellow analyst attended a conference and heard about Agile Development. He brought the idea back to the office and the VP and experienced developers called him a heretic. He didn't know the first thing about how software should be done because his only experience was at this start-up company, not out in the real world.

More years passed, the VP retired, we pushed harder to move to Agile and we were given the go-ahead. We were a dedicated Microsoft shop. Because of this, our transition to Agile was coupled with a transition to TFS as our source control and requirements housing platform. The problems with this approach became apparent to me almost immediately. As we because self-taught and watched all of Mike Cohen's web casts and read all of his writings, I was convinced that an analog solution that we could mold to our evolving process was the way to go instead of using the monolithic trappings of TFS to force us to work in a predetermined pattern. I was ridiculed by the company tech-heads for not wanting to use software in a software company. TFS won out.

Here we are in 2013. We have again restructured with new leadership and new ideas in place. I had little to do with the new round of leadership coming into place, however, they coincidentally(?) align much more closely to what I envision an agile shop to look like. We have designers who design our user experience - crazy! We have an analog work tracking system that works differently for each team (I have dubbed this our 'Information Super-Hallway'). The end of our sprints are a celebration of what we've done over the last three weeks. We break down our work for each sprint collaboratively. Things are coming along nicely.

I want to talk more about how to get to the better place and I hope you'll stay with me for a while and let me know what you think and what you want and what you have to offer.

Ciao!