Releasing the Brakes 1

Posted by Jimmy'z on October 31, 2011

front brake

One challenge of working within a large organization is that there are lots of people with control of the brakes and few people protecting the champions who are trying to affect change. I realize there is a need for occasional braking, but too much pressure on the brakes could lead to a very slow moving organization and will eventually suffocate out the innovators.

How do you fix this? I think it is a trust issue. I think the book Five Dysfunctions of a Team agrees with this. Perhaps my next book should be The SPEED of Trust.

Right now, I’m applying principles of the Dysfunctions book to facilitate better trust between myself and colleagues, and between the members of my team. It forces me to be brutally honest about things, to speak up, and to allow myself to be vulnerable.

Does anyone have any experience in this arena?

Photo by gabork

Ownership

Posted by Jimmy'z on October 24, 2011


Photo By: Jim Lange

Earlier this month, Ryan Money gave a keynote address talking about some challenges he sees in working within a large corporation vs a start-up. Having come from the start-up world, I could relate with some of the frustrations he has also experienced while moving into big corporations. One of the challenges he talked about was Ownership, which I believe is a huge factor in the success of an organization.

Within a large organization, it is easy to get caught up in our own silos with tunnel vision on the things that we work on. We work tirelessly to empty the queue of work that is given to us individually or as a team, but we rarely step back to think of how our work integrates with the rest of the organization.

It is easy to look at things that are wrong that are “not my job” and do nothing about it. Today, I almost passed up reporting a typo on a survey thinking “that’s not my job”, but I decided to take some responsibility for our products (all of them) and took a screenshot and forwarded it to the people who could fix it.

I manage a few people that do a great job of taking ownership of things. I’m grateful to work with those people.

Agile 2011 Takeaways

Posted by Jimmy'z on August 12, 2011

Big Wave Surfer

It’s been a great week at the Agile 2011 Conference. I’ve attended a lot of really good sessions, a few awesome sessions, and luckily only a couple of “meh” presentations. I feel like my mind has been expanded greatly and I’m very excited to come back to the office with some of the new things that I’ve learned.

Here are some of my key takeaways:

Self-Organizing Teams

The team decides how they will work together, they set rules, and work together in ways that will help the team succeed. Managers empower, facilitate, communicate the “big picture”, set vision and goals, and remove impediments.

Focus on Strengths

By focusing on the strengths of the teams, the team members can use their skills to the best of their abilities. This can be done by letting the team members pick their own tasks and share their strengths or abilities with others. By focusing on individual strengths and working on building those strengths, the individuals will grow faster than by focusing on weaknesses.

People Are Motivated by Autonomy, Purpose, and Mastery

When an employee is compensated fairly, autonomy, purpose, and mastery become much greater motivators than $$$. Money motivations are actually detrimental to knowledge workers. They begin focusing on the wrong things and their work is lower quality. By giving knowledge workers the ability to master skills, have the autonomy to determine their course, and a higher purpose, employees will be motivated to build great things.

Daily Scrums Can Be More Effective

Daily scrums can be more effective by setting the context at the beginning of the stand-up. For example, including things like 1) who will be out of the office during the week 2) stories that must be completed that week 3) days left of the sprint

Kanban + Scrum for Maintenance Teams

For maintenance engineering teams, putting Kanban together with Scrum Sprints can be a very effective method of work. My team has constantly faced challenges of Customer Crisis disrupting our sprints and making it difficult to accurately commit to work that will be completed during the sprint. Making the sprints smaller can help because you can more easily commit to what you will complete during the week. If crisis items need to take priority, that is fine and because you are limiting your WIP (work in progress) through Kanban, you can still keep a focused flow of work that continuously delivers working software/systems.

Pairing or Swarming

Pairing or Swarming can help a team become more productive and produce higher quality work. Pairing is basically pair programming, where one person drives the computer and the other person navigates. This allows the person behind the keyboard to use his L-mode of his brain, while it opens up the other to be more creative, see the bigger picture, and use the R-mode of the brain. Swarming is essentially putting multiple people on a difficult task to push it through to completion.

Limit WIP

Setting a limit on the number of stories that can be in the WIP (work in progress) can facilitate pairing or swarming. For example, if you have 6 members of the team and you only allow 3 stories to be “In Progress”, it encourages team members to pair up to get a story done so that another story can go “In Progress”

Beware of Tool Traps

We often trap ourselves into a closed mindset by relying too much on our tools and processes. This can be very much like monkey traps, where a monkey reaches his hand through a small hole in a box to grab a banana. With his hand gripping the banana, his hand no longer fits back through the hole. The monkey could go free by simply letting go of the banana, but will stay trapped because of a refusal to let go. Which of our tools and processes are like the banana?

Lean

“Lean” is something that I should be learning more about. It basically takes the principles of lean manufacturing (Toyota) and applies principles to their companies. Some of the main principles of Lean include: reducing waste, becoming disciplined people, and minimizing work in progress.

Agile on Non-IT Projects

Agile principles and tools can help non-IT teams become more effective and to deliver value to their organization more quickly, and with higher quality. We looked at several case studies where law offices, insurance companies, construction jobs, and manufacturing plants adopted Agile methods and saw a strategic improvement in the way they delivered their products. The ironic thing is that much of Agile came from manufacturing, so the use case essentially brought best manufacturing practices back to another manufacturing company from a software perspective.

Office Design Matters

Office space can be optimized to better facilitate Agile practices. Private offices and cubicle walls can be detrimental to the efficiency of an Agile team. Open areas for pair programming, whiteboard spaces, and walls for post-its can help a team collaborate more easily. A radical change in office space cannot successfully be mandated from the top down. It has to be something that the team decides would be useful. Many teams that make the transition, while skeptical at first, find it to be very effective.

Agile Games to Teach Principles

Games can be a very effective way to teach principles to a team. Games can be invented from simple craft materials. An effective model for game invention is: 1) identify the problem to be addressed 2) Identify 2-3 Agile principles that would address the problems 3) build the game and Keep it Simple Sir 4) test the game 5) Prepare retrospective questions to facilitate learning.

Story Mapping

Story Mapping gives dimension to user desires for changing the world. By simply using different colored post-it notes, your team can quickly map out User Tasks, User Activities, Stories, and Release Features. Business people and developers alike can easily reference areas of the Story Map because of its simple organization.

All in all, it has been a great conference. For those who attended this event, what gems did you come away with?

Photo by thelastminute (PhotographyIcon)

Using Mac Spaces

Posted by Jimmy'z on April 07, 2011

How I Use Spaces

The first time I tried using Spaces on the Mac, it really didn’t click for me. I recently found myself frantically trying to keep up with everything at work and getting distracted mid-thought by other tasks, that I finally decided I needed to try something new.

I decided to give Spaces a try and really stick to it. Today was day 1 in this experiment. I enabled 4 spaces and have designated the spaces as follows:

Space 1: My primary workspace (browsers, text editor, Evernote, etc.)

Space 2: Misc. (haven’t figured this out yet)

Space 3: Communications Apps (Skype, Mail, iCal)

Space 4: Media (iTunes, iPhoto, Twitter)

I actually used the option to constrain those apps to the designated spaces. I use hotkeys to navigate between spaces and I believe it actually helped today. I’ll stick with this for a while and see how it works out for me. Stay tuned!

(Photo used under Creative Commons by Flickr user: mattbrett)

Leadership Mistake 1

Posted by Jimmy'z on April 02, 2011

sad

I recently sat in a meeting with some of my reports and another manager. One of my team members said something that according to the other manager wasn’t accurate and raised the tension in the room. The inaccurate information likely came from me, but not in exactly the way I said it. I ended up defending my own communications (potentially sliding the blame for misinterpretation to the team member) instead of taking full responsibility for the bad communication myself. After the meeting I realized I had made a mistake. I’m writing this as a reminder to myself that I should take the heat for my team in situations like these.

(Photo used under Creative Commons by Flickr user: kalexanderson)

PositiveSSL Untrusted Connection in Firefox

Posted by Jimmy'z on March 19, 2011

I recently ran into an issue with a PositiveSSL Wildcard certificate that I bought through NameCheap.com. The certificate was working correctly on all browsers except Firefox on Windows. It was giving me an untrusted certificate error.

The fix is found here. Basically, you need to install an intermediate certificate chain so that Firefox can follow the CA chain up to a trusted Certificate Authority. Many browsers already have this chained certificate info, but for some reason, Firefox on Windows doesn’t have it.

The PositiveSSL.ca-bundle can be found here.

If you are using Apache, the config will look like this:

SSLCertificateFile /etc/ssl/crt/yourDOMAINNAME.crt
SSLCertificateKeyFile /etc/ssl/crt/private.key
SSLCertificateChainFile /etc/ssl/crt/PositiveSSL.ca-bundle

Make sure you restart Apache.

/etc/init.d/apache2 restart

Don’t Make Me Think

Posted by Jimmy'z on November 24, 2010

Outside of my job at FamilySearch.org, I have my fair share of web development work that I do on the side. An area that I’ve always struggled, especially when the concepts of the new site are entirely original, is user interface design.

I recently discovered a new Stack Exchange community built around User Interface design. I found a discussion thread about which books the community’s designers recommend to developers. The answer that by far had the most votes was Don’t Make Me Think.

I decided that I had to read this book. I bought the Kindle version of the book and read it on my Droid Incredible. This worked well, except there is no way to zoom in on the pictures, so it was a bit hard to get everything I needed to out of the tiny pictures on a small screen.

Don’t Make Me Think defines some simple design principles and why they are important. It teaches the Why, What, and How behind making good UI choices. I can now look at sites like Amazon.com and clearly see where they are following good UI principles, and then I look at some of my stuff, and think “Woah, I really missed the boat here.” Most of my stuff isn’t that bad though. I was surprised at how many of these things I have done right already. I now feel like I have a rulebook that I can go to when making tough design decisions.

Some of the principles I like most from the book include:

  • The Homepage needs to explain the purpose of the site.
  • Page hierarchy is important to make the sections of your site easily identifiable.
  • Page titles are needed on every single page.
  • Users muddle through sites and don’t necessarily learn how to use them properly. As an example, there is an astounding number of people that use Google and Yahoo! as their browser’s address bar. It isn’t the proper way to use it, but they manage to get to the sites they are looking for.
  • Clickable things should clearly appear to be clickable.
  • Your search bar should actually use the word “Search”
  • Usability testing with 1 user early on in the project is more important than testing 30 towards the end.

There are many more concepts that I don’t have time to write here, but if you do anything with web development or design, this book is really helpful.