The Power of a Physical Board

Flash back to my first day at Übermind. I had been told they were agile. They talked the agile talk in the interview. I walk into the office and notice that there isn't one single board in the entire place. None. In fact, very few information radiators in general.


So I asked around, "why?" Well, I vaguely remember being told that they had tried a physical board on a project perhaps once or twice. But it never took. So I changed that by showing the office the power of the board. A great board with tons of information that is well-maintained is irresistible. So check out how many physical boards are in the office after 8 months or so...

A personal schedule/Kanban board.

A department-specific board for UX.

A department-specific board for QA. Note how the lanes migrate right over onto the window.

Another QA-specific board.

The device lab board.

A Kanban board for a conference we are spinning up.

A personal board used for mentoring/teaching.

A personal Kanban board in the lower right and a project rolling board.

IT Kanban.

Webservices board.

A simple Kanban board for an Agile Mastery Class I am leading.

A board for Marketing. Marketing.

The board that started it all. We had to move it so it was reset a few weeks ago.

Another internal project board.

My work here is done.

Well, not really...

"Agile Experience Design" by Ratcliffe & McNeill

The UX Director here at Deloitte | Übermind recently loaned me a book, "Agile Experience Design" by Ratcliffe & McNeill. I was intrigued because I haven't really seen any great references on Design and/or UX in agile projects. And here at Deloitte | Übermind we do tons of UX and Design, more here than anywhere I've ever seen. It shows in our awesome looking and mega-usable mobile apps.


Anyways, I read the book cover-to-cover at a record pace. It had all the good agile stuff, iterations, retrospectives, etc. That kinda content is pretty much geared towards the Design/UX engineer who has minimal agile experience. So that content was good. Simple, to-the-point, etc. I only took issue with 2 minor points; but those points aren't about basic values or principles. They were more like "I wouldn't do it that way" points. For example, one section's illustration showed a daily standup at 5:30 PM. Weird. But minor.


The stuff I really loved and got into was how to integrate UX and/or Design into an agile process. As an experienced agilist, that's where the money in the book was for me. I loved that stuff. It's the first reference I've seen that covers this topic area really well.


So from my perspective, if you are involved in agile that has lots of UX and Design, this book is a must-read. 'nuff said.

Awesome bookness

Lego City Scrum Workshop

I recently e-mailed my office e-mail list with links to a variety of Scrum training workshops, including Lego City. Well, it so happens Adam McLain, an iOS developer who also collects Legos, got very interested. He approached me about putting together a Scrum training workshop specifically based around the Lego City model. We then drafted Cyndy Eng-Dinsel, a QA agilist here, and we got started putting it together!


First off, we Googled it of course. We based our workshop on the model at http://www.agile42.com/training/scrum-lego-city/. But we made some important changes:

1. We updated the stories to reflect our city attributes here in Seattle. For example, one of the stories was to create a ferry and an associated dock. We ended up creating about 16 new stories.
2. We extended the actual task execution time in sprints from 5 minutes to 10 minutes. This gave more time for actual Lego play!
3. We created 4 new "event" cards. For example, 1 of the events was about 2 team members getting sick with the flu and being out for 5 minutes.

But in general we pretty much followed the guidelines as defined by agile42. All told, we did 4 sprints and the entire workshop took about 3.5 hours, including a general retrospective/discussion at the end. Overall, I think it was a smashing success! We are probably gonna end up doing it again. Check out these sweet pics:

Are these my co-workers actually working hard here? I guess all projects should involve Legos...

The finished metropolis. Awesome.

The Lego City crew. What what!

Thanks go to agile42, Adam for kicking this off, Cyndy for facilitating, and to the crew above for participating.

The Team Knows the Answer

I think every Scrum Master out there will agree that sometimes you encounter a situation or scenario that you don't know the answer to. Shocking! Here's the thing - it's OK not to know the answer.


In a recent sprint planning meeting we encountered a situation where the team literally ground to a halt during estimation. There was a dead silence as I searched my mental data bank for a solution to the situation. I didn't have one. Silence stretched out...


So one of my team members asks me "So Scrum Master, how do we solve this?"


And I replied "I don't know."


Seeing the looks of shock on the faces of the team was actually quite funny. So what happened?


After an uncomfortable silence I encouraged the team to come up with their own solution. A team member spoke up with a great compromise, the team quickly agreed, and we moved on!


There are several lessons here.


As an agile evangelist and/or Scrum Master, it's okay to tell the team you don't know the answer to something. Let them know we are all just people and sometimes we don't know all the answers.


In conjunction with that, encourage the team to come up with their own answers! Try saying things like, "OK guys, how do we resolve this and move on?" or "Alright then, how do we get past this for now? We need ideas!"


The team knows the answer. They just need to figure it out.