Commit Your Company to Diversity


The Harvard Business Review article, How Organizations Are Failing Black Workers — and How to Do Better, points out that many companies have a soft commitment to real racial diversity. I recommend giving it a read. Here are five takeaways I’m bringing back to my company:

  1. Companies use relationships to find talent. Companies must encourage employees ( and in particular, executives) to get involved outside of the office in racially diverse arenas (e.g., mentoring, internships, Junior Achievement). Go and be where people don’t look like you.
  2. Define specific, measurable steps the company will take to encourage racial (and gender) diversity? Without targets, managers commitment will be squishy.
  3. Don’t allow job stereotypes to influence hiring decisions. For example, not all entry level developers are young, scruffy hipsters. And not all sales reps are cute young women.
  4. Sponsor people of color in your company. Be their advocate and seek promotion of and for them.
  5. In order to feel included and comfortable, people need to be around others who look like them and have shared experiences. Commit to hiring more than just one person of color to build a critical mass which encourages others of similar faith, race or background to join the team too.
  6. Executive must be diverse too. Having a person of color in the board room makes it much easier to hire employees of color who will feel comfortable and respected within the company.

The Real Issue with Apple Watch 3

apple-watch-brick 150Business Insider posted a thoughtful take on the much publicized problems with the Apple Watch 3 launch. I’ve been excited about a new Apple Watch, especially the added LTE capabilities, although I can’t really say why. It’s certainly not because I want to take calls via the Watch.

The article points out my dilemma perfectly by talking about why adding LTE doesn’t really shift the job people use an Apple Watch for. It’s a great point. As an agile practitioner, I’ve become more enamored with the “Jobs to be Done” methodology. What job is your current project or product being “hired” to do?

What Is a “Stand-up” and Why Do We Do It?

LINK: Guide to Agile Practices: Daily Meeting

standup-modell1I can’t count the number of times I’ve had to explain what a “stand-up” meeting is. I usually handle this question off-the-cuff, explaining that the meeting is daily, time-boxed (time-limited) to 15 minutes and usually includes each team member answering the Three Questions.

Today we had a high school senior job shadowing several of the IT folks and I was tasked with showing him the stand-up meeting used by many of our development teams. I wanted him to have a take-away from the meeting to help him remember the “what” and “why” of our stand-ups, so I turned to the Internet. I came across this fantastic definition of  the stand-up meeting (or “Daily Meeting” as they refer to it) from the Agile Alliance.

Why Israelis Brag About Their Big Head (Rosh Godal)

LINK: Word of the day / Rosh gadol: What sort of head do you have?

In this article, Shoshana Kordova does a great job of explaining the Hebrew terms rosh gadol (“big head”) vs. rosh katan (“small head”). While telling someone that they have a big head may be career limiting in English speaking circles, telling them they are rosh gadol is paying them a high compliment. Rosh gadol describes the ability to see the big picture as opposed to focusing on the small tasks. Hit up the article for a helpful discussion of the difference in these two types of people and why organizations have (and need) both.

Years ago a great post on the Joel on Software blog discussed how developers would ideally be rosh gadol. In reality, your team will consist of both rosh gadol and rosh katan resources. As a project manager or technical lead, identifying which type of thinker each team member is can help you guide them towards tasks they’ll be more comfortable and efficient with. It might also help you manage your expectations when dealing with these two types of individuals.

Leaders Building Leaders Conference

Union College Division of Business hosted a great conference today called Leaders Building Leaders Conference during the college’s alumni weekend. I was fortunate to present an Agile form Managers topic during the conference. I’ve attached my slides here and will try to get some notes from other sessions I’ve attended posted here shortly.

Agile Intro – Managers slides.

Jony Ive and Design at Apple

I’ve been an Apple fanboy since my days using an Apple ][+ back in 1981. Apple has always been about design, but with Steve Jobs return in 1997 and the rise of Jony Ive, the focus on good design reached an entirely new level. I’m fascinated by how Apple makes this work. In many projects I’ve worked on, good design is seen as a luxury to be considered “if there’s time at the end of the project.” Hint: there’s never time at the end of the project. I think good design is part of the technical excellence that must be the foundation of all projects in order for them to be flexible, sustainable and maintainable. For a glimpse into who Jony Ive is and how he’s changed Apple and industrial design, check out the interview.

Jony Ive

Photographed by David Sims, Vogue, October 2014

Can “One Windows” Fix Microsoft’s App Problem?

History of Windows logosWhat Does One Windows Mean for You? – Don Jones on Pluralsight blog

The idea of one Windows is intriguing, but as Don points out, it can mean different things to different people. The elusive “one application to rule them all” approach to cross platform support has been around for decades without ever truly coming to fruition. My experiment with Microsoft Surface over the last year has taught me that the tablet apps and desktop apps are entirely different animals. Microsoft’s attempts to build one operating system that does both desktop and touch at the same time has produced an OS that does neither particularly well.

I hope that Microsoft is leaning from the dismal uptake of Surface (and other Windows tablets). It’s all about the user experience. While people say they want to run all their Windows apps on any device, if the experience becomes a frustrating series of impossible-to-click buttons and text editing nightmares, they’ll decide tablet computing just isn’t worth it. Don’s view is that much of Apple’s success with developers hasn’t been because of write once/run anywhere software. Instead, he suggests that Apple’s iOS and desktop application boom comes from allowing developers to reuse code to create separate applications that cater the strengths of each platform. I agree. Microsoft has to embrace the advantages of each its various computing platforms (phone, embedded, desktop, tablets and Xbox) while making it easy for developers to move and reuse code between all of them.

Does Iterative Development Stifle Innovation?

bulb in hand“Shorter sprints leave less time to recover if a promising but risky initial approach fails to pan out.” – My Primary Criticism of Scrum, by Mike Cohn

I came across the above blog post from Mike Cohn today and it got me thinking about whether and how my development teams innovate. It is definitely easy to get into a rut, where the team is constantly focused on the simplest possible solution and burning down. It is up to the project leads (Project Manager or Technical Lead) to be intentional about encouraging innovation within the boundaries of the agile process. For our project teams, this is a two step process:

First, project leads must look for opportunities to innovate. Sometimes this will result directly from a Retrospective improvement. Other times, the project leaders need to recognize when a project has a need for innovative solutions and the space and time to pursue those solutions. There is no science here, this is a balance of project resources (people and time) against the value of the innovation.

Second, once we make the decision to explore a new technology, approach or process, we break down the steps to complete this exploration. We define a user story, estimate the story and break it down into smaller stories as necessary. Next we task out the steps needed to satisfy the story or stories and, finally, we execute the stories in time boxed iterations.

I’ve found it useful to place time limits on research tasks. Research is one of those activities that can go down the rabbit hole. When asking developers their Definition of Done for research tasks, it’s not uncommon to hear, “I’ll know it when I see it.” I could work with the developer to force them to define “done” for the story or task, but instead I usually just say ask them how long they want to spend on the research (e.g., four hours, full day, whole week). We use that time frame as a hard stop to discuss the next steps in the process. For example, is more research needed, should we implement the solution or is the approach is unworkable?