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.


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?

What Sports Doesn’t Teach Us About Winning

basketballI started this post back in January, but just realized I never published. Hope you still enjoy…

I’m at a basketball tournament in Kearney, NE this weekend where my son’s team is getting hammered by the competition. It’s not their fault really. There are a number of reasons they don’t play well (which I won’t go into here), but needless to say, their coach has a very difficult job ahead of him as we look towards two more difficult games tomorrow. It reminded me of a very important principal we should apply to our projects and other organizational initiatives: How do we define winning?

The goal of a sporting event is usually evident to all of the participants (i.e., spectators, players and coaches). Sports are usually made up of winners and losers as measured by score, time, distance or finish line. In the real world, wins and loses may not be so obvious (even in sales, which is more blood sport than most business areas). As a project manager, I often find that the project participants start out with differing assumptions about the goals and objectives of a particular initiative. Unless project leaders take care to define project goals, the team will have no hope of measuring wins and loses, successes and failures.

As most project managers know, the key to success is setting measurable goals. It’s not enough to just have goals, but those goals need to be SMART. They also need to be in alignment with a vision for the project, team, division or organization. Ideally, our goals should allow us to get at least part way towards realizing our vision. One of the best methods I’ve used for goal development is to lay out the vision and allow the team to come up with the goals. Not only is this a phenomenal way come up with realistic goals (since the team probably understands how to get there better than you do), but you are also communicating those goals with team and getting buy-in all at the same time.

As for my son’s team, coach better figure out how to get that team focused on the little goals that lead to wins. If those boys can improve their rebounding, turnover ratio, shots in the paint and free throws, they will have concrete measures of progress and success. If, however, they stay focused on the more “obvious” goal reflected on the scoreboard, it’s going to be a very long weekend indeed.

What the Customer Wants

Girl Eats Huge Sunday

During a recent customer design session (combination requirements meeting and design discussion), I was surprised when one of the stakeholders quoted me as saying that it was the development team’s job to build whatever the customer wants. I paused for a second and thought, “What did I say that was interpreted that way?” I know I would never intentionally tell a customer that our job is to build whatever they want. Our job is, of course, to build what the customer needs. There is a world of difference in those two statements and I took care to explain that difference to all of the stakeholders at the table. Neither of the teams truly knows what the application we’re developing will look like in the end. We all have ideas (at least as many different ideas as there are people on the team). My job as an agile project leader and business analyst is to facilitate communication between all of the players in a way that uncovers customer needs and results in a system that can meet those needs in way that our customers find at least acceptable (but hopefully exceptional).

The 6 Sins of Project Leadership

The 6 Sins of Project Leadership

So many PM articles focus on the nuts and bolts of project management practices. In this post, LeRoy Ward focuses on how to lead projects and project teams. I can’t agree with the need for authenticity enough (sin #5). As one of the commenters points out, being authentic is about being the genuine you. You don’t have to highlight your warts for everyone to see, but it’s OK to admit that you don’t know the answer while also demonstrating confidence in your ability to figure it out (hint: that doesn’t mean you have to do it by yourself…see sin #2).

LeRoy’s suggestion that you act as the CEO of your project (sin #1) has come into to sharper focus for me recently. I’ve worked on many projects where getting all the details right was more important than getting the project done. I’m not suggesting that buggy or half-baked software should go into your production environment, but PMs should be looking for ways to get working portions of software projects in the hands of the customers as early as possible. In the past few years, I’ve started evangelizing about how a system waiting to go to production provides no value to the organization.

Check out the article. It’s a good read.

NOTE: Projects At Work requires registration to read. This will result in some graymail, but Projects At Work consistently delivers good content to my Inbox as well.

When the Customer Insists on the “Wrong” Design

GarageI was recently confronted with a familiar situation: a customer telling my team how to design the system during a requirements session. For those of you unfamiliar with application development projects, let me explain the scenario this way; you’re building a new house and you tell your architect that you will need a place to store all of your gardening tools and lawn equipment. You instruct her to design a second-story storage area into your garage. “Wait,” says the architect, “I think I can get you all the storage that you need if we just add a built-in shed on the back of the garage.”

“No,” you insist, “the second-floor storage area is just the ticket.” What should the architect do? What should my development team do? The way I see it, we have a handful of choices:

  1. Beg for forgiveness (not permission) and do it the right way our way.
  2. Debate with the customer until we’re blue in the face about the right way to do it.
  3. Sell the customer on the right approach our approach.
  4. Throw our hands up and walk away form the project.
  5. Just Do It (the customer way).

Here’s what happens in the first four scenarios above:

  1. We tick off the customer, probably miss their vision and end up owning (responsible for) the feature/process/system in the end.
  2. We tick off the customer, waste a ton of time debating over pointless details and end up right back where we started.
  3. We convince the customer our approach is best, probably miss their vision and end up owning the feature/process/system in the end.
  4. Tick off the customer, get reprimanded for not making it work and hopefully don’t get fired or sued.

More often than not, the best approach is to swallow our pride and “Just Do It.” I know what you’re thinking. I’m taking the easy way out. “Just Do It” the customer way and then blame them when the project goes down in an inferno of failure. Except, that is not what I’m recommending. No, what I’m suggesting is that there is a strong possibility that neither of you is right and that by insisting that you are (or even quietly believing you are), you are setting the project up for failure.

How can this be, though? Developers know how to write software. We’ve studied database normalization,  object relational mapping, decoupling and user experience design. We’re the experts…in software design. But are we experts in the customer’s business? While we may have years of subject matter experience, how well do we understand our customer’s specific business processes?  Even if we have spent many years inside the customer’s team, working with them and their current systems, we may not understand their vision for the project. Heck, even the customer may not truly understand their vision for the project.

As an Agile practitioner, I believe that respecting the customer’s requirements is important. It’s important not just because the agile manifesto says so, but because (along with the rest of the principles covered in the manifesto) it’s the most effective way to uncover the real requirements. I’m not suggesting that we should blindly follow the customer’s lead into a situation that my team or I believe to be ill-conceived. I’m saying that we should respectfully explore the customer’s ideas. Doing so in small, well-planned chunks will usually bring more clarity to the goal that the customer is trying to achieve. So maybe I should rephrase my approach as “Just Go With It.” By exploring the customer’s vision/concept/requirement, we allow ourselves to understand more about them, while also showing the customer that we are listening to them. Not only does this improve our understanding of the customer’s vision, but it also develops credibility with the customer, which hopefully makes it more likely for them to respect you and your vision down the road.

First Post

Wayne and Garth standing togetherI’m launching the blog with all of the fanfare and pomp reserved for new public-access cable TV shows. If this goes as planned, my first post will pass quietly like the sound of a tree falling in an empty forest. Instead of searching for something profound and meaningful to use as the cornerstone for this little encyclopedia of Keil, I decided to just blurt out something and avoid all of the procrastination normally associated with trying to write the perfect post.

Fortunately, today revealed a pretty good topic for discussion when we extended an offer for a new staff member who is a former co-worker that I’m really excited to work with again. We won’t have his response for a couple of days still, but the incident brings to light something that I think is very important for project managers and those in leadership positions in general: The power of a positive (or hopeful) viewpoint. Three weeks ago, I learned that one of my developers had taken a position with another organization. She was a fantastic contributor on our team and we all knew that she would be tough to replace. It would have been easy at that point to focus on the problem (“great, we’ll never find another Lisa”) and skulk about, projecting that negative attitude on my team.

In my opinion, good leaders regularly find opportunity in the challenges they face. Now I’m aware that some situations have no silver lining and simply require the team to grind out the problem. In most cases, however, opportunities can be found by looking at the issues through the right lens. In our recent situation, the challenge of losing a good team member brought the opportunity to bring on someone who will be even better. Even in those cases where little or no chance for benefit can be seen, remember that a positive outlook that is focused on the end goal will help your team drudge through to a resolution.