For me the session on Agile Methodologies led my Desi McAdam of Hashrocket was one of the highlights of January’s She’s Geeky unconference. It was one of those occasions when I felt several disparate pieces of context clicking into place and starting to make sense.
|NOTE: This is part of a series based on my live tweets from At last weekend’s She’s Geeky unconference in Mountain View, CA.
My immediate need for understanding more about Agile development is that I’m helping to organize the new Reynolds Journalism Inst. News Collaboratory. The point of this effort, as Jason Kristufek recently wrote, is to be a “do tank,” not a think tank, for experimenting with new options for the news business.
That’s why we’re trying to engage in this community people with diverse types of “do” experience — technologists, librarians, entrepreneurs, financiers, advertising and marketing pros, etc. And, yes, journalists too. The point is to actually get people working together to try stuff and share the results, not just to talk about stuff.
The question then becomes: How do you get people to decide on which problems to solve or experiments to try, parse those out into doable chunks, move their efforts forward, and assess results? Rather than try to do this all on the fly, I thought it might be useful to borrow some ideas and practices from Agile development.
For context, here’s the Agile Manifesto, as well as an excerptWikipedia’s current article on Agile:
“Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.”
So with that context, here are my live tweets from this discussion (cleaned up a bit). Unless otherwise attributed, all points made here came from Desi McAdam…
Now in the Agile methodologies session, which I hope will help with RJI collaboratory.
There’s a difference between Agile development & utter chaos. But Agile can devolve into chaos.
Agile is a very rigid process. If you don’t stick to the process, things fall apart quickly.
Agile is an iterative process: earlier work gets outdated quickly. Cycles are smaller, iterative, to adapt to change as change happens.
Pair programming is more popular with females — more interactive, cooperative. Keeps you on track, out of rat holes.
In Agile, you have to be disciplined: Organizations and your pair partner must be disciplined. Very accountable.
Pair programming is a wonderful way to do knowledge transfer.
Pair programming improves code quality. If you’re coding and someone’s watching, you’re less likely to do something hacky.
Pair programming is more productive. People don’t generally like to interrupt working pairs. (Interesting!)
Agile also is about sustainable work pace: Don’t burn people out, get the most benefit from coders.
Some companies require some up-front planning, like wireframes or mockups, before throwing Agile development team on it. Do you have a good base?
Agile used in Spot.us development process. David Cohn came to us with wireframes. We started storycarding. Right off bat, we had to prioritize and think about what desired feature could go.
Storycard = definition of a chunk of work. Say what the business value is first. Get client to tell you, helps set priorities
Glitches with Agile: Lack of quality assurance (QA): Developers should be writing test code. Pivotal tracker (popular Agile project management tool) doesn’t address QA.
Rally, other tools do account for QA — but they’re bloated and slow and tedious to use. Simpler configurable tools needed.
Standup meetings: key part of Agile process. Can work in any organization. Very short meeting: everyone stands up, gives recent and current tasks, identifies obstacles.
Agile is hard to do in a distributed environment (workers not in same location). iChat, screen sharing helps. Good manager/developer communication is crucial.
Good Agile stories follow INVEST principles (from Extreme Programming, a related discipline): Independent (self-contained), Negotiable, Valuable, Estimable (you can guess how involved/big it might be), Small, Testable.
ME: I’m liking the story analogy of the Agile process. I think media people will be able to relate to that.
Negotiable = not defining the story in such rigid detail that it can’t be changed.
Desi recommends Liz Keogh as a great resource on thinking about Agile.
ME: The Agile session is incredibly valuable! Desi rocks!!! I needed exactly this info right now!
I’ll be sharing more thoughts on Agile later — but for now here are a couple of takeaways that struck me:
Storycarding reminds me of journalistic news judgment. The process of breaking a project down into tasks that meet invest criteria reminds me how journalists and editors decide which news and information warrant development into a story. Both involve assessing a situation and needs, and matching it with criteria. Both appear to be more like art than than science or rote procedure.
Applying Agile techniques to other fields (such as news and journalism) is itself an experiment that should be handled in clear storycard-like chunks. It may not work, and it certainly would be a culture shift. I think, for cultural reasons this is a strong reason to involve geeks, entrepreneurs, and others in this process — and to team them together with journalists to promote knowledge transfer.
…More thoughts later. But for now, what do you think? Please comment below.