- Consulting / Coaching
- Jeff’s Blog
There are at least a hundred for-profit or open source tools to help you track your agile / Scrum project. Here is a list, from 2013, of 70 such tools.
If you’ve read Agile in a Flash or some of my blog entries, you’d quickly gather that I’m not a fan of most software-based project tracking tools–you’re better off using whiteboards and/or physical card walls. Introduce a software tool only if you must. And if your need is solely for reporting up to management (hmmm), remember that it’s the SM’s/project manager’s job to capture, consolidate, and distribute such information. Please don’t involve the rest of the team in this.
The tools I seek instead are those that help our team communicate and collaborate better. We’re 15+ years into “agile;” I’d hoped for far more collaboration tools than exist today. (What’s my excuse for not building any of it?)
IDEA, Eclipse, and even VisualStudio (with Resharper added) are powerful. To what extent do these tools directly support TDD? IDEA, Eclipse, and VS all support unit testing out of the box, but that scratches only the surface. While plugins exist for many of these interests, I’d like to see direct support for things like:
With TDD, tests and production code are inexorably linked. It would be nice to work in an IDE that supported TDD as the primary workflow for building software.
Pairing will never supplant loner development. But it’s still a preferred way of working for many developers, including those distributed geographically.
If we’re pairing and you’re sharing your machine and IDE, I’m stuck with your horrifying choices for keymaps (I need my vim!), colors, font, and font size. One or both of us must make concessions to the most-comfortable setup we would choose. How sad.
The problem of disconcerting configs would be reasonably easily solved if the major IDEs supported a universal config-switching scheme. Sets of profiles (one profile per IDE, I suppose) would be stored somewhere accessible via http. The first time I sit on your machine, I’d enter my profile-set location. The IDE would provide a universal hotkey that toggles between active profiles (right now, you would typically need to go through one or more Preferences/Settings pages to switch out all the preferences). My turn to pair? I press the toggle hotkey, and my preferred setup is loaded..
Another focus would include supporting accessibility considerations for pairs. Some folks need a considerably large font, for example. A pair-friendly IDE would provide the ability to easily sport multiple views across multiple monitors.
Using multiple machines might ultimately be a better world than my shared machine ideas above, even if I’m physically sitting next to you.
Screen-shared programming sessions usually suffer latency issues, particularly for the remote pair. If you’re a VIM or Emacs weenie, however, you can run an effective pairing session using tmux/tmate or screen. The character-mode interaction makes it almost as good as being there–particularly when coupled with cameras, quality audio, and a screen share so that you can see the UI interactions on the host machine. This is my preferred remote-pairing setup, but I admit that there are some great things I lose that IDEs like IDEA can provide.
Atom also supports a plugin called Motepair that “enables remote pair programming using Github’s editor.”
Subscription-based cloud IDEs like Cloud9, Codeanywhere (which has a free version), and Codenvy are an option, but for now, most of us would probably prefer to stick with our IDEA or VisualStudio or Eclipse. (And I’m resisting paying for yet another subscription…) Having not used these, I’m not sure how truly collaborative they are. Your experiences are welcome in the comments!
The subscription-based Floobits takes things one step further, offering the premise of allowing clients to use whatever IDE they choose… as long as it’s Emacs, IDEA, Neovim, Sublime Text, or Atom (no Eclipse or Visual Studio yet). I’ve not tried it, but it sounds fantastic. Koding appears to be another tool with a similar model.
Other attempts have been made to create remote pairing plugins for specific IDEs. I remember XPairtise, an Eclipse plugin, which was file-based (it synced at the file system level) and had no end of problems. Now there’s SAROS, a still-active open source initiative.
There’s little worse than watching someone struggle through typing story data into a tool like Rally. The tool often requires lots of clicking about, which can create a distraction for the rest of the team in the room.
In contrast, I’ve found simple virtual card wall solutions like Trello to be fantastic, however. I’ve run and been a party to iteration planning, retrospectives, and other distributed (and non-distributed!) meetings where Trello was the tool of choice. It’s highly tactile and responsive; all parties see changes as they occur. With plugins, things like dot-voting on cards promote Trello to a great general purpose tool for managing and tracking just about any collaborative meeting. Worst case is that you need to export the information to sync up another tool elsewhere.
Ultimately: I wish all applications supported true real-time collaboration. Google Docs is a great example of a tool that effectively supports live editing by multiple people.
If we really believe in agile, let’s insist that the tools we use and build all support collaborative capabilities, and not just as an afterthought.
Should we ever “give up” on someone? Agile or not, development or normal life, people are always the biggest challenge. Difficult people are obvious targets, since by definition they do things that most people don’t want to deal with on a day-to-day basis. But can we help them become less difficult?
Just what is a difficult person? I actually welcome a healthy level of skepticism. If you’re not skeptical about things, you’re probably not pushing boundaries as often as you should. I can help a skeptical but open-minded person by answering their questions and guiding them through necessary self-discovery and acceptance of a new idea. With some people, however, skepticism instead grows into a potentially unhealthy attitude, whereby they resist differing ideas at all costs. Stated from their point of view, “I’m right and you’re wrong.”
Sure, if you’re absolutely right in your reasons to avoid something, it’s an appropriate response. But that’s almost never the case, particularly when we’re talking about something like TDD or automated testing. People have achieved good levels of success with diametrically opposed ideas, strategies, and tactics. What that means is that someone who wants to argue every last point against their presumed opposition is being close-minded. Sometimes they cross over the boundary into pure contrarian–even if you agree with them on a point, they still find a way to argue against it!
I felt regret most of this weekend about a post I made to one of the agile lists last week. After an exchange of a few nit-picky posts, I stated that I wasn’t going to waste my time any more. It was soon apparent that the other poster was going to shred virtually every line I wrote, never mind trying to find any common ground. Now I don’t feel bad at all–blowing hard at brick walls is a huge waste of time.
Doling stories out to individual developers not only makes for more boring iteration planning meetings, but it also impacts the system’s overall quality.
One of the most overlooked practices in software development today is review. If you don’t pair, then you really must find a way to consistently review work product. Unfortunately, most companies pay the cost of not doing this: code that is increasingly more difficult to maintain, and solutions that are questionable at best.
Insisting that a team finish a story every couple of days or fewer will often mean that two or more developers must collaborate on a story. In order to collaborate, they must agree on some part of the design and a plan to implement it. The developers will need to continue talking as the implementation progresses. That’s a good thing. Much of the resulting design won’t be one developer’s wonderfully clever or woefully inadequate brainchild.
Such collaboration brings a bunch of siloed developers one step closer to being a true team. Initially, velocity will decrease a bit: developers will have to learn how to talk to each other and coordinate things. Developers will learn more about other parts of the system, increasing their value to the project as well as their personal worth. It’s not quite as good as pairing, but it does go to the heart of agile.
I currently work as part of an agile mentoring team in a large organization. Up until recently, we shared a project room. At any given point in time, there might have been one of four to six or seven team members (including a manager), plus one to three people that we were working with. On average there were four people in the room at any given time.
Up until this experience, I had always had positive sentiments about open workspaces and team rooms. In this current setting, I did benefit significantly from getting to converse frequently with all of the other people in the room. I learned things I probably would never have learned otherwise. And, I had a grand old social time.
But I also found that I wasn’t getting much work done when I had things I need to concentrate on. It seemed like I could be guaranteed a distraction at least every five minutes. Either someone was asking a question, or I was overhearing something that I felt compelled to respond to. It got to the point where if I had to find a couple hours to work on something (such as preparing training material), I ended up leaving the open workspace to find somewhere quiet.
The problem wasn’t the open workspace, it was the fact that none of us were really working on the same thing. The other mentors were usually working on a different project than I was. And my manager, well, you know how managers are, there’s always something they want you to pay attention to right away.
Escaping the room on occasion was an adequate solution, but the better solution ended up being pairing. I noted that as soon as I found a partner to help build a solution, or someone that I was mentoring, the distractions disappeared. I surmise two reasons: first, as a pair we were focusing on a problem. That meant I was no longer listening to any external conversations. Second, people are more reluctant to interrupt two people that they see obviously engaged in a conversation or task.
As I’ve paired more and have worked with teams employing pairing, I’ve grown a long list of benefits that I’ve seen accrue from the practice. My experience here adds a new bullet item: pairing minimizes distractions.