Robert Bogue
November 23, 2015
No Comments
Learning how to grow a company is a difficult challenge. There’s never enough time and always too many problems. There’s always the gap between what you want to do and what you actually do accomplish. However, despite this some leaders manage to create noteworthy organizations and some of those write books – Joy, Inc. is the story about Menlo Innovations, a software development consultancy located in Ann Arbor, MI. It’s an interesting contrast to Pixar which was covered in Creativity, Inc.
The Source of Success
When you’ve been successful – or moderately successful – it’s natural that you’ll want to determine what the factors are that made you successful. Admitting that it was dumb luck that allowed you to create an organization that others envy doesn’t do much for one’s ego so most successful business people build a mental model for how they became successful. Most successful business leaders will share with you how they believe they were successful – whether that is really what made them successful or if it was another hidden factor, well you’ll never know. They will, however, develop some sort of a theory.
Richard Sheridan is no exception. He believes firmly in seemingly every component of his environment and how it’s allowed to him (and his partner James) to create a company that is the envy of many. There is no doubt that they’ve done many things right. However, do I believe that everything that they’re doing is right? In a word, no. In fact, some of the practices that are called out are directly opposite of well-established research on how software can be developed best. However, many of the principles are sound. So from my perspective we’ve got a situation where 70-80% of what he says matters, 10-20% doesn’t matter, and perhaps 10% of what Joy, Inc. says is essential is probably ultimately probably harmful.
Accessing Agile
I’ve been a fan of agile principles for many years. (Take a look at just a few of my book reviews on agile software development: Agile Software Development, Agile Software Development with Scrum, Agile & Iterative Development: A Managers’ Guide, and The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP). Unfortunately, I’ve run into more than a few customers who espouse that they’re doing agile when they’re really doing whatever they can to duck real responsibility under the guides of agile being all about no documentation and “sprints.” Too many clients I’ve walked into had done several sprints and hadn’t turned over the first thing for the customer to react to. Many of the clients I run into deliver no documentation instead of documentation without ceremony. They run “stand up” meetings where everyone sits so they can settle into a long winter’s nap as someone blathers on incessantly about some problem they want the group to solve – in the meeting.
The problem with this is that stand up meetings are supposed to be quick. They’re supposed to ask three things:
- What did you do?
- What will you do?
- What’s in your way?
These simple questions are powerful. They create a commitment, follow up on the commitment that was made, and puts leaders into the position of being servant leaders (See Heroic Leadership) to help the developers resolve the problems that they have. While stand up meetings are three simple questions running them takes discipline.
So while I fundamentally agree with and support the concepts of agile, my feelings about test driven design and pair programming are more dubious.
Test Driven Design
One of the challenges I sometimes have with developers is that they don’t really know what they’re trying to do before they start. They just start coding not really understanding where they’re going. Covey said “Begin with the end in mind.” In other words, you have to know where you’re going before you can attempt to get there. As a result, the core tenants of test driven design are solid. By specifying the behavior of the tests you’re signing up for the contract that you’re going to follow. You know what you’re delivering because you’re already building tests for it. So conceptually, it’s a great idea. The problem is that practice gets in the way at times. So while I’m in favor of test driven design and the resulting unit tests – I’m not willing to make it an absolute requirement.
The first problem with writing unit tests for test driven design is the number of tests that you’re going to write. Technically to get full coverage of testing you’ve got to test for positive and negative conditions and two tests for every ‘if’ statement in the code. In short getting full test coverage requires a lot of tests and many of those tests aren’t going to be indicative of real world problems or conditions. So it’s too easy to get “test happy” and to start writing tests so that you can say your code passed more tests.
The second problem is that sometimes to test code you need to get a fair number of objects created to test the interactions. When the objects that you rely on are expensive to create (in terms of time or resources) or they are environmentally sensitive, you’re left with the challenge of how you can mock up the underlying objects that you need so that the tests can run quickly. The problem is that at this point we’re writing much more code and we’re writing mock objects that are supposed to emulate their heavyweight counterparts – but that rarely works exactly like it’s supposed to. So as soon as you plug in external objects you’re dramatically increasing the effort and simultaneously decreasing the probability that you’ll find a real problem.
The final problem with test driven development is that it doesn’t work for multi-threaded or event driven programming. Here the timing of events is critical and the testing harness will interfere with the timing.
Again, I’m for test driven design and unit testing – where it makes sense. The perspective described in Joy, Inc. is that this is an immutable part of their culture – which I believe is too much. However, that’s nothing like the concerns that I have with pair programming.
Pair Programing
Pair programming is an idea where two developers work on one computer on one section of code. There are variants to this approach including the use of multiple mice and keyboards but the fundamental is that there are two developers who are working on the same code. In general the research on pair programming says that it takes more man-hours to write code this way – though not as much as one might expect (roughly 15%). The advantage of pair programming is supposed to be early defect identification and removal. It turns out that this number too seems to settle in around (15%). However, the proponents offer that these 15% more defects are much more valuable from a cost perspective because finding defects early compared to later makes them much less expensive to fix. This is well established in the research.
However, even pair programming proponents are aware that there are many different situations that make pair programming difficult. The power dynamics between the pair can often cause one of the members (the observer) to disengage and effectively become a wasted resource. Finding teams that work well together and creating a culture where pair programming is only surpassed by the need to have projects that scale to having two or more developers assigned to it. It’s too my discouragement that many of the projects that I see require only a handful of hours and often are assigned only one full-time (and sometimes only part-time) resource. As a result there’s a minimum floor for where pair programing works. If you’re in an organization and you’re looking to hire one developer to do work – well, pair programming just doesn’t work.
However, my real concern with pair programming comes from the awareness of flow (See Finding Flow, Flow, The Rise of Superman, and The Art of Learning). Getting into flow can take a while (See Peopleware for instance on how long it takes for a developer to recover after an interruption.) As an aside the environment for Menlo Innovations is open-air where everyone is expected to be constantly monitoring for a call from someone else in the room or the CEO asking for an impromptu communication. I know this is not advantageous to creating flow.
It’s my perspective that it would be better to have frequent code reviews in pairs than it would to work together. I believe that done correctly the reviews will take less time than pair programming and the process of explaining the code to someone will activate different parts of the brain of the coder thereby creating additional opportunities for discovery and learning.
Ultimately, pair programming is great at creating learning in developers. As developers work with each other they learn the best tricks of the other developer and they’re allowed to diffuse in the developer pool. (See Diffusion of Innovations for more about the spread of innovations.) As a learning tool, pair programming is incredibly valuable – but I don’t know that it’s warranted in every situation.
Legacy of Learning
So while I’ve got some criticisms of individual components of the organization there are some really important concepts – like the learning created by pair programming that I love. Richard explains that developers need to continually learn. They must be lifelong learners. I heartily support this. I’m also discouraged by Steve McConnell’s comments that most developers have never read a book on development. The creation of opportunities to learn both through pair programming and through creating channels of honest feedback are – I believe –one of the keys to the organization’s success. Arie de Guis – the former head of strategy at Shell – said that the differentiating factor for longevity in an organization is its ability to learn. Institutionalizing the desire to learn is a critical factor for success.
Relentless Honesty
If you’re hiding things or you’re refusing to share what’s real and true, you’re denying reality and you’re depriving yourself of the ability to learn from it. Unfortunately our natural tendency is to protect ourselves, to withhold any information that doesn’t support the idea that we’re amazing or flawless. There are such powerful forces at play to prevent us from being ruthlessly honest that it’s no wonder that it’s difficult to create a culture where honesty is not just valued by practiced.
Accountability is a special tool for creating honesty. Accountability makes it clear that the lies – even if they’re through omission or seen as harmless – will eventually come into the light. The only way that secrets retain their power is through the belief that they won’t be found out. Twelve step programs often say that you’re only as sick as your secrets and by making it difficult to hide secrets you remove their power to hold you back. In an organization creating clear rules for what is and isn’t acceptable is important. Following those rules up with accountability is essential.
Accountability has to apply to everyone – all the way up to the CEO. When the CEO doesn’t believe that he or she is above the rules then it’s easier for everyone to believe that the rules apply to them. If they don’t apply to the CEO does that mean they don’t apply to the entire C suite? What about directors? Making it clear that the rules apply to everyone sends a powerful statement.
In Change or Die the stories of Delaney Street and how even the leaders would be held accountable to the rules sends a powerful message that resonates with all of the people.
Systems That Support
There are so many things that the traditional organization espouses but doesn’t live up to that it’s hard to tell what organizations really believe. If your organization does employee satisfaction surveys, what actually happens with the results? Do they get communicated out in an all-company meeting and then grand plans for how to improve the scores are summarily forgotten until next year when the survey comes out again identifying the same things that need resolved? In many organizations, if not in your organization, this is the case. The organization says that they care about how employees feel about the organization but their commitment to take action on the results says something else – something very different.
One of the revealing things about Joy, Inc. was exposure to the systems that keep things on track. Whether it’s the system for adding work to a project or sprint or it’s the estimating process which uses simple folded sets of paper, the transparency of the internal processes and the recognition that these systems are specifically designed to ensure that the values of the organization are adhered to are another pillar, I believe, to Menlo’s success.
Enthusiastic Estimates
Another simple but effective technique being employed is that estimates are done by the people who are going to have to do the work. This is critical because it eliminates the distortion that happens as project managers and clients distort reality in the direction that they want. If the feature requires 40 hours to do but they only have 32 hours left in the sprint planning, it’s tempting to reduce the effort to 32 hours to make everything balance out – however, doing this perpetuates a lie. We know that our best information about the time it will take is 40 hours but we’re willing to practice “wishful thinking” and say it may only take 32 hours. That sends the wrong message to everyone in the value chain. The developer feels undervalued. The project manager and the client feels like they can squeeze one more thing in.
What you can be enthusiastic about when estimating is that your estimates won’t be tampered with. You won’t be lambasted because the answers aren’t what someone else wanted to hear. Instead you can be rewarded for communicating honestly what you believe.
Requirements Gathering Through Anthropologists
I published my first course on Pluralsight in September of 2014. The course was Good Requirements Gathering for Developers. I created the course because one of the challenges I found was that more frequently than not getting good requirements – whether you’re running a more traditional non-iterative waterfall project or an agile project is difficult work. Most of the people that I see generating requirements don’t have the skills to create requirements. Often times the project manager is assigned to capture the requirements so they can be put into the project planning documents. At Menlo, however, there’s an awareness that it takes a different skill set than that of a typical project manager or a developer. The ability to quickly sketch ideas, to listen, and to observe are not natural skills for most project managers or developers. While they’re teachable skills, they’re not automatic. As a result of the general lack of skills in this area too many projects proceed with an unclear understanding of what needs to happen.
Hidden in the Menlo description of High Tech Anthropologists is a recognition that the objective isn’t really to capture requirements, the true objective is understanding the users to a level that allows you to delight them with the solutions that you’re able to co-create with them. Anthropology is the study of humanity. When we’re trying to solve problems for customers (internal or external) we’re trying to connect with their human needs and deliver solutions that address the wants and needs that they may not be able to fully articulate.
Make Mistakes
They’re inevitable. The sooner that you realize that mistakes cannot be avoided the sooner that you can move the perspective of creating learning from them and building the ability to recover from them. (See Creativity for more on making mistakes.) We want to avoid the embarrassment of a mistake but since none of us have holes in our hand from being nailed on a cross I’m relatively certain that none of us are perfect. That being said no matter how hard we try to avoid mistakes, they’re going to happen.
The beauty of making mistakes – if you’re willing to put on the optimist hat for a moment – is that in mistakes is the potential to learn something new. We can learn what we did wrong or how the circumstances didn’t align with our response. Mistakes are – or at least can be – a good thing.
Systems for People
In the end I may disagree with some of the assertions about the specifics that lead to an organization that’s a joy to work for – particularly as it pertains to the specifics of how to do software development. However, I do believe that the fundamental systems approach to people problems leads to better outcomes. From my perspective the true genius of Menlo has nothing to do with how they develop software. To me the key value is in how they design systems that reinforce their core values and support employees.
The idea that it’s possible to bring children to work absolutely demonstrates the message that families are important. Pair programming, while not necessarily practical or efficient in all ways, reinforces the core message that everyone should be learning all the time. There are dozens of examples from the book where the leadership at Menlo have developed an awareness of how people based systems interact and how to change those systems to get the desired outcomes. (See Thinking in Systems for more on systems thinking.)
Whether you agree with the specific claims that are made about software development, Joy, Inc. can help you think about how you can create an organization that you want to work for – and others do too.
