If you’ve had more than a couple of corporate jobs in your career, you have likely encountered an equity stock option component in your job offers.  If you’ve worked for a startup or other early-stage private company with relatively few employees, you’ve had the potential to receive a larger slice of the pie as an early-stage employee, whether you realize it or not.

I’m not going to dive into what equity stock option grants are.  There is plenty of information online already about that.

It’s an important topic because, if your time is valuable (and it is), you’d like to know that putting several years of your human capital into a venture is going to result in a lucrative exit after your vesting period.  It’s all about how much (or how little) real leverage you are granted with those options.  And nobody has figured out how to manufacture time.

This whole conversation is a lot simpler when you receive a job offer from a publicly-traded company, which is required by law to disclose how many shares have been authorized, issued and outstanding.  It’s completely transparent how much the company has to grow its bottom line for you to reach a certain goal in yours.  You can then use conventional investment planning to estimate the real monetary value of your stock option grant over the vesting period.

Some private companies keep the distribution of company ownership (and options for ownership), also known as the capitalization table, a closely held secret.  This can be problematic if you are trying to fairly negotiate your slice of the pie, since you may not be able to find out the total size of the pie.  It’s also a red flag that there may already be significant disparity across the capitalization table.  Venture Hacks has a decent article on how a capitalization table might be set up, including a sample spreadsheet.

It helps to find out as much as you can about the capitalization table during the interview process, before even getting to the negotiating table.  You may not be able to find out exact numbers or fractions.  Listen out for terms like majority ownership, dilution, and founder status.  It also helps to know the dollar amounts of external investments, particularly the most recent cash infusion.  That number, combined with the current option strike price can help you triangulate the approximate number of total shares outstanding, and a starting point for your negotiations.

In this tight Austin job market, I’m seeing postings for positions like “Seeking Experienced ScrumMaster.”  ScrumMaster is a role – not really a full-time job.  I realize companies are having to dig deep into their goodie bags to attract talent these days, but they’re also applying terms like “ScrumMaster” and “Agile” in full-force buzzword style.  What a shame.  I’ll explain why.

There are 2 basic types of team members in the Scrum framework – chickens and pigs.  Pigs are the ones with “their bacon on the line” and chickens are there to “watch.”  An oversimplification, but I’m going to resist the temptation to digress.

ScrumMasters are pigs.  They are developers like the other pigs on the project.  They just happen to have volunteered (or been bribed or asked) to take on the facilitatory role of ScrumMaster.  Done properly, they have some level of tasking on the iteration schedule to help keep them honest (“at the trough”).  ScrumMasters are intimate with their product and teams, and they are proficient in the technologies with which they’re developing.  ScrumMasters are not project managers.

Scrum teams are self-organizing.  Project status is emitted from the burndown charts and team-maintained task board, as a by-product of each team member doing their part.  Having said this, the short list of responsibilities for the ScrumMaster role does include “enforcing the rules.”  But that’s different than scraping status for management or beating on teams for being behind schedule.

When you hire on a full time ScrumMaster, two important – and unfortunate – things happen.  The person in this job has a slim-to-none chance of owning any individual tasks on the development schedule, which makes them a chicken.  They just don’t have the same level of investment in actually completing the work as does a developer on the team.

The second thing that happens is that the full time ScrumMaster ends up diluting the sense of the self-organizing team.  The ScrumMaster is responsible for keeping the bumper guards in place, not for driving a project or pushing teams to go faster.

If you think you’re going to get someone to serve in the ScrumMaster role on multiple scrum teams, you might really be after a Program Manager.

Even in the biggest of tech companies, nearly everyone takes on multiple roles.  Mentor, liasion or mediator, to name a few.  ScrumMaster is another such role, and you might first suggest someone already on your team step into the role before trying to hire a wolf in sheep’s clothing.  Your burndown charts will thank you.

I ran across an elegant way to sum up what I consider a tenet of leadership, articulated by Lynn Blodgett, CEO of ACS (a Xerox company).

Give people control, hold them accountable, give them control of their resources, and then monitor what they do.  And if you do that, you’re going to tap into, in our business, the highest level of drive — entrepreneurial drive.

Pop quiz: You’re wrapping up your sprint review, and summarizing requests made by your customer.  Do you:

a) commit to fulfilling those requests before the end of the sprint you’re closing out,
b) commit to fulfilling those requests in the next sprint, or
c) not commit to making any changes during the sprint review?

My answer is C.  Let’s explore why C is the best answer.

Think back to when you started the sprint.  You and your team committed to your product owner a body of work to get to Done by a certain date.  You held your daily standups and you had ready access to the product owner and/or customer during the sprint.  Maybe you even had to put in some “overtime” to get things done. (more on why overtime is in quotes in a different post).

In any event: there you are, showing off the work the team accomplished, and now you have a set of feedback items to deal with.  Inevitably, some of that feedback will contain change requests.

It’s usually easy to detect change requests.  These often are prefaced with phrases like “it would be nice if” or “I’d like to see it do this.”

If the team commits during the sprint review to fulfill the requests before the end of the sprint you’re reviewing, then you’re setting yourself up for a short number of very long nights (remember: you also committed to a date at the beginning of the sprint).  You also reinforce the behavior of accepting changes at the last minute.  Not a good path to travel.

Let’s now consider committing to those requests in the next sprint (option B).  On the surface, that sounds better, but it’s only a tiny bit better.  There are reasons why your sprint reviews are separated from your sprint planning meetings.  You won’t have the right people in the room to fairly build out the workload for the next sprint, and pre-committing the latest and greatest change requests could displace other, higher-priority issues that your product owner is responsible for managing.

This brings us to C.  It should be fairly clear why C is the best choice, but if not, here’s why: It’s in the best interest of the team and the customer for the product owner to consider with equal weight the old and the new when it comes to managing product backlog.

It’s in the best interest of the team because you really do need the opinion of the developer(s) that may not be participating in the sprint review for whatever reason, and it’s unlikely you will know enough about these new requests to assign story points on the spot.  You certainly won’t have enough data to make a rational time estimate that feeds the sprint backlog.

Option C is also in the best interest of the customer because she is also not thinking about the backlog, which is out-of-sight-out-of-mind in comparison to that shiny new GUI she is drooling over in the sprint review.  Deferring commitment, even if just until the very next sprint planning session, helps mitigate buyer’s remorse on the part of the customer.

The sprint review is the ceremonial, if not technically the end of the sprint, because it’s near or at the end of the sprint and because the team has met all of their acceptance criteria that they set out to meet at the kickoff.  Be careful to not sabotage the team and its velocity, or otherwise move the finish line, just for the sake of making fast promises to an eager customer.

I’ve been a time management fanatic for a long time now.  I need to have things scheduled, bring closure to tasks, treat others’ time like gold and expect the same of my own time.

I’m quickly finding that becoming a parent is forcing me to up my game.  Tasks or projects that might have acceptably languished for a few days now must be completed between newborn feedings (a matter of hours).  Elevating my own productivity is turning out to be one of the many joys of being a father.

When it comes to personal time, everyone had told me that I would have none at all.  That’s not entirely true.  I do have a fraction of the time I had before becoming a father, and I need to prioritize what I do during that time and manage it as carefully as I do my family/baby time.

I was starting to lose hope that we would ever fall below the 100s. It’s finally getting closer to my favorite time of year though, with cool mornings and warm afternoons. Now all we need is a bunch of rain.

September will also be special because it’s when our first child will be born. Less than two weeks left, and I am much more excited than I thought I would be. We have prepared as much as we can, but I know we’re not truly ready. In a strange sort of way, I think bringing a child into our lives will be healthy in many ways.

I am fortunate to be able to take time off from work to focus on the important things for a while. And true to form, I am setting high expectations for myself to be a great dad. I’m going to try and take it day by day.

Lean and Agile software development frameworks are a great starting point for identifying the bare necessities for efficiently running software projects.  The Agile Manifesto itself is timeless in that it transcends process, rules, methodology and paperwork.  It cuts through to the universal, raw values that compel us to produce working software.

I’m a certified ScrumMaster.  You can take that certification course too, and learn all about the promoted techniques, meetings and artifacts.  What the course won’t teach you, though, is how to fill in the blanks.

One of those blanks is the gap chasm that can exist in your work model between “What do we offer users?” and “what are the concrete components that we build?”

Developers don’t develop user stories; they develop features and functional components.  On the surface, this may sound like semantics, but consider building a search engine.

User Stories answer the question What can I do with the software? Examples of this are “As a user, I can search by string,” and “As a user, I can page through search results.”  Provided that the product manager/owner actually fills in the backstory – rather than offering a meager list of one-liner requirements – the goal of the user story is to give developers enough context to a) coarsely estimate the complexity of the user story and b) identify the feature(s) that fulfill the user story.

There’s where some popular frameworks, including Scrum, dive headfirst into “start the sprint and we’ll see you in 4 weeks.”  Out of the box, there are few suggestions of how to operate after planning meetings and within sprints (iterations), other than “have a daily standup” and “end on time.”

One of the glossed-over steps is the need to synthesize a design for the features (and their inter-dependencies) that your team will use to fulfill the user stories under consideration.  Your architect or technical lead may be the one that produces this.  To extend the rugby metaphor offered up by Scrum: think of this as part of your game plan.

Once you have this game plan in place, your team will have the goods to provide finer-grain estimates for the work at hand.  Also, for you Scrum purists out there: there’s no rule that says you can’t allocate time for progressively elaborating this game plan inside a sprint. The important thing is to be deliberate about your feature breakdown, account for it, and adjust the rest of your schedule accordingly.

The moral of the story is this: Don’t expect too much from the framework you choose.  It’s up to you and your organization to define the processes that govern how you behave within that framework.

One of the cornerstones of agile development is striking a balance between planning, design and execution.  The idea is that you don’t really know what you will be doing 6 months from now, and that users don’t use a design, they use your product.  Spending as little time as necessary on Big Design Up Front (BFUD) shortens the feedback loop until you get confirmation that the requirements and design you thought were valid actually are valid.

To be fair, it can be easy to paint yourself into a corner by not doing enough upfront design.  However, it’s important to remain aware of the intersection between “we have a future-resistant design that meets customers’ needs” and “you ain’t gonna need it” (YAGNI).  At the point where you start speculating on user stories, especially those that will convoke significant cost (and waste if unnecessarily implemented), stop and consider whether the cost of designing for possible futures now outweighs the cost of fixing a problem later.

Designs, like plans, should be expected to change.  Building software is not like building a house.  Studs can be moved around and foundations can be adjusted later.  We must plan and design with change in mind, because the requirements are going to change whether we like it or not.

Lots of life changes abound.  New job.  New (first) baby on the way.  Need to share thoughts and ideas.

When I’m old and rickety, I will have wished I had built memoir content along the way.  This should help with that.