process – Virag Consulting

Say It to My Face

Talking behind someone’s back can get you fired at Bridgewater. If you have a problem with someone, you must confront them and sort it out. The corporate culture is devoted to frank assessment of everyone’s strengths and weaknesses.

You can see why this might be important to functioning as a close-knit team, and to personal development. Bridgewater founder Ray Dalio is famous for what he calls Radical Transparency. There is even an app for that.

In most work places everyone is working two jobs. The first is whatever their actual job is; the second consists of managing others’ impressions of them, especially by hiding weaknesses

Some people think Dalio is a crank, but the movement seems to be gaining adherents. Shopify posts employees’ strengths and weaknesses on the company wiki. In this interview, founder Tobi Lütke sounds exactly like Dalio.

We are all … personal-growth junkies. So we really committed to giving each other feedback, and we’re trying to expand that to the entire company.

Personally, I like the direct approach. I have worked with people who prefer to sulk silently, plotting revenge or whatever, instead of laying their cards on the table. This is unhealthy, as well as unproductive. If you find yourself mentally rehearsing what you should have said, or what will happen “next time,” you need to get that off your chest, and damn the consequences.

If you tell someone, “you screwed this up because you failed to do X,” you begin a productive dialogue. Maybe he has never been trained in X. Maybe he chose Y instead, for a reason. Maybe Gartner Group just wrote a white paper on X, and it’s deprecated.

On the other hand, I can see radical transparency being limited to certain kinds of teams, like investment analysts and mountain climbers. It requires people who are already high performers, committed to raising the bar, and mature enough both to give and to receive criticism properly.

Most people have a hard time confronting their weaknesses in a really straightforward, evidence-based way. They also have problems speaking frankly to others.

This is where Dalio’s idea diverges from Radical Honesty, the self-help program of author and psychologist Brad Blanton. Blanton advocates brutal honesty from everyone at all times, which strikes me as impractical, even comedic (like the movie The Invention of Lying). A more practical book for business people is Crucial Conversations.

The other thing that struck me about the Lütke interview was his remark that companies are evolving, still finding the right way to organize. This I can believe from my long experience working with startups, and reading Tom Peters. Companies certainly need less hierarchy and more authentic teamwork. We will have to start being honest with each other.

Maturity Model for Software Startups

Software companies begin life at CMM Level One, and some of them die there. You may not be familiar with the Capability Maturity Model, but you will never forget your time at Level One. This is where the developers code all night because you need that next feature, to pay the rent. This is where you release new code and then spend all day patching it, in production.

“How many users do you suppose we’ll drop, if we reboot it right now?”

On the other hand, it is possible to have too much process control. I was at a Level Four company once where we had to three-bid a project to plan and initiate a second project that would develop the software. The chart above, from Ron Patton’s book, shows the levels as stair steps.

The model contemplates an otherwise stable company that has weak processes only for software. In a startup, all processes are weak and resources are limited. To be successful, processes must mature in step with revenue. In this article, I’ll illustrate holistic process maturity with some examples.

At Level One, you have limited HR capability, and therefore no diversity training or compliance. You have no benefits, no vacation policy, no travel policy, and no expense audits. Your exposure to liability is huge, for everything from “constructive termination” to respondeat superior.

“The reason for Brad’s separation from the company is a private matter which I am not at liberty to discuss.”

I looked into this, and found that there is indeed a maturity model for HR. The first step, in my experience, is to crib an employee manual and make everyone sign that they have read it. At least then you can disclaim any actions that go against the boilerplate in the manual. You might also invest in an employment law poster.

At Level One, you also have no marketing function. The sales people roll their own presentation materials, talk tracks, and brand message. The first step is to hire a dedicated “marketing person,” to do sales support and organize your booth at NADA. Actual marketing comes later.

Entrepreneurs are good at tracking their sales and market share. People I work with look forward to their first thousand dealers, a public dealer group, or a big agency. Celebrate each milestone by notching up your process maturity.

I would say that you should be out of Level One (for software) after eighteen months. If you are already taking distributions, while the business depends on “heroes and luck,” then you are gambling. Raise some capital, hire a good manager, and get it fixed. My earlier article, Sales-Driven Development, describes what I feel is a reasonable level of process maturity for a young software company.

Baby Steps

I will close this post with a few pointers for leaving Level One. Basic stuff. Most readers should be able to skip this list.

Create a maintenance window and stick to it. Only move code to production at 6:00 AM on Wednesday. If anything goes wrong, people are in the office. It’s also not Saturday, our peak volume day. If you are constantly having “emergencies” that can’t wait until Wednesday, you need to look at that.
Implement a code control system with a rollback capability. If the latest build has a problem, at 6:10 AM on Wednesday, you do not start debugging. You push the rollback button.
Set up a reliable QA environment, and sync it with the production database. I don’t know how many times I have heard that the build worked in QA but some new data was encountered in production, and it crashed the site.
Create a division of labor, such that the developers stop fussing with the servers. Developers love to fuss with infrastructure, which is not their skill set. At all. Hire a professional, or rent one from your cloud service provider.
Implement a work order tracking system. Planning at Level One is a “pushdown stack,” which means that yesterday’s panic is still simmering when it is superseded by today’s panic. Start by writing commitment dates on a bulletin board, so that everyone has visibility into the backlog.

Sales-Driven Development

I invented agile development. No, that’s not as cocky as it sounds. Every development manager I know has been trying to reduce cycle times, forever. At BMW, we did quarterly releases of call center software, and that was on client-server technology. As a profession, we have always been as agile as possible given the tools of the day.

What we call “agile development” is the ability to release software early and refactor it later. People generally overlook the high cost of refactoring, but I’ll save the critique for a later post. You can read The End of Agile, over at Effective Software Design. What I would like to present here is a practical approach that served us well at MenuVantage, and which is still relevant today.

We were operating in a highly competitive, fast moving market. Our sales people would come in and say they had just lost a sale because Brand X had some feature we didn’t. Better yet, they would have closed the sale on the promise that we would have it in next release. The developers complained about “sales driven development,” which, today, sounds like it could be a book title.

Our cycle ran from development on the local laptops, through automated daily builds, to the hosted production servers – every six weeks. I know that the scrum literature talks about producing “shippable” code every two weeks, but few shops actually move to production that frequently unless they are in a consumer market, running AB tests. I assume that most of my readers are developing business software for dealers and finance sources.

One innovation in our process was a second QA environment, on the company extranet, where product owners could preview the work in progress. Business requirements were thin, as I’ll explain later, and the extra environment gave us some ability to iterate within the six week cycle. I dubbed it “rolling QA,” in the process document.

When we deemed that it had rolled enough, we froze this code and moved it to production. Meanwhile, “nightly QA” would already be in use for the next release (see diagram). We also maintained a second copy of production, called “post-prod,” that we could use just in case we should ever need to diagnose and fix a critical problem in production.As each release went live, the product owners would meet to negotiate the content of the next release. This expression, “product owner,” is another thing that bugs me about scrum. In this case, though, the meeting included the legal owners of the company. We might differ over development priorities, but we had absolutely congruent goals for the company.

In preparation for the meeting, we would have pulled together a short list of the highest priority change requests, and estimated them – in hours. We did not use “complexity points,” because sales and finance people are much happier thinking in hours. For one thing, it facilitates a discussion about how many developers there are and how many hours they work. If you are uncomfortable having this discussion, trust me – using an arcane metric instead of hours will not make it easier.

Within the development team, we did use complexity to derive each estimate, by counting how many modules, pages, queries, etc., had to be changed. Contract developers have bid projects this way forever. I am thinking, in particular, of a spreadsheet used by Ernst & Young’s Advanced Development Center. Over time, the conversion factors are updated, so “institutional learning” about the estimates is captured.

We used conventional bug tracking software to manage the backlog. They get better every year. I will note that the last scrum system I used, JIRA, is a repurposed bug tracker. This is part of the reason why I find agile is better for enhancing an existing product than it is for the initial release – but that’s the other post.

My job was to collect high level requirements, write specs, and groom the backlog. Requirements were at the level of, “we need rollbacks so that we can do Sign & Drive.” This is actually not a bad formulation for a scrum story card. Readers will recognize the complexity concealed within this simple request – the UI changes and the math, lots of math.

The goal of the planning meeting was to distill the “short list” into an even shorter list of requests we could accommodate in the release. Don’t be surprised if your short list becomes a LIFO stack. That’s human nature. If something was hot two cycles ago, and it was never scheduled, then it probably isn’t hot anymore.

Development would start the meeting by presenting the short list and announcing how many hours we had available. Initially, we might have been paring a 3,000 hour short list down to 1,500 for the release. After a few cycles, though, everyone was able to predict what the final slate would be. The meetings became shorter and less contentious.

This is where we really enjoyed the advertised benefit of agile – and what motivates me to endorse this approach. The group learned that if we didn’t get all our requests into this release, we could rely on the next one, and the sales team developed a feel for how much they could promise.

Business Process Modeling

I am doing a Business Process Reengineering (BPR) project for LoJack Corporation. It is to their credit that a mature organization like LoJack is willing to examine its business processes. This is part of a broader effort to increase F&I penetration, and it promises to be a lot of fun. Readers of this blog know how much I enjoy BPR, and Dr. Hammer.

After much deliberation, we chose Business Process Modeling Notation (BPMN) for the project. My main concern was having diagrams that would be easily understood by everyone on the team. Not everyone who is an expert in F&I is also an expert in BPR. I also wanted notation that would keep track of data flows, and was well supported by textbooks and software tools.

If we had only IT people on the project, I might have recommended UML or ODBA, but both of these are too technical. Also, UML doesn’t do a great job of combining process and data flows. I think the absolute best notation on this point is Event Process Chain (EPC) but it, too, requires special training. There is a great paper out of Harburg Tech, by the way, comparing UML and EPC. The windup is that UML is better for software and EPC is better for process.

As to support, BPMN is an Object Management Group (OMG) standard. Visio 2010 not only supports BPMN, but it includes a syntax checker. This will be important for people new to the tool and the notation. I also found a number of good recent textbooks, including The Micro Guide to Process Modeling. This is a concise “how to” that will serve us well, and it includes some good style tips. Happy modeling!