Mathjax javascript librry setup

Adopting Personal KanBan

  • Updated 24, Sept, 2013

When I was working as a full time employee, my days were both busy and highly structured. I used the regular array of task/time management tools, anchored by Microsoft Outlook email and calendars, (Outlook and Exchange were “standard issue” where I worked). For our projects we used Scrum, and Atlassian Jira, especially “Jira Agile” and the RapidBoards. I use Things for my To-Do lists (Which I still think is a great tool, BTW). While my colleagues thought I was highly organized and productive, I generally felt overwhelmed and stressed, drowning in the “busy-ness” of meetings and to-do lists, and that I could have been getting a lot more value for my time spent. I’m sure you know the feeling.

Now that I’m on my own, my time is much less structured… A lot of my time goes into professional and business development and networking. I’m naturally inquisitive, and I love to learn. If I am not careful, the notes, ideas, and half-read books, pile up. In KanBan terms I let my Work In Progress (WIP) get way too high.

So I decided to “practice what I preach”, and adopt Personal KanBan. While I have many years experience with Scrum and various forms of incremental and iterative development, my experience with KanBan is very limited, so its also an opportunity to learn.

I got a copy of the Personal KanBan Book by Jim Benson and Tonianne DeMaria Barry. Its an excellent introduction to KanBan and Personal KanBan. Its a fast, fun read, very engaging, with clear explanations of why so much of our traditional thinking about time, task, and project management for any kind of knowledge work is deeply flawed.

Then I set up my initial Personal KanBan Board. I share a small home office with my wife, who flatly refused to have a big white-board cluttering up the space, so I went with KanBan Flow, an one-line Board. Its working great for me… So far it has all the features I need. I’m using the free version, but I plan to upgrade to the $5/month premium version, just to support them. I think the most popular tool is Trello. I’ve tried Trello and like it a lot. The free version has more features than KanbanFlow, and Trello is stronger on the social/multi-person side. However there are some features in KanbanFlow, like full coloring of the cards, that I prefer over Trello. But the two products are quite similar, and you should try both before you make a decision. KanBan Tool also looks good, and has a free version, but I have not tried it.

Read on for more details….

We Value Discipline Over Bureaucracy

UPDATED….

A question was asked in the LinkedIn Agile Project Management group “If you were to be given an opportunity to add one more line to the Agile Manifesto, what would it be?”

My answer is: “We value discipline over bureaucracy

I have a saying: “You need to know the difference between discipline and bureaucracy”. A critical success factor in Lean and Agile is maintaining a high degree of discipline, while actively eliminating bureaucracy through continuous improvement.

Scott Ambler’s Writings on Disciplined Agile

In an Agile CMMMI LinkedIn group discussion on “How disciplined is your Agile implementation?”, Scott Ambler pointed out he had written an article on “Discipline vs Bureaucracy” in Agile several years ago:

Scott describes “Discipline over Bureaucracy” far better than I could… it’s well worth reading his material on the topic.

Also Scott has a web site Disciplined Agile Delivery dedicated to improving discipline in Agile development practices. The web site is a companion to Scott’s book of the same name Disciplined Agile Delivery

Scott has a written a wealth of material on the importance of discipline in Agile development - his book and web site are a great resource on Discipline in Agile development.

Read on for more details….

The True Genius of Brett Victor

I had a math prof in university that quipped:

True genius is not inventing a new mathematical theorm or discovering a new law a physics, these are things that very few people attempt. True genius is coming up with a new way of cheating at cards, or a new sexual position that was not known to the ancient greeks. True genius is in making discoveries in endevours that millions of people do every day.

By this definition the designer and UX expert Brett Victor is a true genius. If you have an interest in user experience (UX) design, or an interest in software development environments, you really owe it to yourself to watch Brett’s Inventing on Principle talk, where he discusses his principle:

“Creators Need an Immediate Connection to What They are Creating”

In the talk, Brett shows some truly brilliant ways to allow a software developer to have an immediate connection to the software they are writing. IMHO the ideas are “True Genius” because they offer radicilly new ways to interact with software while its being written. When you see the ideas, they seem “obvious”. Yet with millions of people involved in software development and using IDEs, Brett’s ideas are fresh and creative and take IDEs in an entirely new direction.

After you’ve watched the talk, head over to Brett’s web site Worry Dream for more creative brilliance.

Agile Coach Camp Canada 2013

I attended Agile Coach Camp Canada #ACCCA13 in Toronto on June 14-16. About a hundred people attended. Besides the folks from the Agile coaching and consultanting community, there were a healthy number of software developers, development managers, and others which really enriched the sessions. There was even an architect, Paul Whelan (who designs buildings, not software) who hosted a very inciteful session, and added a great deal to the Camp discussions. (See Jason Little’s blog post for details on Paul’s session)

The Camp was organizaed using Open Spaces Technology, and it worked extremely well. (Which is to be expected, given all the Agile practiioners!)

You can check out all the tweets, videos, and pics on epilogger

I kept notes of the sessions I attended, as well as references to resources like books and practices/frameworks that were discussed during the camp. I’ve created an “open notebook” from my notes, which you can find at: Agile Coach Camp Canada 2013 notes

The Culture of Code Quality

Crafting quality is as much about culture as it is about process. No amount of process or testing can create a quality product after the fact. In the end, quality has to be designed and built in, from the start, by individual workers. The Japanese automobile manufacturers figured this out decades ago. The S/W development industry learned this about 20 years ago. The software practices and tools to support this notion have been readily available “for free” for a decade. Yet we persist in not take advantage of the tools and practices at our disposal.

There are many books on this subject, but two in particular come to mind.

“How Google Tests Software”, James A. Whittaker; Jason Arbon; Jeff Carollo, Addison-Wesley Professional, 2012. (Other links to information include this InfoQ review and James Whittaker’s blog posts which summarize the main points of the book.

You may not agree with every specific technique and tool in this book, but the culture for creating high quality code at Google is very compelling. The first page of the book states:

Quality is not equal to test. Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other“.

Google does not have a Q/A or testing department. They have an organization with the title of “Engineering Productivity”. I like this a lot, because high quality software development shops have been shown to develop products faster and a lower cost than low quality shops. High quality software quality means higher productivity.

What Is ‘Blue Collar Programming’?

I’m stealing the term from “big” Dave Thomas, who used it over 30 years ago. For me it means the “meat and potatoes” software development, whether it’s product development or custom IT work, embedded systems or applications, server or client. The key characteristics are:

  • It’s done for commercial or business purposes (there are business stakeholders to really care about the outcome)
  • It’s done by ordinary developers and teams… in general the teams will have a range of skills and experience. This includes some junior or mediocre staff.
  • It’s project-based… it has time, content, and resource constraints.

This is “development in the trenches”. In fact “in the trenches” is a good analogy. You can learn a lot about S/W development by drawing analogies with other disciplines. I’d highly recommend reading the book Warfighting - The US Marine Book of Strategy. All you need to do is replace the term “war” with S/W Development Project, and you can learn a lot. I recognized in the book what I refer to as the “4 Fs”:

  • Friction: In war, and in S/W development projects, everything is much harder than it should be. Things that are easy in a small or practice setting are slower and more difficult in the heat of battle.
  • Fog: The information that comes to the leaders, whether S/W development managers or military officers, is delayed, imperfect, sometimes conflicting, and can’t be completely trusted. The higher up chain of command you go the more difficult it is to get accurate, timely data of the situation on the ground.
  • Fluidity: The best-laid battle plans often do not survive contact with the enemy. The situation evolves and changes, and your plans have to change to align with the new reality. (waterfall development is particularly bad at dealing with fluidity)
  • Fatigue: Troops can only sustain a full offensive for so long. Humans get tired, supplies runs out, equipment breaks down. Assuming that your staff and resources can sustain a “110%” effort on an on-going basis will only bring on eventual defeat.