Book Review – Super Sad True Love Story

I aim to cover progressive approaches to business.  Reviews of fictional works don’t usually qualify.   However, a novel I just finished seems germane to my “future business” theme:  “Super Sad True Love Story” by Gary Shteyngart.

Shteyngart explores one possible future that may follow from some of our current trends.  He painfully describes in detail the distopian demise of the american society and economy.  It would not be quite so painful if it were not obvious that we have already started down many of the paths he treads.

In his future, people have become fanatically involved in their personal information devices;  to the point where face to face interaction has become somewhat awkward.  People relate to each other based on a series of public scores/rankings.  Starting to sound familiar?

In this fictional society the US is even more indebted to foreign powers who have grown impatient with our inability to handle our economic and social issues.  Everyone is so worried about their personal status and their purchasing power that they have lost all sight of what it takes to create real value and drive an economy.

Happily, I can envision some different paths for the US.  I am heartened by the new class of social entrepreneurs and the recent increased focus on education.  We have a growing set of people with good ideas and the gumption to execute.  If we can win the masses over from their sense of entitlement, innovation could usher in a new wave of prosperity.  The US has a rare combination of access to capital, resources, and tools for innovators to succeed.

My hope is that more and more people will weave innovation into their day job, ideas they have for a side business, or social projects they pursue.  Future business in this country can be even more successful than ever if the majority stop acting like cogs and begin working as engines.

Anyone else read this book? Even if you haven’t, what are your thoughts on where we are headed?


Microsoft Project doesn’t work

I have been using Microsoft Project for years.  There’s been a lot of love and a lot of hate.  Often at the same time.

In my opinion, it is still the best available software for setting up project tasks and project dependencies.

Unfortunately, that is where the party almost always ends.  The problem is that reality almost never follows the path we envision on Day 0.  The timeline is not the only element that changes.  What steps are required and the order of those steps ebb and flow as well throughout the project.

This is where the best part of MS Project also becomes its downfall: it is so good at identifying dependencies and assigning resources in order to build a nicely structured gantt chart, that the interdependencies are usually massive.  When elements start to shift, the number of data points and task relationships that must be maintained becomes unwieldy.

Most PM’s realize eventually that nobody else on the team is really paying much attention to the project plan and they are spending inordinate amounts of time trying to keep it current, so they give up.  In a horrible scenario, they try to deathmarch to the beat of the original plan.  In a better scenario, they find an alternate way to track progress and predict success.

I have found MS Project is a useful tool at the beginning of a project to identify critical path.  A critical path is the longest dependency chain.  It is a set of tasks that if one of them slips, it will slip your entire project.

Once I am ready to begin a project, I slim it down to a format that the whole team can relate to and that can be kept up to date more easily.  I also like frameworks such as IBM’s 7 keys approach which takes a much more holistic approach to project status tracking.

Anyone using MS Project all the way through a software development project?  Anyone using agile and MS Project together in some way?

Pre-mortem for risk mitigation

robert-mankoff-o-k-let-s-just-have-a-look-see-at-this-pre-mortem-new-yorker-cartoonIf you wait until a post-mortem to review what went wrong, you are already dead!  It’s not going to help.  😦

Guy Kawasaki mentioned another approach on his recent Entrepreneurial Thought Leaders podcast appearance.

Before your effort fails, get everyone to close their eyes and imagine it has failed.  Have each person describe the scenario that they believe could have led the team to that point.  Then all you have to do is capture all the described wrong turns as risks and decide which ones are important to mitigate.

Just like so many good ideas, this idea’s simplicity is its genius.  Participants will be emotionally involved and therefore will cut straight to the heart of the matter during an exercise that can otherwise be pretty dry.

Guy may have drawn the idea from this HBR article: Performing a Project Pre-Mortem.

Anyone ever tried it?  If not, give it a shot and let me know what you think.

Book Review – Nudge

This book covers an approach with which I agree : Paternalistic Libertarianism.  Two big words that mean everyone should have the right to make choices for themselves, but that the system should be set-up to subtly encourage choices that we, as the decision framers, believe are in the decision-makers’ best interest and the best interest of the larger population.

I think Libertarian ideals are great, but game theory tells us that when we are left to each fend for ourselves, we do not always end up with an optimal solution that creates the most total utility.  In situations where there is a history of people making choices that are sub-optimal, a paternalistic nudge can be for the individual and overall good.

However, problems start to arise when you think about who should be the framer of these paternalistic decision choices.  Do they have motives beyond the common good?  Do they measure common good in different ways than we do?  While nudging is certainly better than legislating against something (from a Libertarian point of view), it may not match with our own personal definition of “good”.

This book, like so many business books, would have been much better as a long magazine article.  It gets quite repetitive.  I feel that the authors could have traded out some of the endless examples for more space to help potential framers think through how to best approach setting up a nudge.

Though I skimmed it at parts, all in all, I thought it was an interesting read.  What I learned will hopefully inform my approach next time I am faced with framing a decision for others.

Please share if you have ever experienced or set-up a nudge and what you felt about the experience.

Product Development – Iterating by Color

Agile development has shown itself to be a superior approach over waterfall in many cases.   But, what I don’t see talked about much is the fact that each feature you pull off your backlog could be developed with a variety of complexities.  If the business owner tells me that she needs to get from point A to point B, I could build her a Yugo or I could build her a Rolls Royce.  I am sure she would prefer the Rolls Royce, but if you factor in the time to build it and the cost, she might prefer the Yugo or something in-between.

The first time you attempt something brand new, you can involve the stakeholders in the design/development, but you are never 100% sure how they are going to react once it is launched.  So, it is best to build that feature relatively simply and then improve over time.

We use colors to denote the amount of resources that we are willing to dedicate to designing and developing a feature, process, or application.

Yellow is the lowest level.  It represents our first attempt at something and it is usually a minimum viable product.  We just want to solve the pain point so we can learn from it.  Often it is very manually intensive to run a yellow feature because elements that could be improved via technology are not.

Green is the next level.  At this point we want to build something that will not tax the operational team.  A solution should be able to run at this color for a year or so without causing any major stress to the system.  We are able to take what we learned from the yellow version to inform how the green system is designed/built.  Occasionally we go straight to green, but only when we feel there are no workable yellow solutions.

Blue systems are designed to last for several years.  They should be scalable, easy to manage, well-architected, and most of all, they should only be built after one has learned from earlier implementations of the feature.  We sometimes go from yellow straight to blue, but we never build something at a blue level first.

This coloring approach is not nirvana.  There are challenges

  • How do you split your resources among the different colored projects?
  • How do you decide to prioritize a blue version of something existing against a new yellow feature that is desired by stakeholders?
  • How do you merge yellow, green, and blue staged elements into the same system (will they always plug and play)?

Anybody tried something similar?  What worked and didn’t work for you?

The Power of “done”

My agile scrumtastic friend Andrew Tsui invited me to join him for an evening meetup of Agile NYC led by the master of all scrum masters, Ken Schwaber. My primary takeaway from the session is the importance attached to the definition of “done”.

Too many software development teams move onto the next set of desired features before they have reached a full complete, tested, and shippable state on the current set of features. This creates an over-estimated sense of the velocity at which the development team is progressing. Unfortunately, it is not as simple as the team picking up where they left off and completing the unfinished pieces before a customer release. Leaving loose ends in each iteration (sprint) is actually a compounding problem.

A team that consistently falls short of “done” ends up with a required stabilization stage which lasts much longer than the sum of all the missing elements from each iteration. The problem is easily rectified by allowing the development team extra time per sprint (short-term) in order to dramatically reduce the stabilization stage and save time in the longer-term (release).

Another nice side effect of slower velocity and increased amount of “done” per iteration is that the code base staves off the complexity that naturally slows velocity over time. Thus velocity can be maintained at a higher rate over a longer period.

Book Review – Game Based Marketing

I have the pleasure of knowing Gabe Zickermann quite well as the leader of the NYC Fall program for the Founder Institute. I am developing a start-up right now through that incubator.  He treated us to his presentation on gamification a few weeks ago.  The idea of gamifying customer experiences is already intriguing to me, Gabe’s talk made it even more appealing.

Unfortunately, I have to say that the book version of his ideas does not hold a candle to his in-person presentation.  While I had hoped that it would provide lots more examples and even some tactical approaches to go about thinking how to gamify a specific business, it did not.  It remained a very high-level overview of the history and general concepts of gamification.  This book is a perfect example of an article being stretched too far.

I highly recommend that people think about booking Gabe as a speaker.  He is entertaining and this topic is pertinent to the Future of Business.  Gabe will help your group to think about engaging with customers in new ways.