I admit it, I’m a bit of a geek. OK, I am an Alpha Geek. And yes, I sometimes go with the slightly more computerized solution that others might. I just don’t get Agile’s fascination with sticking hundreds of pieces of paper on the wall, though. Agile teams need a mechanism to share knowledge about stories and tasks. They often do this by using whiteboards with sticky notes (so they can be moved) or cork boards with push pins and index cards. There are columns for the stages (waiting, in process, in QA, done done done) and rows for each story. This article shows an example of one.
I talked about it with an Agile coach friend of mine, Nancy Van Schooenderwoert of Lean Agile Partners, and she made a good point that the paper system makes the whole process easier to learn. She also pointed out that all software has limitations, and it’s important to start out with the index cards or sticky notes so you don’t get the impression that any limitations in the software are a limitation in the Agile practices. I get that. But once the team is passed that point, it’s time to use software-based collaborative tools. Why?
Read on…
I came across this blog post on the Developer Art blog on preserving and sharing project knowledge. I found both the articles and the comments insightful, offering several good suggestions for persisting and disseminating project knowledge.
This is a topic near and dear to my heart. Anyone who has worked with me on a project knows I take endless notes, and I have been saved by them many times. They can lead to information overload, but to me, it’s worth the risk. You can’t go back in time and take notes at a meeting that already happened any more than you can reshoot your vacation pictures once you’re back home and notice that they all have your thumb in them. I would rather record information and throw it away later if I don’t need it, than try to reconstruct an undocumented conversation after the fact. The act of recording the information also helps me remember it.
Read on…
Just a link to a nice article on the subject. I know we can be pretty hard to figure out, but geeks need love too 
Here’s the article on DZone, a technology publishing company that produces valuable content for software architects and developers worldwide.
As a Software Engineer, I normally think of Agile in terms of software development. As someone who has rolled out Agile practices at several companies, I also think of it in terms of how Agile software development affects the rest of the company. The last company I worked for (yes, I’m still looking for work!) implemented full Scrum, including pair programming, TDD (as in, insufficient code coverage had a direct effect on your bonus), retrospectives, standups, etc.
I came across an interesting blog post, The Smart Entrepreneur’s Guide to Finishing What You Started, on Scott Ginsberg‘s blog that suggests entrepreneurs learn lessons from Agile, too. Scott bills himself as “The Authority on Approachability”, but most of his blog posts seem to be aimed at high-level business and marketing people. He also claims to wear a nametag 24/7, with a tattoo of a nametag sufficing for certain occasions. Everyone needs a shtick, though, and this is what us geeks call “mostly harmless“.
This post proposes favoring action over inaction, moving at a sustainable rate, making sure you’re focused on the customer’s needs, limiting scope to enable completion of a phase/project, and [post="Done Means Done Done Done" text="making sure done means done done done"]. Sound familiar?
I also liked his post 6 Ways to Rally without Being Ready, reminding us that you’re never 100% ready, but that’s not actually required to start.
I am a Knowledge Geek. I like collecting knowledge, searching knowledge, and organizing knowledge. If you read my post on my recent cellphone research, you know what I mean. I take notes at most meetings and conference I go to. That often turns out to be very advantageous, especially on longer-term projects where it could be important to find out when a particular decision was made, by who, and why. I’ve always named the files staring with the group/project/company name, followed by a YYYYMMDD timestamp, and optionally a topic after that, so finding things isn’t too hard. The larger problem I started facing recently though, is I have been taking notes on multiple computers. I needed a way of making sure I had access to at least some of these notes when and where I need them.
Up until fairly recently, I had my server and my laptop. All notes were taken on the laptop (and backed up to external USB drive). Then I got an iPhone, and found note-taking on that quite practical (using QuickOffice). Then I got a netbook (Dell Mini 10), and started using that for meetings (after I got the netbook, I didn’t use the iPhone for note-taking very much). The end result was these meeting notes were not where I needed them. I needed a way of synchronizing these notes between computers.
Read on…
I am a Team Leader in Agile Bazaar, a member of both the Agile Alliance and the ACM. We have two events coming up in a few days. Please go to Agile Bazaar for more information on either event.
Nanette Brown: Agile and Architecture: Crossing the Great Divide
May 6, 2010 6:00 pm – 9:00 pm at the IBM Innovation Center, 404 Wyman Street, North Entrance, Waltham, MA
Agile development and software architecture are frequently seen as two divergent schools of thought or camps. Agile developers often refer to architecture as Big Design Upfront (BDUF) and may regard the architects major output as merely shelf-ware. Proponents of architecture-centric software development may see Agilists as undisciplined or short-sighted, engaged in endless rounds of refactoring which architectural foresight could have forestalled.
In reality, Agile development and software architecture practices are complementary. Focused attention on architectural concerns becomes critical as Agile development scales-up to handle larger and more complex systems. Agile developments focus on customer value, rapid feedback and response to change can provide practices that assist Architects in dealing with ever more volatile environments and increasingly compressed delivery cycles.
In this presentation, we will take a journey to each camp to dispel misconceptions and discuss how Agilists and Architects can learn from and benefit each other.
Deep Agile 2010: Empowering Teams with Agile Games
May 15-16, 2010 at Microsoft New England Research & Development Center, One Memorial Drive, Cambridge, MA 02142
Agile development teams are like emergency response teams – they need to be ready to act quickly to new challenges and changing competition.
At the Deep Agile 2010: Empowering Teams with Agile Games seminar, you will experience techniques that teach agile teams how to work together effectively and adapt to changing conditions.
I say “experience” because, rather than hearing lectures, you will be learning actively through observation and situational experiences, led by professional coaches and engaged facilitators.
The seminar includes structured sessions along three tracks: games to learn, games to change, and games to do work. You can move between tracks to select the blend of exercises that best suits your needs. Sessions range from introductory Agile concepts, to the theory of constraints (via the “bottleneck” game), to innovative topics such as using the art of improvisation to facilitate teamwork and exploring emergent design.
The second day will feature an “Open Space” meeting session, in which participants decide the agenda, then meet in breakout groups to explore the topics of greatest interest and share ideas for solutions. Open Space sessions are exceptionally stimulating and productive, because the discussions focus on the questions, problems and successes of you and your peers (See: the Agile Bazaar website for more information).
Of course the only way to gain all these advantages is to attend Deep Agile 2010: Empowering Teams with Agile Games in Cambridge, MA on May 15-16, so register today!
For more information and to register please go to http://games.agilebazaar.org/.