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.
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.
This is the seventh in a series of posts about the individual speakers lined up for…
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 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!
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.
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.
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.
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.