Scrum meeting snapshot.

I’m sure you know about apples and doctors and whatnot; I’ve also found that Scrums are just like that too.  It’s a foundational tool for any team that’s becoming “agile”, and a great starting point to work Scrum principles into an organization for a lot of reasons.

A Scrum is simple and wraps a lot of good ideas into itself.  The idea of a 15 minute meeting with a hyper-focused agenda with a few rules is something that can easily be applied in non-technology as well as technology groups.  To frame the benefits in a slightly different way:

• You’ll just get things done.
• Information is boiled down to the essentials.
• You can improve morale by empowering team members; they are free to self-organize for the rest of the day with minimal regimentation.

Here are some tips for organizations who want to start introducing Scrum into non-software-engineering teams:

• For project managers acting as Scrum Masters: Focus on impediment identification and resolution (action) as opposed to project plan maintenance (passive).
• For business analysts (or other team members in general) acting as Product Owners: Focus on getting everyone on the same page regardless of role and break out of the siloed information mentality as opposed to creating and maintaining over-wrought documentation.
• For the rest of the team members involved: Focus on progress, momentum, and constructive conflict as opposed to accounting for every minute of one’s time.

I realize that some people might argue:

• What about emergencies?  I would say that Scrum Master judgment can intervene to call off the Scrum as needed.
• What about getting to other topics?  That is not the point of the meeting!
• How do we make sure everyone has their say?  Team members (emphasis on team) will, as long as it’s brief and to the point.  Non-team members wait until the “parking lot” time that’s determined by the Scrum Master.

These (and their variations) are all excuses for ScrumBut, a horrible mutation that’s justified with weak rationales and a disdain for other folks’ time.  Respect the people you work with, and just don’t do it.

PS. Credit for the photo of the Scrum meeting goes to Jason Yip and his article here.

C. Minard's Depiction of Napoleon's Invasion of Moscow and Russia in 1812 and 1813

I recently finished reading Dan Roam’s “The Back of the Napkin,” which is a great introductory and reference book on communicating with pictures.  I also spotted Seth Godin’s blog post commenting on this NYTimes post and its validity.  And last but not least, one of my favorite examples of multiple dimensions of data plotted on a single illustration is explained by Edward Tufte.  I mention all of these examples because it’s easy to make a bad picture, but not too hard to make a really good one.

My career is filled with all sorts of illustrations to prove a point. Whether it was as pedestrian as a pie chart, or a project timeline, or a business roadmap, illustrations allow someone to demonstrate a few things:

• That you’ve researched the problem at hand, and know what you’re talking about.
• That you can show variations of the issue (by drawing on top of the picture).
• That your analysis is sound.

There’s an inherent danger to pictures though, which is that sometimes they lend too much credence (as Godin points out above) to a weak analysis.  Godin points out that

“reviews never reflect the product, they reflect the passion people have for the product. As Jeff Bezos has pointed out again and again, most great products get 5 star and 1 star reviews. That makes sense… why would you be passionate enough about something that’s sort of ‘meh’ to bother writing a three star review?”

The point for any viewer of the illustration is to be skeptical of the data that underpins the picture.  Note that the NYTimes post relies on shaky data, whereas the Minard illustration is based on mostly secondhand (but reliable) accounts.  Both require at least two passes across the pictures shown, and the biggest difference is that the NYTimes post discredits itself, whereas Minard’s builds on itself.

Conclusion: Check to see if your pretty picture relies on not-so-pretty data.  If it does, don’t be lazy; find better data (i.e. garbage in, garbage out).

Being the astute reader that you are, you’ve probably guessed it: Chrysler is the best example of survival through innovation. Dodge Caravan/Plymouth Voyager were practically invented by Chrysler and still has fair market share and gas mileage numbers compared to sedans and compact vehicles (not counting the green stuff). Chrysler pushed the Jeep marque to gain significant traction in the early 1990s, leading to a surge of consumer demand for vehicles that could go off-road, carry everything plus the kitchen sink, and still get you to your destination in comfort (thus the original luxury SUV, the Grand Cherokee Limited). And finally, the Dodge Viper is an iconic muscle car that injected some American pride (and brute force) into the high performance automotive arena.

Chrysler had many opportunities to succeed in the past based on its innovation, but its lack of business savvy and missteps in the marketplace in manufacturing, partnerships, and brand marketing have significantly hampered its competitiveness. I hope that the Fiat alliance actually yields the following instead of “leaner management and overhauled manufacturing”: truly equitable technology and supplier sharing, the development of a breakthrough hybrid or electric vehicle, and the employment of lean manufacturing techniques.

Conclusion: Innovation can keep a company on life support, but it won’t do it any good if it doesn’t know how to make and sell its products.

Sources (background and pictures) include Wikipedia (Chrysler, Minivan, Jeep Grand Cherokee, Dodge Viper) and the Wall Street Journal.

The sharp downturn, according to Mr. Hagel, will force companies to go beyond simple cost-cutting to take a hard look at the economics of their businesses. Most companies, he says, are actually bundles of three different businesses: infrastructure management, product and service development and commercialization, and customer relations.

I find this to be a wonderfully concise observation that has great implications. What happens to companies that transform into one of Hagel’s “bundles”? Do they lose something in the process? Or perhaps consider how a company starts off in one of those bundles. Do they end up growing some small competency out of sheer need? Are we at a point where the business process model can transcend the siloed nature of companies for a more seamless specialization model and have companies truly focus on what they do best? And if so, what happens to management layers in these companies (in other words, does specialization drive out the need for layers of management)?

Conclusion: It will be a brave new world, but I think there are two key problems that the “bundle” idea needs to overcome: trust and consequence. The majority of businesses in the US are small and things get done on an informal basis. With today’s legal infrastructure of contracts, privacy issues, and payment terms, it is hard to directly reward or control/influence the work of an outsourcer, particularly in smaller companies who rely on trust and consequence to get things done.