• What Scrum got right

    Scrum was a huge change in how software was built and a lot of its ideas are great, but some also have major problems.

    Most of my experience is in early stage startups and may not apply as well to larger organizations, though I think a lot of it still does.

    What scrum got right

    Continuous improvement: Retrospectives on a schedule to keep improving the process for the team.

    Daily stand-ups: Help make sure people aren’t spinning their wheels and help collaboration between team members.

    Demos: Keep everyone up to date on what’s working and get feedback. More important as the team grows.

    What scrum got wrong

    Sprints: I really hate sprints. They cause constant deadline pressure that isn’t helpful and doesn’t help get work done quickly. In my experience it just burns people out.

    Sprints, even short ones, always have other tasks/stories that come up and need to be done during the sprint. I’ve handled this differently on different teams. In one we had a rotating role that only worked on bugs and one off things that came up during the sprints. Most of the time it just ends up meaning something else on the sprint doesn’t get done.

    Priorities can change at any time and waiting for the sprint to end to adjust just delays things in the best case and causes work to be thrown out in the worst case.

    “Work expands so as to fill the time available for its completion” - Parkinson’s law

    Sprints lend themselves to this and it almost always works that way. This is kinda of a double hit between sprints and estimation.

    Now for Estimation

    The idea of estimation by points in scrum is good, but in practice it doesn’t work well and doesn’t provide the business any more meaningful expectation of completion then just ball-parking an estimated date.

    I know there are lots of reasons why business wants estimates from the development team. But I really don’t think development, specifically custom development like in a startup or quickly moving team, can be estimated with any accuracy.

    My process or at least my starting point.

    • Monthly retrospective & OKRs review

    • Daily stand-ups or check-ins.

    • Prioritized backlog of stories or tasks.
      • Releasable, can be released.
      • Small, under 3 days of work.
    • Kanban board to pull work though.
      • Backlog: Priority ordered stories.
      • Blocked: Things that can not be worked on right now.
      • WIP: Work in progress is moved to verification after it’s deployed.
      • Verification: This should be done by product people.
      • Completed: Tested, in prod, and verified.
    • Continuous Delivery
      • Automated Unit tests
      • Automated Integration tests
      • Automated Deployments
    • Scheduled Demos

    Retrospectives & OKRs

    I like doing these once a month and I like the normal:

    “What’d we do well, What can we improve, and What should we stop”

    I think the last one is the most important for improving the process.

    OKR’s or goals are good to have and review in these meetings. Without them, people don’t know where they are going. I want everyone to know where we’re going and let them figure out how to get there.

    Daily Stand-ups

    Again I like the normal scrum:

    “What did I do yesterday, What I’m doing today, and I’m I blocked on anything?”

    Though, I mostly don’t care about the first one.

    “What am I doing today?” gives the rest of the team a chance to jump in with helpful information or questions that might be related.

    “What’s blocking me?” allows me to help remove the blocks and keep things moving forward. I’d rather hear about these before the stand-up, but sometimes people don’t know they’re blocked until they think about it.

    The Backlog

    This is just a list of stories in descending priority order. It up to the product and the development team to keep them in order. Having clear goals will help this happen.

    When someone is ready to work on something, they take the closest to top thing that they can do. This helps with cross pollination because the top thing might not be the normal stuff they work on, but they should still choose it if they can.

    Stories should be releasable bits of functionality and have some clear value, even if it’s really small.

    They should be about 3 days of work with a very general ballparked estimate. If it’s more than that, break it down further.

    The development process

    The idea is to pull a story on the backlog to working in production. We need a few things in place for this to happen.

    • Code should have automated tests. Mostly unit tests with some integration and some acceptance tests as the system grows.

    • Writing and running test should be easy for each project.

    • All code checked into master should be releasable and should be released with an automated process.

    • Code changes that feel like they should be reviewed, should be done with a pull request.

    With this in place, the general flow goes something like this.

    Take the top story and move it to Work In Progress (WIP). Once it’s released to production, move it to Verification and notify the story creator. It then becomes that persons task to take a look at it and move it to complete or back to WIP.

    The hard part: The number of things in progress, WIP, Verification, Blocked, should be close to one per team member. If verification starts building up you should work with the team to get those cards verified before taking another card from the Backlog.

    In the past, I haven’t enforced WIP/Verification limits to the number of things in those states, mostly because people will just work around them.

    Lastly, there is usually a Blocked column or state for things that are blocked. Having a column allows it to be noticed and unblocked quickly.


    Get everyone on the same page!

    There are two things that need to be demoed, production features and development features. While these have different audiences I think it is valuable to demo both at the same time.

    Demos should happen on a regular schedule like weekly or every other week.

    No Estimation

    Some business have deadlines, but most business don’t have many, if any, hard deadlines. So trying to estimate ends up being a waste of time and a self fulfilling prophecy.

    There are lots of arguments on both sides of this and reality is always somewhere in the middle.

    My approach is to keep the stories in the backlog to a size of 3 days work or less. And that 3 day estimate is just a quick gut based guess.

    If there is a deadline to a need to communicate a date to a customer, I like to talk through the details of that specific thing and figure out a plan.

    But we need some estimation and plan…

    I recently came across the idea of GIST Planning which seems like a really good way to manage roadmaps.

    I don’t know the right answer here, but I think traditional roadmaps and detailed estimation isn’t it.

    What other approaches have you used for this?

  • Upgrading dev tools: puma-dev and asdf

    Replace POW with Puma-dev

    Read POW to Puma-dev

    Puma-dev project

    I changed the .dev domain to .test.

    puma-dev -install -d test -dir ~/.pow/

    Replace RVM with asdf

    Remove RVM Clean RVM

    sudo rm -rf $HOME/.rvm $HOME/.rvmrc /etc/rvmrc /etc/profile.d/rvm.sh /usr/local/rvm /usr/local/bin/rvm

    Remove from .bashrc|.bash_profile|.profile|.zshrc

    But removing RVM broke Vim, so I did brew upgrade vim to fix it.

    Very detailed write up: Replace RVM w/ asdf

    asdf project

    Follow install info from project.

    Update/Add ~/.asdfrc

    legacy_version_file = yes

    Ruby Default Gems; Add ~/.default-gems


    Make sure you have required deps installed and updated.

    brew install coreutils automake autoconf openssl libyaml readline libxslt libtool unixodbc
    brew install wxmac

    Install the plugins for the things you want. There are a lot more!

    asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git
    asdf plugin-add erlang https://github.com/asdf-vm/asdf-erlang.git
    asdf plugin-add python https://github.com/tuvistavie/asdf-python.git
    asdf plugin-add ruby https://github.com/asdf-vm/asdf-ruby.git
    asdf plugin-add nodejs https://github.com/asdf-vm/asdf-nodejs.git
    # Imports Node.js release team's OpenPGP keys to main keyring
    bash ~/.asdf/plugins/nodejs/bin/import-release-team-keyring

    Install versions & set the defaults

    asdf install ruby 2.5.0
    asdf global ruby 2.5.0
    asdf install erlang 20.2.3
    asdf globabl erlang 20.2.3
    asdf install elixir 1.6.0-otp-20
    asdf global elixir 1.6.0-otp-20
    asdf install nodejs 9.5.0
    asdf global nodejs 9.5.0
  • Sass Bootstrap 4 in Phoenix 1.3

    Add dependencies to assets/package.json

    • Add font-awesome, bootstrap, jquery to dependencies
    • Add sass-brunch and copycat-brunch to devDependencies
      "dependencies": {
       "phoenix": "file:../deps/phoenix",
       "bootstrap": "4.0.0",
       "font-awesome": "4.7.0",
       "popper.js": "1.12.9",
       "jquery": "3.3.1"
      "devDependencies": {
       "babel-brunch": "6.1.1",
       "brunch": "2.10.9",
       "clean-css-brunch": "2.10.0",
       "uglify-js-brunch": "2.10.0",
       "sass-brunch": "2.10.4",
       "copycat-brunch": "1.0.9"

    Change the app.css to app.scss

    • Delete assets/css/app.css
    • Add assets/css/app.scss
    • Include font-awesome and bootstrap
    $icon-font-path: "/fonts/"; /* use fonts from priv/static/fonts/ */
    @import "font-awesome";
    @import "bootstrap";
    // Overrides 

    Watch for changes in config/dev.exs

    Add scss to the patterns config

      live_reload: [
        patterns: [

    Update brunch-config.js

    1. We need to make sure app.scss loads last
    2. Add copycat config for the font-awesome fonts
    3. Configure scss to include bootstrap and font-awesome
    4. Add $, jQuery, and bootstrap to the globals
        stylesheets: {
          joinTo: "css/app.css",
          order: {
            after: ["../priv/static/css/app.scss"]
        babel: {
          // Do not use ES6 compiler in vendor code
          ignore: [/vendor/]
          "fonts" : ["node_modules/font-awesome/fonts"],
          onlyChanged: true
        sass: {
          options: {
            includePaths: ["node_modules/bootstrap/scss",
              "node_modules/font-awesome/scss"], // tell sass-brunch where to look for files to @import
            precision: 8 // minimum precision required by bootstrap-sass
      npm: {
        enabled: true,
        globals: { // bootstrap-sass' JavaScript requires both '$' and 'jQuery' in global scope
          $: 'jquery',
          jQuery: 'jquery',
          bootstrap: 'bootstrap' // require bootstrap-sass' JavaScript globally

    I think that’s it. Might have to cd assets && npm install and restart Phoenix.

  • Getting started with Elixir

    Phoenix is a web framework build on Elixir, which runs on the Erlang VM. Why check out another web framework & language?

    IDK… the grass is always greener. There are new ideas in new frameworks. Maybe one will fit more with my personal development opinions.

    So here we are. So far I like it. Both Elixir and Phoenix. Have only started some very basic hobby apps. Elixir is very Ruby looking, but pretty different in most regards. It’s functional for one big one. And immutable.


    brew install elixir


    Like Lein & Rake

    mix help
    mix new PROJECT_NAME --sup


    Like Gems https://hex.pm is the place to find then and see how popular they are.

    List of Elixir libs

    CRON scheduler


    Web development

    mix phx.new PROJECT_NAME


    Slack: elixir.slackin


    Plug 'elixir-editors/vim-elixir'
    Plug 'slashmili/alchemist.vim'
  • CES 2018


    CES was about robots this year. There were a lot of toy focused robot kits that were cool. I like the Jimu kit the most.


    And there were robots for automating tasks, like laundry, one’s for playing ping pong, which was more about reaction time and appropriate force. I’m sure there is always robot stuff, but felt like they took it up a level. My favorite was a 3d printing arm, which produces filimate prints as good as the box style printers.


    As always there were TVs, drones, and phones. The codrone was cool in that it had a programable interface that would let you control the drone however you wanted, for example with you computer camera and hand motions.


    But the coolest stuff was again in Eureka Park.

    Tons of home automation stuff, personal data trackers, and AR/VR stuff. AR/VR stuff still seems early, but also like huge progress from last year. I liked the Swidget outlet with it’s swapable modules for different types of automation technologies. They have dev boards for making your own modules and an API coming in the future.


    The coolest looking thing for me was a new motorcycle from Yamaha. Electric, self driving functions, and heads up display. Also, amazing looking design.


    Business wise, the BLE 5 chips are a big jump forward and offer some pretty awesome tech. Looking forward to playing with those dev kits! Of course, we had good meetings with a bunch of folks, parties, and networking, which is where the value really is.

  • GoBuffalo Nested Resources

    Buffalo is a web framework written in Go by Mark Bates. I’ve been working more with Go and started using Buffalo. Mark has done an awesome job with it! Thanks Mark!

    Pretty quickly into my app I wanted nested resources. Support for them seems pretty much there. It takes some work, but all in all it was pretty easy to get going. Here are some notes about how I approached it.

    Getting started

    I started following some of the videos on the Buffalo site. From there I generated some resources; User, Org, Index. I wanted Indexes to be nested under Orgs.



    indices := app.Resource("/orgs/{org_id}/indices", IndicesResource{&buffalo.BaseResource{}})

    There we grab a reference to the resource group, named indices and then add the LoadOrg middleware.


    Every action in the Indices resource should have the Org available. I was looking for some BeforeAction hook or something, but didn’t find any. Enter middleware.


    func LoadOrg(next buffalo.Handler) buffalo.Handler {
    	return func(c buffalo.Context) error {
    		tx := c.Value("tx").(*pop.Connection)
    		user := c.Value("current_user").(*models.User)
    		o := &models.Org{}
    		if err := tx.BelongsToThrough(user, "org_users").Find(o, c.Param("org_id")); err != nil {
    			c.Error(404, err)
    		c.Set("org", o)
    		return next(c)

    This does two things…

    1. Make sure the Org is available to the User.
    2. Set org in the Context


    The actions need some updating, mostly updating them to scope the queries to the Org, make sure new Indexes get added to the Org, and changing some of the redirect URLs.


    func (v IndicesResource) scope(c buffalo.Context) *pop.Query {
    	tx := c.Value("tx").(*pop.Connection)
    	org := c.Value("org").(*models.Org)
    	return tx.BelongsTo(org)
    func (v IndicesResource) newIndex(c buffalo.Context) *models.Index {
    	orgID, err := uuid.FromString(c.Param("org_id"))
    	if err != nil {
    		c.Error(404, err)
    	return &models.Index{OrgID: orgID}

    Those two helper functions help scope the queries and set the OrgID on new model instances.

    I’m not showing all the changes needed, they’ll be pretty obvious.


    I was kinda worried about this, but it turned out to already be supported. I’m not sure if it’s part of Mux or Buffalo yet, but either way it works.

    What works? You’re wondering… links!


    <!-- Generated Version -->
    <li><a href="<%= newIndicesPath() %>" class="btn btn-primary">Create New Index</a></li>
    <!-- Nested Version -->
    <li><a href="<%= newOrgIndicesPath({org_id: org.ID}) %>" class="btn btn-primary">Create New Index</a></li>

    Adding Org or org to the path function and passing in the org_id value was all that was needed. And the org is in the Context already thanks to out middleware above!

    Would love to know if I missed something already built in to the generators or a better way to handle any of this, but pretty happy with the results.

  • Starting cloudsh search project


    I’m starting a new side project to learn Golang and use AWS Lambda.

    The basic idea is an API that will index a website and provide a searching interface using JavaScript.

    The target users are those creating static / generated sites. Sites where having a database setup doesn’t make sense.

    I’m gonna run the API and processing on AWS Lambda using the awesome Apex and Up projects. I really like the serverless idea and am looking forward to trying it out.

    If it sounds interesting, join the mailing list at cloudsh