Here are a few thoughts on last night’s NYC Agile / Lean Practitioners Meetup. The topic was certainly relevant to some of the work I do and was helpful to re-iterate some best practices I need to employ and keep in mind for my project work.
I work with teams to build prototype applications (typically for iPad) aimed to inspire clients and showcase how we take industry/niche insights and apply those to a client need/problem by building a functional prototype.
In order to do this, we work to understand what the client problem is, identify what type of tool may work best (dashboard, calculator, workflow, diagnostic…), rapidly iterate on a design and develop the application - All in the timespan of 1-4 weeks, depending on the level of app robustness the client may require. To accomplish all of this, our teams work in an agile environment.
Agile is adaptive and should be used to fit the type of project employed. With that said, teams can make agile work in a multitude of ways. My projects, due to very demanding time-frames, require an agile recipe where we essentially scale down the general structure of the agile framework to fit our needs.
Textbook, blue sky agile emphasizes the need for co-location for many very good, obvious reasons. BUT, the reality of many project landscapes is that for very good and obvious reasons (I’m looking at you, “cost.”), co-location simply isn’t feasible.
There are some pronounced challenges that offset the money that teams may face by hiring remote team members. A central challenge brought up during the Meetup which resonates the most with me is communication.
Communication is key to any project and can be especially challenging when teams work remotely. The role communication plays on agile projects is even more noteworthy as the iterative nature of the products we create relies on constant feedback. Taken a step further, the short timelines I have building prototypes means that we must communicate that much more frequently and smartly. Something I have found is that inadequate communication can lead to assumptions. Assumptions are bad. Assumptions de-rail projects.
It’s important to keep in mind the barriers to communication while working in an non-co-located agile environment. Such barriers can be technology (conference call, bad cell reception, slow loading times for a screenshare, poor connectivity…), language (english as non-native language, culture), absence of face-to-face time… From my experience, silence and the absence of questions tells me that there is a high probability that people are making assumptions or simply are not following along. There isn’t room for this to happen on rapid, highly technical and visual projects which require constant feedback and iteration.
Keeping in mind what communication barriers mean to an agile environment, and finding the right tools to alleviate some of these impediments, go a long way.