Archive of articles classified as' "project management"

Back home

Japanese vs. Western models of decision making

11/09/2014

I was reading a book about The Toyota Way last year (sorry, can’t remember which) and something that stuck with me was a section on Japanese versus Western decision making*. The diagram was something like this:

japanese-vs-western-decisionmaking

The crux of it is, Japanese companies like Toyota spend more time preparing for a decision, and less time executing. Western companies reach a decision earlier, and then execution has all sorts of problems. It’s also important to note that Japanese companies often reach the “end goal” sooner.

Preparation involves building consensus, but that doesn’t mean it’s all talk. Japanese companies pioneered set based design and prototyping, which allows them to try out a huge number of ideas cheaply. By the time a decision is made, they’ve “thrown out” about 90% of the work they’ve done!** However, once the decision is made the execution goes smoothly.

It is easy to see how Japanese decision making maps to businesses with a clear distinction between preparation/pre-production and execution/production, such as traditional manufacturing. It can be difficult to map to pure product development. Keep a few things in mind.

  • Consensus isn’t just discussion and design. Big-Design-Up-Front is not preparing for execution. BDUF is a woefully incomplete form of execution. Building consensus means actually implementing things in order to rapidly learn.

  • Consensus isn’t a democracy. Toyota has a very hierarchical structure and people have very clear responsibilities. The goal of consensus-based decisions is to make better decisions, not to achieve some Platonic ideal. Difficult decisions are still made, but the role of the executive is to manage the consensus-building process, rather than “just hurry up and making a decision.”

The Japanese model is built in to cross-functional teams. Consensus isn’t achieved by the heads of Engineering and QA signing some agreement in blood. If that agreement ends up not being a good idea- and it almost never is!- you end up with the Western execution experience. On the other hand, cross-functional teams have much more interactivity and iteration going on, and overall execution is much faster.

People will get upset. Take responsibility for your decisions, and acknowledge some people will get upset by them. However by making sure their concerns are thoroughly heard and discussed before execution, you will make sure they don’t keep pulling things off-track.

Anyway, there’s lots of good writing on this topic, and I highly suggest checking some of it out if it interests you. This is just my software development-centric take.


* I’m just calling these the Western and Japanese models of decision making. They are clearly not the way all decisions are reached in the respective countries. In fact these generalizations may not even be true anymore. Whether Japanese or American companies behave this way is irrelevant. The names are just proxies for different types of decision making.

** Obviously the work isn’t thrown out, since they’ve learned so much from it. But if the effort were raw materials, I suspect 90% of it would end up in the trash, depending on how a set is developed and culled.

No Comments

Everyone should take vacation at the same time

31/07/2014

Throughout my career I’ve always seen people struggle with taking vacation. People are too wrapped up in what they’re doing. Managers can’t allow critical people to go missing. There are weeks of trepidation and handover and “I don’t know how to fix that” emails. To a large extent, this can be fixed with shared code ownership, comprehensive automated testing, and all those types of good development practices. I have a better idea, which I saw in great use at CCP (which for a long time did not have those good development practices):

Everyone vacations at the same time.

In Iceland, this was a cultural thing. From what I understand, employers aren’t allowed to deny you vacation between May and September. Everyone goes on vacation in July. The office is empty. Things just go relatively smoothly as no one expects anything to get done during July (its a great time for side projects). This “July slowdown” wasn’t limited to CCP, as people who need visa renewals in the summer no doubt learn.

In Atlanta, the studio just closed down for two weeks in July.

In both cases, there may be a skeleton crew to keep things running, people on call, etc. Its just that no one expects anything non-immediate to get done. This has many benefits: its easier to plan for, office costs are cheaper, there’s a single silent period rather than months of rolling disruption, everyone takes a refreshing vacation, and much more. It’s pretty much the only vacation policy I’ve seen that was largely resilient to the pressures that keep people from taking vacation. To be sure, some people were screwed over by bad managers, but (in contrast to most other management offenses) this was largely due to particular managers and not underlying cultural causes.

If you see the people around you failing to take the proper vacations everyone needs to keep going, I’d encourage you to try having everyone go on vacation at the same time.

6 Comments

Optimize iteration length for feedback

4/06/2014

If there is one theme that is weaved through all of Agile’s principles and practices, it is feedback. TDD. Pair programming. Continuous delivery. Stories. Estimation. Reviews. Retrospectives. On-site customers. Feedback comes up against and again. Feedback from code, the team, and users.

As I mentioned in my previous post, I am a big fan of short (one week) iterations. Feedback is why. If your team works in three-week sprints, and mine in one-week sprints, we have three times the feedback. I have three times the opportunities to learn and improve. While you debate whether to try something new in a future sprint, we try it out immediately and evaluate whether it’s working every week, until we accept or reject it. We become three times as good at estimation. We know in a third of the time you do that a solution to a problem works.

Perhaps in some situations one-week is too long. You could try two-day iterations early on with a new project and new team. Or perhaps, on a legacy project, even two weeks is too short and you don’t get enough work done to get good feedback. You can get faster feedback going to three week sprints, rather than having to wait four weeks (two two-week sprints). The point is to optimize for feedback. This means you should prefer shorter sprints, but there can be exceptions.

The benefit of feedback cannot be overemphasized. In a previous post, I said no single aspect of the Toyota Production System is more important than the others. That’s not entirely true. “Continuous Improvement” can bootstrap the other TPS components. You improve through getting feedback. It follows that you should do anything you can to get better and faster feedback.

2 Comments

Should a team be able to abort a sprint?

2/06/2014

After my second retrospective on a new project, I unloaded some pretty harsh criticism about what we were building. I felt it was a “solution in search of a problem” and “not high value.” After proposing an alternative and convincing everyone to change direction, our sort-of Product Owner blasted me for not bringing my issues up sooner and basically wasting two weeks of work. I said I had voiced my concerns, but not strongly or formally, because I was focused on getting the sprint work done. My feeling was that it wasn’t constructive to second-guess things in the middle of a sprint, and that I trusted the people who made the decisions. Especially as the new guy on the team, I leaned towards agreement.

We both had a point. As a senior person, I had a responsibility to speak up. As a team members, I had a responsibility to get our work done. I don’t know if I made the right choice in this instance. Perhaps if I argued too loud too early, I wouldn’t have had enough credence for people to believe me, and would have been in a worse spot at the end. Or perhaps I would have saved two weeks or work.

This is one more reason I prefer one-week iterations. A week is too small to break up, so you just go heads down. But you don’t work on the wrong thing for too long. You get two or three times the chances to learn and improve.

1 Comment

There is no essence of Agile

30/05/2014

real agile is: talk to the users directly, know their pain point, address it, repeat. -someone on Twitter who I disagree with

In many conversations about Agile, especially as of late, I read something like the above tweet. I don’t know where the idea that Agile can be distilled down into one or two practices or principles comes from. Thinking this way is extremely harmful. If you think like this, I’d love to hear your explanation.

Agile methodologies come out of Lean thinking which comes out of the Toyota Production System (TPS). The TPS is incredible. It mixes explicit practices such as 5S, ideals such as JIT, and principles such as “respect for people” into a unified, harmonious way. TPS is often represented using a house metaphor as in the following image:

house-of-lean1

The house is an apt metaphor because every single component is structurally vital. “Talking to users” and “addressing pain points” corresponds pretty closely to “customer satisfaction,” which is the roof of the TPS house. The roof is elevated by the walls, which are secured by the foundation. The roof is integral to the function of a house, but no more so than any other component. Customers can only help inform what you produce. If you are unable to produce those things at high quality, speed, and efficiency, and improve over time, then it doesn’t matter how much you talk to customers.

Adding an Andon cord to an assembly line does not make a manufacturer Lean. Being Lean requires a whole set of practices, ideals, and principles working in unison. It can be TPS, or your adaptation, but it requires incredible rigor, skill, and learning, and it’s not simple. Likewise, no single practice, from TDD to iterations to talking to users, creates a well-performing Agile organization.

There are plenty of pseudo-Lean companies, just like there are plenty of pseudo-Agile shops. On the plus side, the damage from Six Sigma Black Belts is far more severe than the Certified Scrum Master racket.

Companies that are Lean are rare, and have been at it for a while. It’s silly that every JIRA jockey thinks they have learned the essence of Agile. Being Agile is difficult, complicated, and takes a while. Let’s not try and distill it down so much that we totally dilute it.

5 Comments

Results are not the point, followup

19/05/2014

In response to a previous post explaining the phrase “Results are not the point“, commenter RenRen Gabás says:

Both approaches have their own place. It’s easy to see why Toyota/Lean works well with manufacturing and operations. Continuous service and operations needs continual improvements. However, there are times when you need to forget all about process and workflow in order to break new ground. I would place breakthroughs in research and product development right in the Danny category.

Unfortunately, history (and logic) shows that Jess (continuous improvement) is still going to out-innovate Danny (gets drunk and makes stuff) and come up with far more breakthroughs.

  • Exhibit A: The Prius (first successful hybrid car) and Lexus (Toyota’s first luxury line) demonstrate that continuous improvement is not limited to operations. These were successes of product development and marketing.
  • Exhibit B: Google, a company filled with innovation, research, products, and big ideas, is also a world leader in analytics and iteration! Who do you think their process most closely resembles?

Do not confuse the stifling bureaucracy of a large company to embody Jess, and the creative chaos of a startup to embody Danny. This is a fallacy. Large companies are more stifling, and startups are more creative. But this is due to intrinsic properties, not continuous improvement.

Another way of saying “results are not the point” is “do not trust your fortune to randomness.” I don’t know anyone who would disagree with that! Yet when we take the Danny approach, that is exactly what we are doing, no matter the nature of what we are working on.

1 Comment

Results are not the point?

15/04/2014

The phrase “results are not the point” often confuses people new to Lean thinking. It confused the shit out of me, not having really understood it even after my first few books. This is a shame, because it’s such a simple thing.

On Friday night, Danny got really drunk, coded a game, and the game was a hit. Danny did this again the following Friday, with the same results. And once more that third Friday.
Jess codes on sober Saturday nights instead (still drinks on Friday). Jess programs a game, and it runs poorly, crashes often, and isn’t fun. The following Saturday, Jess makes a new game, which runs fast but still isn’t fun and crashes often. That third Saturday, Jess creates a new well-performing, fun game, though it still crashes.
Would you bet on the long-term success of Danny or Jess?

Clearly, the better bet here is Jess. Jess has discovered a process which can be continuously improved. There is good reason to believe Jess will eventually create reliable success. The fact that Danny has been successful three times is basically irrelevant, since Danny’s process is totally haphazard.

This is the idea behind results are not the point. Focusing on the results, and not how those results were achieved, doesn’t improve anything in the long term. The point is to create a repeatable, empirical, continuously improving process. If we can create a reliable, successful process (which here includes culture and practices), we can get reliable, successful results.

9 Comments

The “Year of Code” Director is Your Boss

12/04/2014

There was some hubbub a few months ago when it was revealed the Executive Director of the UK’s Year of Code initiative can’t code [link]. Not that technical (domain) competency is a sufficient condition for management and leadership, but I’d certainly call it a necessary condition. (I’ll use the world ‘technical’ below to refer to any sort of specialized domain, not just programming.)

Apparently a number of people don’t agree with the idea that competency in a domain is a requirement to manage that domain.* I find this idea infuriating and it can only end poorly.

Perhaps you have a manager who knows little about programming or design or whatever your specialty is, and you consider this person to be the best boss of all time. Great! I’ll call this person Your Boss for convenience. Here’s the problem:

At some point, Your Boss needs to make some contentious decisions. Maybe over your work, maybe over something you’re not directly involved with (I bet Your Boss was hated by a lot of people, too!). Your Boss has literally no ability to help resolve a technical decision. “Wait!” I hear you say. “My Boss is enlightened enough to know that the people closer to the problem should be making the decision!

But who are those people closer to the problem? Who put them there? Oh, that’s right: Your Boss. But your boss has little technical knowledge. How is Your Boss supposed to decide who makes the more technical decisions? Without basic technical ability, Your Boss doesn’t even know what questions to ask. Your Boss can’t even learn; she doesn’t have the technical prerequisites. Instead of being able to provide leadership, Your Boss is left scratching her head. This is not leadership, and this is not management. This is a cancer and an organization that is unable to grow and learn.

It’s no surprise this topic is divisive. When Your Boss places a lot of trust in you, you are autonomous and think of Your Boss as the best boss of all time. But when someone runs up against you and Your Boss, they have no real recourse, because Your Boss trusts you and has no ability to further inspect the situation.

Certainly, superior ability or experience is not a requirement for management over a domain. But I thoroughly believe that not just familiarity, but some actual professional practice, with a domain is a requirement. I hope that if you are someone who believes in the myth of the competent non-technical manager, you’ll rethink your experience and view Your Boss in a more complete light.


* Clearly, at some point, you cannot be experienced in all the domains you manage, and need to trust people. Unfortunately we do this far to soon, and accept a development manager who has not developed, or an engineering manager who has not done much programming. In the case of the Year of Code Director, I think the issue is a non-technical background (in programming nor teaching) and a general lack of experience. If she had proven a wunderkind in her given field (which is, btw, basically PR/marketing/communications), maybe she should be given the benefit of the doubt. There are many examples where talented administrators have moved into new areas and been quite successful. But her appointment, along with most of the rest of the board, is pretty clear cronyism (and when you throw out technical merit and domain experience, you’re left pretty much with cronyism).

4 Comments

Why Agile became meaningless

6/04/2014

Uncle Bob recently wrote a post about The True Corruption of Agile. I think it will be a defining post for me because, as I’ll explain in my next post, I’m ready to give up on Agile. It has become meaningless due to the corruption Uncle Bob describes, and trying to reclaim Agile isn’t possible.

Imagine the Lean movement without Toyota. Toyota is the guiding force in Lean because it grew out the The Toyota Way.* When Lean goes awry, Toyota- the company and its principles, practices, and culture- is there to set things straight.

Toyota can guide Lean because the company has been successful for decades and Toyota attributes its success to the principles and practices known as The Toyota Way. But for many years, Toyota’s success was explained away by anything except the Toyota principles. Finally, all that was left was The Toyota Way. Toyota is the Lean reference implementation.

Agile has no such entity. Instead, we have hundreds of “Agile” shops who attribute success to some (non-)Agile practices. Then, once they’ve evangelized their (non-)Agile stories, reality catches up with them and the success disappears.** But no one hears anything about that failure. The corruption and perversion here is inevitable.

Without a company like Toyota giving birth to Agile and showing others how to do it right, Agile was destined to become what it is now: meaningless and corrupt.


*: The Toyota Way started out as the Toyota Production System. They aren’t technically the same but for the purposes of this post there’s no reason to distinguish.

**: For example, maybe InnoTech decides to use Scrum on a global scale to ship an ambitious product, and talks a lot about how they pulled this off and what benefits it yielded. Years later, velocity is in the toilet because the endless mountains of technical debt created, and maybe the company has had layoffs. The Scrum transformation will be in a book or on a stage. The layoffs or technical debt will not.

1 Comment

What does your Product Owner own?

3/04/2014

In a previous post, I came down hard on Agile leaders that don’t program. Now I’ll turn my sights to another part of the Scrum trinity: the Product Owner. I’ll raise some concerns for what I’ve seen it become in videogames, and suggestions for improving how we use the role.

Most product owners I’ve seen in the videogame industry are much closer to project managers than business owners. Their primary job is often the coordination, planning, and prioritization of the cross-team dependencies that the scaled-up nature of game development tends to create. I’ve seen designers and business/marketing in the PO role on occasion. It has sometimes gone very poorly.

I’ve always thought this situation strange, as the PO role most closely aligns with someone from the discipline of game design. We usually don’t have a problem with mapping a Creative Director or other core vision holder to the role of PO. After all, they are the product champion, and marry game design and business sense. A project manager clearly wouldn’t suffice here. But then other POs on the same project are all project managers. What gives?

There’s are some litmus tests for seeing how product ownership works in your organization.:

  • Do people “graduate” from Scrum Master to Product Owner?
  • Do the same people occupy both Scrum Master and Product Owner roles, concurrently or not?
  • Is your product owner leading and championing, or following orders (from above and from the team) and focused on execution (metrics, tracking)?

The skills between product owner and project manager are significantly different. There’s a problem if most people are seen as able to do both, and if POs aren’t coming primarily from design, business, and marketing.

There are lots of reasons things get this way. The important thing is to realize that the term PO isn’t a good fit for what most POs are doing. I see two options.

The first option is to commit to a Chief Product Owner/Area Product Owners structure (described in the footnotes*). Here, product ownership is seen as a distinct set of skills that bridge the business and design/creative side of development. If you have the right people (for example, POs for the overall/creative, technological, visual, and operational parts of the product), this can work quite well. I’d say this is a much better option, but frankly can be difficult or impossible to pull off if you do not have the right people or mindset.

The second option is to commit to having a single Product Owner, and having a project manager (Producer) on each team who is responsible for traditional project management duties and being a proxy for the real PO. They make few decisions of their own, but just act as dutiful middlemen. Usually the Producer will also take the role of Scrum Master, though I think this is a shame as their focus will be on traditional project management. This will make it difficult to make sure your teams are getting an ongoing Lean and Agile education.

Ultimately, the key is to acknowledge how product ownership in your organization works. If how people are fulfilling the role of PO does not seem to align with the literature, change something. You can choose option one, and change your organization to match the literature. Or you can choose option two, to abandon the literature, and find something that will work instead. In either case, do not continue the dissonance.

The core of Lean and Agile is continual improvement. If you are using confusing or inappropriate terms and organizational structures, you sow confusion. If you are confused and without direction, you cannot reliably improve.


*: Scaling Lean and Agile Development is the best book I’ve read about scaling Agile development methodologies. Regarding the role of the product owner, their recommendation is to have a single PO if possible, but to have a single Chief Product Owner and several Area Product Owners if one PO is impractical (which it often is in game development). Importantly, POs are tied to areas of the product, and not to teams (who can and should drift between areas of the product).

4 Comments