Leadership of a Team: Progress and Backlogs

I’ve been checking out a number of teams and what their workloads look like. I’ve of course worked on more than few with completely disparate practices and policies. Some where really good at making great progress and others were absolutely horrendous. I’d argue one team actually went backwards in progress more than a few times. Suffice it to say, I’ve seen a whole lot of the bad and a fair amount of amazing teams. I’ve been fortunate in doing so as it really helps to have a solid perspective in both arenas.

To summarize, it’s nice to know when the ship is sinking and when the ship is sailing full steam toward the destination! Continue reading “Leadership of a Team: Progress and Backlogs”

Oh Snap, Got That Kanban w/ Github Integration!!

A recent issue came up on the team yesterday. We needed to increase the visibility of what we’re working on without dragging ourselves into more one on one or team communication. As anyone that has spent more than 5 minutes with a team knows, meetings kill productivity and morale, so the idea to get a kanban board going was brought up.

That raised the second issue of a remotely distributed team. We can’t have a real kanban board and the literal presence that it provides by being physical. The next best thing though is to have a virtual kanban board that integrates well into our workflow. With integration we get to look at it regularly and work around it to communicate where and what we’re working on without it becoming a major interruption.

That left the need for a kanban board with github integration. I thought to myself, “this exists right?” I checked the ole’ Internet tubes and sure enough someone had posed the question on StackOverflow! The question read, “What’s the best kanban tool to use with github?” Unfortunately there wasn’t a whole lot of answers or information following that up. However, the one answer that did exist provided an interesting solution.


The simple one page site is located here: http://huboard.com/ and on Github here: https://github.com/rauhryan/huboard. This describes the product a bit, and Ryan Rauh(@rauhryan) has a blog entry on Los Techies titled “Huboard – Github issues made Awesome“. You can also follow Huboard on Twitter @Huboard.

(Screenshots courtesy of Ryan’s Blog Entry, click any of them to go to his blog entry)



Huboard #2

Huboard #2

Where I’m At…

At this point I’m just checking it out, forking the code, and seeing how it works. This tool looks very promising however and fits into the workflow in an extremely seamless way!

Ward Cunningham Presenting “Missing from the Beginning: The Federation of Wikis” @ #nodepdx

This is the seventh in a series of posts about the individual speakers lined up for…

Ward Cunningham Presenting at CyborgCamp. Photo: Mark Coleman http://markcolemanphoto.com/

Ward Cunningham Presenting at CyborgCamp. Photo: Mark Coleman http://markcolemanphoto.com/

I’m extremely happy to introduce Ward Cunningham. He’ll be presenting “Missing From the Beginning: The Federation of Wikis” at NodePDX. Here’s a description of what he’ll be presenting on in his words.

Our new wiki innovates three ways. It shares through federation, composes by refactoring and wraps data with visualization.

The Smallest Federated Wiki project wants to be small in the “easy to learn powerful ideas” version of small. It wants to be a wiki so that strangers can meet and create works of value together. And it wants to be federated so that the burden of maintaining long-lasting content is shared among those who care.

Ward's Art Image, Click to Checkout His Site

Ward's Art Image, Click to Checkout His Site

Ward has a list of awesome insights and projects he’s worked on, including a little agile manifesto contribution. 😉  Here’s a short bio of Ward,

Ward Cunningham currently serves in a one-year appointment as Nike’s open-data fellow. He has been CTO at CitizenGlobal, a growth company enabling the co-creation of media. Ward co-founded the consultancy, Cunningham & Cunningham, Inc. He has served as CTO of AboutUs, a Director of the Eclipse Foundation, an Architect in Microsoft’s Patterns & Practices Group, the Director of R&D at Wyatt Software and as Principle Engineer in the Tektronix Computer Research Laboratory.

Ward is well known for his contributions to the developing practice of object-oriented programming, the variation called Extreme Programming, and the communities supported by his WikiWikiWeb. Ward hosts the AgileManifesto.org. He is a founder of the Hillside Group and there created the Pattern Languages of Programs conferences which continues to be held all over the word.

If you’d like to come and check out Ward’s Presentation and the other kick ass presentations lined up, get involved in some coding, hear what Node.js is all about, or just hang out please RSVP and get the event on your calendar! Besides, what better reason to come visit the amazing city of Portland, Oregon than to come hack some node.js and chill for the weekend!

Urban Lean Agile Tech Breakfast Meetup, Be There This Wednesday!

Are you hard core into technology and software development like Node.js, JavaScript, Ruby, Rails, .NET, Java, Clojure and more?

Do you like the ideas behind the agile manifesto, lean startup, kanban, and thinking outside of the box?

Are you digging that ASP.NET MVC Framework or waiting for the next ALT.NET meetup?

Loving that ease of Ruby on Rails to wow your user base with ease, to implement with Sinatra those clean JavaScript & jQuery enabled UX for your clients?

Want to talk shop, eat some grub, have a beverage, and get a nerd kick start in the morning?

In that case meet us for Urban Lean Agile Tech Breakfast Meetup at Mod Pizza @ 1302 6th Avenue @ 8 am on Wednesday, August 3rd.

Iteration End, Velocity++, Chart Awesomeness, Contribute Back Plz K Thx!

Here’s a few charts and such from the end of an iteration that the team I’m on just wrapped.  I’d love to see any TFS charts of this nature or other solutions in JIRA, TeamCity, or whatever is used.  Anyone else out there want to get a blog post up about it, I’ll add a link at the end of my entry here.

Lots of Tests, Good Continuous Integration Build

Lots of Tests, Good Continuous Integration Build

Gotta have solid test coverage for any reasonable expectation of maintenance.  When I mean tests, I’m talking about properly abstracted, mocked, stubbed, faked, or otherwise built so as they don’t depend on all sorts of nonsensical external dependencies like file systems, database, or other things.

Code Coverage, in general keeps an upward trend!

Code Coverage, in general keeps an upward trend!

100% is a little fanatical, but an upward trend after the beginning of a project and the initial work beginning is one of the best things to see.  Code coverage with tests means you’ll be able to get all sorts of goodies:  maintainable code, non-increasing tech debt, faster refactors, etc.

The Few Fixes Needed, Get Fixed Pretty Quick!

The Few Fixes Needed, Get Fixed Pretty Quick!

Unit test fixes.  Should be quick, should be furiously done, and shouldn’t take more than about an hour on the infrequent times they occur at all.

Unit Test Coverage Up...

Unit Test Coverage Up...

Increasing Count

Increasing Count

…and of course, the burn down.


Burn Down

Burn Down

Don’t Give me Rework Refusal!

Over the last few weeks I’ve seen a few comments regarding rework. One of those comments was Julie Booth’s (@uxsuccess) comment on Twitter regarding rework,

“Do not fear rework!!”

That kicked me off with a response of,

“Do not fear rework!! /via @uxsuccess so true, plz plz don’t cower before rework!!! :). Listen to @uxsuccess!

Then just recently I stumbled onto a book I’ve been meaning to read called Rework.  This book is written by the crew at 37signals.  This company is best known for SaaS Offerings Basecamp, Highrise, Campfire, and Backpack.  All of them created with high quality, solid UX (User eXperience), probably great code quality, maintainability, and the list of goodness goes on.  In addition, the other thing that 37signals is widely known for is their efforts around Ruby on Rails (created by DHH @dhh).

Rework is a fundamental requirement to actually getting an elegant solution.  It might seem chaotic or disconnected at first, but it quickly becomes a vastly superior way of doing things instead of the “Do it once, do it right the first time” nonsense.  Things need to change, doing things right the first time is almost impossible anyway.  That is why you practice playing guitar before becoming a virtuoso, you learn to hammer before becoming a carpenter, you sketch and draw before becoming an architect, and the list goes on.

Don’t expect perfection, expect creation.  That’s what I’d say.  If you can’t tell, I agree with the Ruby on Rails mindset, with a lot of what DHH/@dhh writes, and I especially respect what 37signals has accomplished and the revolutionary business ideas in the book Rework.

These types of ideas – simple rework and the open minded approach to rework – makes a business faster, more agile, and responsive to their customers’ needs.  These ideas, these mentalities are what have created great companies in the past and will build great companies in the future.  The companies that suffer the traditional approaches and mindsets are at significant risk of being eliminated from the market altogether.

There are many others out there also, that push these types of ideas and mentalities around rework, refactoring, and agile practices.  If you haven’t checked out who 37signals is, the book Rework, or Ruby on Rails you should stop whatever you’re doing and find out about this company and its products.  Especially find out how their products were built with business agility in mind, with a strong dose of Agile ideals.  With that I bid adieu for the day.  Happy coding, and don’t fear the rework.

It Brought a Tear to My Eye, Agile Ideals Rock!

I’ve been leading a software development project for a little over a month, one of my team members and I have been communicating back and forth steadily.  Via IM or verbally, e-mail or however we need to.  We’re having a good time figuring out things as they come and getting things done in a very Agile way.  To lay it out as the manifesto is written;

We keep ourselves and interactions over process and tools.  We make sure to have working software on almost every single build that could literally be deployed, while forgoing the currently unnecessary documentation.  We collaborate constantly with the customer representative and don’t worry every minute about the contract negotiation.  Response to change is almost instant, as it comes along almost every day.

As we’re hustling along getting a complete vertical implementation of a project together this coworker comes to me and states, “It is great to work on a project with someone that knows what they’re doing, and not sent off in a corner to read documentation books on what was done in the past!”  That statement made me so happy.  This is one of the major reasons I advocate Agile!

Agile helps team members get bought into the project.  The team gets involved in ways that other processes just don’t allow.  The team feels enabled, empowered, or whatever one may call it to actually get the job done!  Being Agile isn’t about process or tasks or work items, being Agile is a mindset, is about being interested and involved in what you’re doing for your project.

After a dirge of conversations and some frustrating efforts recently, this is the type of thing that leaves those negatives in the dust.  This is the type of statement and motivation, when I see it, that makes me love what I do and love to come into the office each day!

So anyway, I had to make this post.  Because today, even though I thought it would be a slightly miserable day.  That one statement redeemed it and my day is now rocking!