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.

Kanban

I've worked with Scrum for a while, having gotten my CSM certification in 2005, and I've spent time both before and after that trying to learn what I could about Scrum, agile, and Lean, both in the context of software and out side of it. After absorbing bits of information on Kanban informally, I decided that to was time to read a book on it. I read David Anderson's book Kanban: Successful Evolutionary Change for Your Technology Business.

Anderson's book was a good introduction to Kanban in practice. It had a mix of stories, theory and guidelines that gave a good sense that the content of the book was based on practice. My only reservation about the book was that while it was well written in many spots, there were places where it was a bit less focused that I would have liked. But if you are willing to skim through the less tight parts of the book, it is worth a look. Here are some of the things I learned while reading Kanban.

Before I read about Kanban in detail my initial impression was that  people new to agile, who didn't find Scrum appropriate for their project, were enthusiastic about Kanban because was that they were unwilling to be disciplined enough to manage their work queue. It's hard to move from one's current approach (either a long term rigid planning approach, or chaos) to an approach that required the discipline to work in the context of shorter term commitments (Sprints). With Kanban, you can think in terms of a stream of work. Problem solved!  Or at least hidden. I'm now beginning to understand that, while it might be true that some people and teams are enthusiastic about Kanban over Scrum for reasons like this, that's not all there is to it.

Much of what I learned in Anderson's book about Kanban sounded familiar (not surprisingly) based on what I know about other agile methods. You can use an entirely Kanban-based approach to a project. But, there are elements of Kanban that you can overlay, on say, a Scrum project. The concepts such as limiting work in process (and making that limit explicit) seems line with that Scrum teams I have worked on have done. Scrum teams can certainly benefit from a deep understanding of Kanban principles much as a Scrum project is likely to fail without applying technical practices such as those of XP. (For more a more in depth comparison you can have a look at the article by Henrik Kniberg and Mattias Skarin
on infoQ,  )

Kanban is less structured than Scrum in terms of boundaries and commitments. While in some sense this sounds promising for teams that wrestle with "interrupts" like "critical production issues" it also means that there is less of a framework to identify and address the underlying problems, and the path to improving your process might be slower.  Kanban can be useful. If you use your imagination, you might even think that Kanban is the limit of Scrum as iteration length approaches 0. If teams have trouble managing 2 week iterations, they are likely to have problems with no iterations. At least until teams internalize agile practices and values fully, Scum is probably still a better fit for teams wanting to adopt agile.  (See  Ken Schwaber's comments for a more strongly worded view on this).

While there are aspects of Kanban that will inform my Scrum practice, I think that for those trying to adopt agile, Scrum is a better approach. Kanban might seem to work well, and present less of a barrier to managing a hard to manage backlog, but keeping work in line and maintaining the sustainable pace and slack that  both Scrum and Kanban advise can be much harder. Rather than being an easier way to agility, Kanban seems to require more discipline, and starting with Kanban might not the the right answer for many teams.




 

Do we care whether it's Software Engineering or Craft?

Much like a tenet of agile software development is that "planning is more important than the plan," there are some questions about software development that are useful to explore, even if you can't suggest a good answer. One of these these is whether what we, as software developers do, is (or can be) engineering.

I was talking with a colleague about a comment someone made about a post about lessons that software engineers can learn from artists. In this comment the poster raised an issue that comes up a lot when someone uses the phrase "software engineer." The question was, in essence:

Is what we do when we build software "engineering" or "craft?"

My colleague, who has a background in Naval Engineering and who is engaged to an Electrical Engineer (who designs and builds hardware) suggested that the difference is that one rule of thumb might be:

It's engineering if you need to use calculation (about physical constraints).

An example was that to build a bridge you need to do calculations to determine if the bridge, as designed, will support the load you want to support. Many of the "classical" engineering disciplines (Mechanical, structural, electrical) fit that criterion. But by that definition, some things which most would agree that are crafts, such as carpentry, involve calculations. So there is probably more to it that that.

On the other hand, I don't think that all work that is in a discipline that we might call "engineering" is engineering. A good friend designs test equipment for a living. When he builds a sensor to measure the performance of his home heating system is he doing engineering, or is that activity more like a hobby or craft?

As I think of the question, and the frequency at which it comes up, I wonder:

Why does it matter whether we are software engineers or software craftsmen?

Engineering, to me, implies a certain level of discipline are repeatable process, and all of the classic engineering disciplines are grounded in physical laws that we are fairly confident in for the scales at which they apply.

If the "software engineering" question is important to you, take a minute to understand why you are asking the question, as the reason for asking may affect the answer.  You can bring discipline to building something you regardless of whether or not you are engineering. I don't think that the question of how (or whether) to make software into an engineering discipline is an unimportant one. But I do think that it is often asked in a vacuum, much like the an attempt at a user story that is missing the "so that..." clause.

To me, as a professional, it's more important that I bring discipline to what I do. I want to build useful, quality, software where the definition of "quality" that is often most appropriate is Jerry Weinberg's from Quality Software Management: Systems Thinking:

Quality is Value to Some Person.

It might be fair to say that we're not always "crafting" or "engineering" software when we sit down at an IDE and program. Sometimes we're just coding (or hacking, or programming). But if you (and your team) are committed to building software that meets your customers needs, and you are always working to learn how to work better, you're doing a good thing. And you don't need to call it engineering to acknowledge that.

Agility (and Learning Opportunities) Everywhere

People often ask "can I apply agile methods to something other than software development?" Since the basic appeal of agile methods is to acknowledge uncertainty by planning in increments, evaluating where you are relative to the plan and other forces, and planning the next increment, it seems like there should be no obstacle to following an agile approach for any project. The lurking question many have is "but can my type of project really be structured in an incremental way?"

While in general, I tend to believe that the answer is "yes," it's always good to have examples. So I was intrigued to head a segment on the radio show Living On Earth, where the rapper Baba Brinkmann described his approach to developing The Rap Guide to Evolution as "Performance, Feedback, Revision," which is a very concise way to describe an agile approach. This meta-aspect of this also intrigued me, as Brinkman used the performance, feedback, revision theme in the evolution rap as well.

This is also another reminder of how software developers can learn much from many seemingly unrelated domains. As Rob Austin and Lee Devin explore in Artful Making: What Managers Need to Know About How Artists Work managers, including software managers, can learn from theatre, and in Computers as Theatre Brenda Laurel discusses what interaction designers can learn from theatre.

So, yes, you can be agile if you are doing something other than software, and if you are developing software you can learn how to build software better by looking at other disciplines.