Slicing Pie (Review)

I had the opportunity to review a copy of Mike Moyer's Slicing Pie: Funding Your Company Without Funds. Having worked at a number of startups at various stages,  I  was interesting in the insights this book gave into evaluating the value of and managing equity shares in an early company, before a company is making money, and before you have investors.

This seems like a book anyone involved in startups should read. Entrepreneurs can benefit from a reminder about the value of trust and fairness in dealing with those who join the company to help realize their vision. Those who join startups (even in later stages) can gain insight into the issues involved in bootstrapping a company. Anyone who works in small teams can gain insight into the psychology of motivation and compensation in team working to realize vision. This is a quick read, and the author uses frank, conversational language to explain the importance of fairness in dividing equity among founders.

The underlying concept is that, as an entrepreneur, you need to treat the people who join up early on to help you realize your vision fairly. This will sound obvious, but it's not a universal pattern. Part of the reason could be is that it's hard to know what "fair" is in the context of the uncertainty of a bootstrapping company. Value is uncertain and  people's commitment and enthusiasm can change over time. This book describes through how to define value and equity in a way that all the stakeholders can understand.

This book isn't just about philosophy, but presents a well defined process for managing equity in an early stage, unfunded company.  With case studies, examples, and online resources, this is a great book for someone looking to start a business, or someone thinking about getting involved in an early stage startup. For a short book it is very complete, covering not only the basic "equity" approach, but how the approach helps you to manage situations such as people joining and leaving the venture while still helping everyone to feel fairly treated.  This book is worth the time and the cover price for the information it contains. The book could benefit from some tighter editing, though overall the writing is concise and it's not hard to get past the few sections that are problematic. If you register the book on the author's web site you can get updates for free, so it's likely that my minor concerns about editing will be addressed promptly.

Overall this is a good book that provides actionable advice, for anyone looking to start a business, or join an early stage business.

Groovy Dependencies, Grape, and Firewalls

Groovy is a powerful and fun language. One of the nice features, particularly useful for internal tools,  is the ability to deliver scripts that are self contained with the only pre-requisite being that you have groovy installed. One of the tools that enables this is the Grape dependency management mechanism. Using Grape, rather than delivering a zip file with all dependencies, or requiring that modules be installed as part of the global system installation, you can add a line like this to your script:

@Grab(group='org.springframework', module='spring', version='2.5.6')

This will grap the dependency into a local repository if it is not present already. It makes the startup time for the first run of a script a bit slower, but it also greatly simplifies the delivery of short, script-based tools.

If you are in production environment behind a firewall, you might find that that this mechanism doesn't work because you can't access the public repositories. You can address this by adding an annotation to the file to add your repository to the list

@GrabResolver(name='restlet', root='http://maven.mycompany.com/proxy')

When I first tried this, it seemed to take a very long time for the script to run, with no output.

To diagnose the problem, I needed to have the GrabResolver tell me what it was doing. Looking at the code the way to do this was to set the ivy.message.logger.level system property.

My command line to get detailed output was:

groovy -Divy.message.logger.level=4 Script.groovy

This gave me enough output to see that Grape was looking in the local repository last after timing out when trying the standard repositories. The easiest fix I found for this was create a $HOME/.groovy/GrapeConfig.xml file as described in the Grape documentation. The new local config only has one ibiblio repository element, which is the company repository manager.

<ivysettings>
  <settings defaultresolver="downloadGrapes">
  <resolvers>
    <chain name="downloadGrapes">
      <filesystem name="cachedGrapes">
        <ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml">
        <artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]">
      </artifact></ivy></filesystem>
      &lt;ibiblio m2compatible="true" name="proxy-repository" root="http://maven.mycompany.com/proxy/">
    </ibiblio></chain>
  </resolvers>
</settings>
</ivysettings>

This sped things up significantly.

There may be another way to address the problem, and I welcome feedback. But since this wasn't obvious from the documentation, I thought it might be worth sharing.

Note, this is based on Groovy 2.0.2.

Automation

I recently wrote a short article on on StickyMinds.com about automation. After it was published I came across another related post by Jim Coplien which makes the point that automation should come after you have figured out your process.

I'm not sure that Jim and I disagree in principle on anything related to when to automate, but I wanted to make one point. I think it's important to start out an process that is likely to be automated with the idea of automation in mind. If you don't, you are likely to make decisions that are both not important to getting your work done and which would make automation harder to implement.  As I've said before in the context of deployment, the sooner you consider your constraints the easier it will be to build a system that addresses your real problems.

The hard thing is identifying which "requirements" are there out of expediency (or perhaps laziness) and which are there out of need. Having an iterative approach to any kind of automation can help you with this.  Do a process, write a script to do it, then once the script works well, figure out how to get the script to work more "automatically."

Your process model should come first, before you consider tools, or even automation.  But you can benefit by building automation into the process early, and iteratively improving it.

Problem Solving: Deadlines and Context

One of the more difficult challenges people and teams have in the face of deadline pressure is taking time to consider how to approach a problem rather than just diving in with a solution approach that you know will work.

In college, when I was taking a devices and circuits class,  I found myself stuck on a problem on the first problem set of the semester.  I asked an upperclassman for help and we determined that the problem could be solved by setting up a system of something like 12 equations, and grinding through the process of solving it. His solution was correct of course, but I wondered if this approach might be more complex than it needed to be given that it was  for one of a number of problems in the first problem set of the course, and given that the theme of the first few classes was more conceptual than about doing calculations .

When I later saw the solution to the problem it turned out that by making some simplifying assumptions, the 12 equations reduced to 2, and the solution was quite simple and quick. The lesson that the problem was mean to teach was not how to solve linear equations, but about how to understand when how to use a simple model to understand a complex circuit. The direct, labor intensive approach ignored what the problem was meant to teach.

I don't recall much about the specifics of the problem, but one thing I learned from that experience is that while working harder will often (though not always!) give you a correct solution,  it's always good to think about more than one approach before diving in and solving a problem. 


Sometimes just working harder is the right thing to do. But if you need to get past a deadline, before diving in to solving a problem it's good to think about whether you're doing more work than the situation merits, and that, perhaps, you are overlooking a simpler, quicker,  solution. 

Patterns and The Storytelling Animal

I had the good fortune to be involved in the early days of the Software Patterns.  In brief, patterns are about capturing solutions that people have developed organically over time, which have proven to be the best ones for the context at hand. What's interesting about patterns to those who are used to more academic approaches to learning about software,  is that a good pattern isn't novel. If you've been working in a domain for a time you are likely  to recognize solutions you have used before. If you've struggled with the problem in the past, you are likely to appreciate that the "common solution" is now documented.

By writing patterns, and hanging around people who studied and and worked with patterns, I learned to appreciate that the value of context: it's not enough to have a toolbox of solutions; you need to understand which solution makes sense given the specifics of your problem. In that way, Patterns fit into a set that includes agile engineering practices and software configuration management: Things that help you to focus your energy on the solving the hard problems that apply to your specific situation.

A good pattern is something that other's have used successfully. When trying to understand whether something is a pattern or just a "cool idea" you often find your self trading stories with others who have worked in a similar domain. My work with "Patterns People" also helped me appreciate the value of story in sharing knowledge. The books that inspired the first writers of software patterns, The The Timeless Way of Building , and A Pattern Language: Towns, Buildings, Construction (Cess Center for Environmental), are about building and architecture, fields in which there is a long history and much tradition. Traditional approaches to building evolved organically over time, and the ones that worked were shared and persisted. To understand the difference between a solution that works and one that is adequate you need to know more that just what to do. You need to understand the story behind the solution, and the story behind your current situation.

The value of story in learning and transferring knowledge seem to make sense on the surface. But it also seems to contrast with the way that we sometimes apply business and engineering processes. We want highlights, key points, and simple rules. But we often don't have the patience for the story that describes why (and when) these rules apply. And applying rules without context can sometimes be uncomfortable.  I recently read a review copy of The Storytelling Animal: How Stories Make Us Human, and this book shed some light on why stories work well for learning, and why avoiding story can make us uncomfortable.

The Storytelling Animal a well written, compelling book that explores the science, history, and future of stories and storytelling. Among other things, the book covers why children and adults create and consume fiction, the science of dreams, the role of stories in influencing (and defining) history, and what technology means for the future of stories. Not just full of interesting facts, many chapters start out in the manner of a compelling story, drawing you into learning about the science and history of story telling, proving the point stories are a great way to learn.

In our quest for answers,  it is important to not ignore that there is a always a context to a problem. What worked in one situation might not be generally applicable, and a framework or tool that solves one (important) problem well, but not your problem is not de-facto a bad tool or a bad solution. Just not the right one for you. While it's good to be skeptical when presented with a solution (especially if someone claims it to be a pattern), it's also good to not be dismissive of attempts to capture solutions in context.  Solving technical problems well isn't just a matter of applying technology. You also need understanding and a knowledge of what others have done in similar situations. Your situation may well be unique. But it is also likely to be similar to ones others have encountered.

Have the Orders Changed?

One of the great things about being a parent is that you have an excuse to re-read some classic books. My five year old and I have been reading The Little Prince, and the story of the Lamp Lighter reminded me of a common problem teams have with organizational inertia when trying to transition to agile software development.

For those who haven't read the story, or who don't recall the details, the Little Prince relates the story of his journey to various planets. One one planet he encounters a Lamp Lighter who lights and extinguishes a lamp every minute, not having any time to rest. When the Little Prince asks how this absurd situation came to be, the Lamp Lighter discussed this with the Little Prince:

"Orders are orders..." "It's a terrible job I have. It used to be reasonable enough. I put the lamp out mornings, and lit it after dark. I had the rest of the day for my own affairs and the rest of the night for sleeping." 

"And since then orders have changed?" 

"Orders haven't changed," the Lamp Lighter said. "That's just the trouble! Year by tear the planet is turning faster and faster, and the orders haven't changed!"

This is a very apt metaphor for many teams which are trying to adopt agile without re-examining their entire application lifecycle. The team may be developing using good technical practices, but the requirements management process is too heavy weight to keep the backlog populated, or the release management policies discourage frequent deployments, leading to code line policies that place a drag on the team. In addition to organizational resistance to change, some team members might also be using using development tools and practices that make it hard for other agile practice to work as well as they could.

It's important to remember three things when you are trying to be more agile:

• Agile is a system wide change. Changing practices in one part of the development lifecycle will quickly reveal roadblock in other parts.
• It's important to periodically examine how well your team is doing. Iteration retrospectives are a an important part of improving how you work.
• When reviewing how you work,  the practices that are now problematic are not often not "bad" per-se, they just don't apply  to your current situation.

Jerry Weinberg makes a great point about old rules in his Quality Software Management: First-Order Measurement where he says:

Survival rules are not stupid; they are simply over generalizations of rules we once needed for survival. We don't want to simply throw them away. Survival rules can be transformed into less powerful forms, so that we can still use their wisdom without becoming incongruent. 

"Survival" sounds a bit strong until you consider that the motivation behind working a certain way is often a desire not to fail, and sometimes, "failing" is scarier when you fail when not following established practices. That's why applying techniques such as those in Agile Retrospectives: Making Good Teams Great can make it easier for teams to consider how they can improve.

Standards and conventions ("orders") can be helpful to working effectively, but it's important to review those orders from time to time to see if they still apply.

Paper v Electronic Dashboards: Goals and Values

It's almost a matter of dogma that, for agile teams, low tech project tracking tools and artifacts are superior to electronic ones. The usual reason you might hear for preferring a physical task board to an electronic issue system are are that a physical task board is more visible and encourages communication and collaboration. I appreciate this, and have seen it, but I've also seen teams do well with issue tracking systems. From time to time I see a discussion of this "physical v electronic  tracking" issue and I find myself frustrated by it, but not sure why.

Reading Scott Kirshner's article Incubating ideas from the rank-and-file in the March 4, 2012 Boston Globe led me to think more about this. The article is about the value of listening to people in your organization when seeking ways to work better. This in itself seems aligned with agile values. In particular, this quote caught my eye:

Many of the ideas presented were dazzling. And almost every one sprang from frustrating experiences. Why, in the 21st century, was the hospital still manually updating whiteboards with information about patients’ health status and the teams taking care of them, Lynn Darrah wondered. So she developed a digital display that was just as easy to update, but the information was visible on any computer in the hospital.

While I take issue with the premise that using whiteboards is too low tech for the 21st century in all cases, I wondered how it was that a computer system for tracking patient status could work in a life critical situation, while it might not on a software project. The problem is that the "paper v electronic" discussion focuses on the wrong thing. The issue for agile teams is not about paper v electronic, it's about collaboration, visibility, improvement, and results.

I do believe that, when you are trying to change a culture, introducing a radically new approach can be a way to encourage people to think about how they work. And it's certainly true that "we've always done it that way" isn't a reason  to continue doing something. But you need to focus on goals and results, not the tools you use. Changing tools should be a result of the tool not helping you to meet your goals.

Yes, I do prefer a physical task board in many cases. And if your team does a sprint review and isn't meeting goals, and communication seems to be an issue, try a physical task board for a sprint or two and compare. But is the if the team has a good sense of where things are during a sprint, communicates frequently, and meets goals, insisting on a physical task board might actually be contrary to the agile value of  putting individuals and interactions over processes and tools.