mikehking dot com

Reflections on technology, business, and life



Using JIRA to Scale your Business

I recently spoke at the 2017 Capability Counts conference, put on by the CMMI Institute. David Anderson Keynote 2017.PNG It’s an interesting event that isn’t focused just on CMMI maturity models — instead it’s a conference where a few hundred people get together to discuss process improvement, Agile, software engineering processes, and a variety of other related topics.

The keynote (shown in the picture above) is David Anderson of LeanKanban University talking about the core concepts of Kanban, which go far beyond most people’s understanding of 3 column boards.

I spoke on using Atlassian’s JIRA product to help an organize scale — sharing some best practices/recommendations on how to use a tool like JIRA to get information out of email, hallway conversations, and meetings and into a system where work can be clarified, prioritized and tracked.


Organizational Operating System Upgrade?

I’ve started reading Brian Roberton’s book Holacracy, which talks about an organizational
management approach focused around self-organization and protected autonomy.  It’s an interesting attack on the base assumption that we should build companies in the traditional, top-down approach where a CEO directs leaders who direct other leaders, through layers and layers of business leaders.  Holacracy is the first non-traditional approach I’ve seen to business architecture (designing a company) that is cohesive and specific.  Managing teams with a methodology like Agile Scrum is powerful, but Scrum doesn’t scale to an entire organization, without armies of Scrum of Scrum Masters.  Early in the book, Brian lays out this metaphor of a business having its own operating system (including the org chart, business processes, etc.):

…the operating system underpinning an organization is easy to ignore, yet it’s the foundation on which we build our business processes (the “apps” of organization), and it shapes the human culture as well.  Perhaps because of its invisibility, we haven’t seen many robust alternatives or significant improvements to our modern top-down, predict-and-control “CEO is in charge” OS.  When we unconsciously accept that as our only choice, the best we can do is counteract some of its fundamental weaknesses by bolting on new processes or trying to improve organization-wide culture.  But just as many of our current software applications wouldn’t run well on MS_DOS, the new processes, techniques, or cultural changes we might try to adopt simply won’t run well on an operating system built around an older paradigm.

Brian describes an entire methodology, like some of the prescriptive ceremonies and roles you see in Agile Scrum; which I’m still wrapping my head around.  The core tenets of independent, autonomous roles seems incredibly powerful, because it seems to make companies much more scalable.  And it reminds me of the core factors that Daniel Pink identified in Drive as what employees wants in their job:

  1. Autonomy: People want to have control over their work
  2. Mastery: People want to get better at what they do
  3. Purpose: People want to be part of something that is bigger than they are

Holacracy’s concepts explained in 107 seconds:

What is Agile Scrum?

Ken Schwaber’s book on Scrum, which falls under the Agile umbrella of methodologies, is a great introduction to Scrum, and I love the mini case studies (1-2 pages) he puts in the book to make the concepts more accessible.  Here’s how I’d summarize Ken’s description of the Scrum software development process at a high level featuring the Product Owner (client representative), ScrumMaster (process representative), and the cross-functional, self-organizing team.

  1. Product Owner defines vision with Product Backlog (spreadsheet showing requirements or user stories, sorted by priority, shows estimated complexity)
  2. Sprint planning meeting is 8 hour meeting:  first half is Product Owner discussing priorities for next 30 day sprint and the team estimates how much can be completed in next sprint; in the second half, the team builds the Sprint Backlog (spreadsheet that shows  tasks (should be 4-16 hours of work each), responsible team member, status, and hours of remaining work), decomposes the requirements into tasks, and updates the Burndown chart (line graph showing days of remaining work on Y axis and sprint number on X axis, which can project the end date with a trend line)
  3. Team develops, with a daily scrum (15 minute coordination meeting focused on yesterday’s accomplishments, today’s focus, and risks), focusing on delivering complete functionality by the end of the sprint (designed, developed, tested, and documented for users)
  4. At end of sprint, Sprint Review meeting is held (4-hour meeting where the team demonstrates new functionality to Product Owner and other stakeholders, and upcoming priorities are discussed
  5. ScrumMaster leads Sprint Retrospective meeting with team (3-hour meeting to refine how the team should revise it development processes)
  6. Repeat steps 2-5 until project is completed or funding ends

For a great 9 minute YouTube summary of Scrum, check out Intro to Agile Scrum in Under 10 Minutes

CodeAcademy Demo Day

I was in Chicago last week for CodeAcademy‘s (.org, not .com) demo day, and I was blown away.  CodeAcademy is an intense, 12-week program that teaches web application (Ruby on Rails) and web design skills to people with a wide variety of backgrounds (including many without a technical background).

I met one of CodeAcademy’s founders, Neal Sales-Griffin back in December at a CodeNow event; and was excited to hear about the organization that he had created.  I was blown away when I went to see it in action — CodeAcademy has brought today great teachers; a powerful network of volunteer mentors; and a diverse, impressive set of students.  Last week’s demo evening, which was presented to a packed house, included 3 minutes presentations from all students and some of the teachers.  Some of the students focused the many things they’ve learned, and many showed off projects they’ve been working on including some impressive web applications including:

There were some great insights from the students and teachers at the event, including:

  • When you love creating things, doing anything else isn’t fulfilling
  • The collaborative learning of CodeAcademy had some impressive results — like the creation of utility apps like
  • You have to be 10 times better than the current solution to get people to change their behavior
  • Simple doesn’t mean dumb in design, it means elegant design
  • Know your users (reminds me greatly of my time recently at Lean Startup Machine DC)
  • One of the students was inspired to pursue CodeAcademy by hearing about @dhh buying a Lamborghini
  • The HTML/CSS teacher, Shay Howe, has an awesome, free set of HTML/CSS tutorials at
  • Carolyn Chandler’s presentation on design was awesome

FYI:  DevBootCamp in San Francisco and Hungry Academy in DC are similar to CodeAcademy, but each have their own business model and culture.

Initial reactions to Lean Startup Machine DC

This weekend I experienced the intensity that was Lean Startup Machine DC (#LSMDC).  I went with without lots of expectations — I haven’t read The Lean Startup book, I haven’t been to any similar events, and I didn’t know anyone who had.  It turned out to be an intense, great experience.  The highlight for me was meeting all kinds of fascinating people thinking about or already doing cool stuff in the DC startup/entrepreneurship scene. My initial reaction to lean, with has some significant overlap with agile, is focused on quickly validating business models through real tests of your assumptions.  Not thought experiments, not talking it over with you buddy; but real, tangible ways to test your assumptions by removing assumptions.  For example, an early idea of the team I was on was:

  • Assumption:  people would share job openings on their social networks if they would get paid for helping getting someone hired
  • Realization:  people are protective of their social status, as part of their online identify, and only want to share opportunities that help a friend and/or are associated with a cool company

Much of the weekend was spent wrapping my head around using tools to validate or invalidate assumptions (using tools like Google Ad Words, Facebook ads, talking to domain experts (finding them using your network and social media), and pitching concepts).  In addition, there was a huge focus on collecting “currency” or tangible validation of your idea, which could include letters of intent from vendors, clicks on ads (see, email addresses on a launch page (see, initial payments, etc. The weekend started with people pitching ideas on Friday evening and forming teams and ended with a Sunday afternoon series of presentations of each group, focused on their process, what they learned, and their results.  In between, there were some great local people sharing their expertise in entrepreneurship and lean concepts; as well as a team of mentors around to help guide people through the process. Some highlights included:

  • Peter Corbett talking about iStrategyLabs
  • Discussions with Teague Hopkins about the future of the office of CIO
  • Maksim Tsvetovat discussing how social networks grow
  • Stephanie Hay’s discussions on initial tests instead of getting stuck in talking about ideas
  • Great ideas from Chitra Sivanandam about focusing on pain points (and hearing about some of the super-cool stuff she does)
  • Hearing Brian Sowards’ story of how he used lean to iterate a weak idea into a multi-million dollar valuation

Agile Personal Productivity

Time management is always tough, and lots of people have written some great things on the topic, such as David Allen’s Getting Things Done.  A connection I made recently that I found fascinating was the intersection of agile software development practices (Ken Schwaber’s books Agile Project Management with Scrum is excellent, recommended to me by Derek Huether) and personal productivity.  Agile concepts are based on trying to accelerate progress by relying on short sprints of productivity broken up by planning periods.  This is the best approach I’ve found to management my own to-do list — by frequently assessing my top priorities, both short-term and long-term, and working in bursts to make appreciable progress towards them.  It’s very similar to the productivity concept of putting the “big rocks” on the top of our priority list (see big rock explanation here).  But it’s more than just focusing on the big stuff, it’s also essential to focus on frequently reassessing what’s the top priority, to avoid working on something that isn’t key anymore.  It’s that key of working on what’s important, which can be hard when we want to close things out — something very tempting when you want to feel progress by removing things from your to-do list by closing something almost done when it’s not the most important thing, or just knocking out the easy things (this concept of closure seems to be especially relevant to men, see Men are like Waffles, Women are like Spaghetti).

So what I’ve been trying to do is:

  1. Examine my priorities daily, to make sure I’m focused on the right things
  2. Spend a little time (about an hour) knocking out the quick actions and delegating what should be delegated
  3. Focus big, solid blocks of time on making progress on the biggest, most important, most time-sensitive things

Blog at

Up ↑