View more photos of the visit to Troegs Brewing Company

Using Lean Manufacturing Techniques

I have been using a Kanban flow system to manage software development on my team at PR Newswire.  One of the techniques in this aspect of Lean Manufacturing is using Visual Communication Boards to highlight work in progress.  Among the sophisticated brewing equipment at Troegs you will find simple, clear methods of visual communication enabling teams to work together.

Distribution

The beer industry has a 3 tier system of distribution in which the Brewery produces the beer and sells to the Wholesaler.  The Wholesaler warehouses the beer and distributes to the Retailer (bars, restaurants, liquor stores).  Each state has different laws, each type of alcohol has different distributor focus and the whole system is very competitive.  Next time you walk into a liquor store or notice tap handles at a bar, think about all of the negotiation and strategy that goes into convincing you to choose a certain beer.  I learned how important it is to be “on the handle” and “between eyes and thighs”.  Not the type of thing I consider when building software but now I see these concepts everywhere I buy anything.

Collaboration

Yes, Craft Breweries compete wth each other but I was impressed at how collaborative the industry as a whole is.  It reminded me of the Boulder tech scene, lots of competition but “the rising tide lifts all boats” mentality is ever present.  One of my favorite stories is about Collaboration Not Litigation Ale.  Russian River and Avery Brewing Company both had a beer called Salvation.  Instead of suing each other over the naming rights, they decided to collaborate and make an amazing beer together.  I heard numerous stories of brewmasters visiting and touring other breweries to discuss the mechanics of brewing better beer with other brewmasters.

This project was a wonderful experience.  I am continuously impressed at how generous people are with their time.  Special thanks to Chris from Troegs Brewing Company and Sean from CR Goodman for taking the time to drink a beer with my Group and talk about Craft Beer.

Textbooks are:

• Not searchable. Instead of attempting to use indexes to look up terms in my book I just google them and usually end up on wikipedia.
• Heavy. My work bag contains a MacBook Air, one folder, a pen and a pencil.  It’s light as a feather and I love that.  My school bag weighs almost 30 lbs and requires daily reorganizing of textbooks and supplemental materials (all tons of paper of course).
• Hard to hold. Every morning I sit in this big, comfy chair in my living room in front of a fireplace drinking coffee and reading before work.  Because textbooks are so big and bulky I have to sit at the kitchen table all slumped over when reading course material.

The content in these textbooks matters to me and engages me, but the format is so awkward, bulky and archaic that I’m distracted and don’t enjoy the experience of  interacting with the material.  Now, where’s my highlighter?

Going through this experience has made me reflect on how I write (“written communication”) at work.  My job doesn’t require me to abide by any guidelines as an Investor Relations Officer or CFO might.  I write tons of emails, occasional internal blog posts, comment on internal posts, etc.  I am only judged on the effectiveness of my writing, nothing gramatical.  If I swear in an email and the impact is felt ultimately leading to improvement, then it’s been well written.

I am looking forward to seeing how my MBA professors respond to this style.  Will a looser, conversational tone be appreciated for easily communicating the point or will I be penalized for not following some set of outdated writing rules.  Maybe I’ll throw in a #hashtag for effect to test the boundaries.

For the past 2 years I’ve worked as a “Product Owner” for PR Newswire.  A Product Owner bridges Product Management and Software Development, understanding the business, customer and market as well as the code, deployments and infrastruture (see Agile).  I love this job and it’s perfect for me.  My 10 years as a Programmer gave me the foundation for building great software, however I felt weaknesses in my business knowledge, specifically as I work more and more with the corporate enterprise (budgets, financial statements, etc).

So, I’ve decided to get my MBA.

The Executive MBA program from the University of Colorado is right down the street from my office in downtown Denver, the class is full of experienced colleagues from a variety of industries and I’m really digging this so far.  The program meets one day a week, alternating Fri and Sat.  We take 2 classes at once, currently Leadership and Financial Accounting.

My observations after the first 2 weeks:

• I can now easily read and understand Financial Statements: 10k, 10q, 8k, Balance Sheet, Income Statement, Cash Flow and Shareholder’s Equity
• I spend every other day throughout the week with an Auditor, Bond Trader, Marketer and Product Manager, my Class Group for the next 2 years and my new best friends.  It’s a wonderfully new perspective and I’m enjoying sharing it with this group.
• CU is 5 years behind the technology curve.  I have heavy textbooks, lots of paper and everything is Powerpoint, jump drives and, no joke, overhead projectors (think: Jr High science class).  This has been a bummer given my current MacBook Air, global distributed team and cloud based tooling for every single aspect of my life.
• Spending 1 day a week thinking about business finance/accounting and leadership is incredibly refreshing and energizes me for my daily life at PR Newswire.  It’s like having an offsite once/week.
• 2 big resources for me already have been MBA Mondays and Finance Fridays

Several of my Business Heroes advised me against getting my MBA but gave me tons of support applying.  I really appreciate that and think about their opinions weekly.  I’ve loved comparing my MBA experience with their advice “F the MBA, if you really want to learn about business go work for a startup!”  I want them to know that in the past week I’ve cited TechStars, Do More Faster and the Boulder, NYC tech scene almost every time I’ve opened my mouth to say something about financing, executing or kicking ass in general, Thank you.

Back to studying!

A few weeks ago I attended the “Mastering Workflow” GTD seminar.  This was mostly review for me but the tactic of using “Agendas” really stuck.   In Things, there’s a “People” list that I have never leveraged before.  As life tasks crop up that I need to discuss with Sarah, I associate them with her in the Things and wait until our Life Dinner to discuss.  I also do this with my boss as we have a weekly video chat standing meeting to review anything outstanding.

Using Agendas is a great way to cut down on daily email and task switching while still feeling organized.

As I shop for curtains, read updates on the latest in car seat technology and scour color palettes for that perfect shade of blue, I am reminded how “Nesting” plays a serious role in the day to day life of the Agile Product Owner.  As a Product Owner myself, I am not writing the amazing code that drives our application, I am focused on keeping everything in motion and getting all the pieces just right.  As I see our baby room come together in just the right way and our app taking shape so beautifully, I can’t help but feel like a proud papa.

Now, if only I could get my wife to use Kanban.

This quick reflection just reminds me that building software is amazing.  It’s not writing up exhausting requirements that no one cares about, it’s not outsourcing all of your technology to a vendor, it’s not making stupid decisions that leads to wasting money and not shipping product.  Building software is about being creative, respecting the craft and the team and adapting quickly to a changing environment while relying on tried and true principles.  I can’t wait to see what shows up in the next “git pull”.

I use a program called RescueTime to analyze my productivity in conjunction with BusyCal.  I have tuned the software to run from 9a-5p only Mon-Thu.  I don’t like to analyze my Morning Think or nightly reading routines and work at home on Friday usually declining meetings.  A few weeks ago RescueTime told me that I was averaging 6hrs per day talking, on skype or in meetings.  No wonder I was struggling to keep up with my workload.

I decided to try an experiment to see if I could reduce the 15 or so meetings I had on my calendar for the upcoming week.  I reached out to Project Managers explaining what I was doing and asking to be removed from the meeting request for a few weeks.  I promised to rejoin if my name kept coming up in the meeting.  This worked and I have reduced some of my standing meetings freeing up some quality time to be productive.

Our our software development team we are using agile and have a scheduled retrospective at the end of each release (quarter).  It is important to physically block time for the team to analyze how they work together, pros and cons and ideas to improve efficiency.  I am finding this same concept is important to the quality of your personal productivity.  Do yourself a favor and conduct a calendar retrospective.

Do More Faster is divided into 7 Themes: Idea and Vision, People, Execution, Product, Fundraising, Legal and Structure and Work-Life Balance.  Within each Theme are several 1-3 page stories written by Entrepreneurs, VCs and other interesting people in the software, internet, product development, startup realm.  It’s a great format for the hyper caffeinated, ADHD, check twitter while your reading type of personality.

This book was fun for me to read because many contributors are familiar faces I either work with in some capacity or have seen around the flourishing Boulder/Denver tech community.

Chapters that blew me away and taught me something brand new:

• To 83(b) or not to 83(b), There is No Question – Matt Galligan
• Usage is like Oxygen for Ideas – Matt Mullenweg
• Karma Matters – Warren Katz
• Don’t Plan, Prototype – Greg Reinacker

Chapters that reinforced some of my favorite work related topics:

• Don’t Suck at E-mail – David Cohen
• Get Out from behind Your Computer – Seth Levine
• Be Specific – Brad Feld
• Get Feedback Early – Nate Abbott and Natty Zola

If you want motivation for anything you are doing I highly recommend Do More Faster.

We use Rally’s ALM product and the Kanban custom tab to manage our User Story development.  I have worked with 2 teams over the past few years and both I consider quite amazing and talented.  Ongoing debates about naming conventions for User Stories, the importance of Tasks, and who should be the Story Owner have never been resolved.  Our teams crank out great software, but always within a stressful environment.

As I was enjoying a nice bike commute into work last week I was listening to the GTD | Podcasts episode titled “The Do Lectures”.  Around minute 10:30 David Allen says that to clarify anything, you have to decide “What outcome are you committed to finish about this?”  I realized how similar GTD Projects and Agile User Stories really are.

• A GTD Project clarifies the outcome you want.
• An Agile User Story describes what the User wants to achieve.

Both GTD Projects and Agile User Stories use Tasks as a method of describing the work required for completion.  In both, Tasks probably need to come in some sort of order, will vary in their scope and may require different people’s resource.  Also in both, if Tasks can be defined it signals a complete understanding of the work to be done.  Granted, you may have missed something, gotten something wrong or encounter changes along the way, but at least you’re on the right track.

My experience in working with fellow Developers is that being asked to Task out a User Story is sometimes treated as some kind of insult or waste of time.  We joke a lot about a common Task name we use in Rally simply titled “do it”.  Again, the GTD project similarities are strong here.  The initial reaction is to keep things in your head and resist verbalizing the steps required to complete the work.  Instead, insist on breaking every User Story down into Tasks and agree that the first Task to be worked on or “Next Action” is the most important one.

By leveraging the GTD Projects similarities in your Agile team, hopefully everyone will be more efficient and less stressed!