Rooosterboys Agile observations

At work today, we had a series of case studies delivered on UX and agile. The premise of the morning was to discover whether UX people could work within the dynamic agile team environment. Lots of good stuff in there, but one thing really stood out. Tref, one of our UX team and an Aconex stalwart offered this gem. I'm going to paraphrase him here as I cant quite remember word for word: "To really work well within a small team, one needs to be collaborative, to be collaborative, one needs to deal with and actually like constant interruptions." This is so true, in small collaborative teams, interruptions are a constant, as you share and seek advice from team mates. Of course a key part of skillus interruptus was knowing when, and how to interrupt others. The ability to switch focus but stay calm is tricky, some people hate it and I've seen them crack under just this pressure. Retro notes are littered with "Constant Interruptions" in the "what didn't w

One of the teams I work in is a new product development team. Up until recently we have been working on a minimum viable product feature set. We work in 2 week sprints and at the end of each sprint we did a demo and deployment to a demo environment. We got very used to having this release bus style process and planned our sprints accordingly, what can we release in 2 weeks. However, recently we went 'live' to a limited Beta release and the dynamic changed. We had our minimum feature set being used by customers, and they were giving us daily feedback. There were features we could get them in 2 days development but hadnt really visualised our information so that we could see the Tree's for the forest. In an hours discussion with my accomplice Yoram, we came up with a colourful, yet simple way of visualising all the little featuresets and prioritising them. People do variations of this, hell they've probably already done what we do, but I kinda like itso I thought I'd