In either Scrum or Kanban, it's important to separate your development cycles from when you release or deploy cycle.
For example: In Kanban, our developers work in a flow model to get anything and everything they can get done as fast as they can get it done (regardless of when the release is planned). We manage the work by using work in progress limits. However, we have a public releases that are scheduled every two weeks. So on that scheduled release date, we take all the completed tasks lump them into a release. Nothing holds up a release. For high priority feature, we'll do a hot fix. For big announcements, we'll usually schedule it after we've completed most of the work.
Scrum is the same in this regard at most companies. A public release could happen after 1, 2, or 200 sprints. It really just depends on what you're trying to do.
In the Apple AppStore model, Kanban or Scrum should have no impact on how you deploy. You deploy when you're ready. Kanban no Scrum guarantee that it'll happen by a certain date.
Good point. I think it's wise to due your diligence on the APIs you're considering. Do they have a good track record of availability? Supporting backwards compatibility when they release features? Are they secure? Is it well documented?
Here at Stormpath, these items are a higher priority than any new feature.
Do you have any specific suggestions on how to connect with the higher level decision maker when you were contacted by a lower level employee? Thanks for the great article.
If you're following up and are not getting a response then set a limit to the number of times you'll try again. I personally do 3 follow-up email over the course of a 3-6 weeks. On the last email, I let them know it'll be the last time I follow-up and let them know how they can reach me if they'd like to talk in the future.
If you just keep following up and never stop, you'll likely annoy someone who is probably not interested in what you're selling and you'll likely get spam filtered.
One other spin on the follow up comes in timing and content:
Follow up after 2 days, 7 days, 2 weeks, 3 months, and annually. This increasing time frame rarely is found to be annoying and is an effective way to keep in front of them. Also try and send a new set of content after 2 contacts.
1. It could just be a random drop in the numbers. The VC world is VERY small and there are VERY few players. Equally, VERY few deals get done every year. Moreover, megadeals can really skew the numbers. So even seemingly small randomness can have big effects on volatility. Heck, look at the chart!
2. There's a well documented drop in the number of venture firms out there and in turn with available capital. Less supply...
3. Many venture firms have been burned by gaming and consumer oriented investments and moving trying to move back to their IT roots. However, the majority of angel and seed investing only recently started focusing IT so the there could be a pipeline issue.
Ok here's an analysis on job satisfaction that I found interesting.
1. very weak relationship to high compensation. Not completely surprising and in-line with much of the research.
2. Here's a hard one. No significance of consumer device (tablet, gaming console, etc) EXCEPT for Apple devices (albiet a weak one). All the fanboys are probably nodding their heads but I challenge you to explain it rationally.
3. The importance of work/life balance seems to show in the data with weak relationships to job satisfaction but its mostly around hours spent working and commuting. Why is it only a weak relationship?
4. Suprisingly, life at work seems to be less related to job satisfaction. With only very weak relationships to things like quality of office space, bureaucracy, quality of workstation, # of meetings, opportunities to work on new tech, and opportunities for growth. I wonder if perhaps the data is skewed by the averages. I wonder what the data would look like if you separated tier 1 developers from everyone else.
Windows 8 devs were as happy as Mac devs, which was interesting. No-one else was close. Also note that Mac devs tend to work in smaller shops, which is correlated to happiness.
Game devs were the happiest devs. So - work for a small mac game dev.
More exprienced developers spend more time refactoring code? Does that mean that they're working on crappier code, established code bases, or higher end applications where tech debt really matters?
Conversely, are the younger guys spending less time because they don't know any better, working on small projects where tech debt isn't a priority, or working on completely new code.
My guess it's a reflection of the type of work being done.
Meritocracies are great sometimes but they have the nasty side affect of promoting people into jobs they suck at. Just because you're the best at being an individual contributor, it doesn't mean you're going to be a good manager, and being a good manager doesn't mean you're going to be a good executive or entrepreneur. In organizations that value meritocracies absolutely, you end up losing your best people if they don't scale.
This is known as the Peter Principle. But, I would think a meritocracy would strive to test for, or respond to, promotions into levels of incompetence by pushing the person back down into a role where merit is higher than other available candidates.
Something the article didn't cover but should is the upkeep over time of whatever algorithm you use. We can argue about todays algorithms. But what do we do when those algorithm are superseded? Or when the minimum complexity factor needs to go up. If you're an app dev or devops, will you know when that happens and how will you update?
For example: In Kanban, our developers work in a flow model to get anything and everything they can get done as fast as they can get it done (regardless of when the release is planned). We manage the work by using work in progress limits. However, we have a public releases that are scheduled every two weeks. So on that scheduled release date, we take all the completed tasks lump them into a release. Nothing holds up a release. For high priority feature, we'll do a hot fix. For big announcements, we'll usually schedule it after we've completed most of the work.
Scrum is the same in this regard at most companies. A public release could happen after 1, 2, or 200 sprints. It really just depends on what you're trying to do.
In the Apple AppStore model, Kanban or Scrum should have no impact on how you deploy. You deploy when you're ready. Kanban no Scrum guarantee that it'll happen by a certain date.