Mob programming in short

Yesterday our team was eagerly waiting for our team coach to make his appearance at Agila Sverige an agile conference in Sweden.

You can watch his awesome talk here (in Swedish): https://agilasverige.solidtango.com/video/mob-programmering-fran-oreda-till-gladje

As we were waiting we watched an other lightning talk about tips for visualizations in agile projects doing Scrum/Kanban. By the way this talk had awesome tips for visualizations and the presenter did a really great job. You can watch it here (also in Swedish): https://agilasverige.solidtango.com/video/visualiserings-bonanza

But during the talk members of our team were twitching and every now and then someone said

-“We’ve Done that”

-“We’ve tried that”

To summarize I think we all collectively realized how much waste we’ve gotten rid of during the past 6 months we’ve been mob programming. It’s almost like the first time you tried Kanban after doing Scrum and realized there was a lot of waste in Scrum that you were glad to get rid of.

So about 6 months ago our team at Fritidsresor began doing mob programming and my initial concerns were about speed. Would be able to sustain the same speed or even deliver faster.

I was dead wrong, speed is just one of the thing that gets more awesome. You will eliminate a lot of waste and gain both speed, quality and most important of all your team will get really tight and have lot’s of fun.

I’m out of battery so here are my top 5 tips for a successful introduction:

1. Trust, make sure that everybody is on board. All members of the team, your team coach and the organization. The organization part is really hard I think, luckily for us our team work at Fritidsresor where they’re really open for this kind of experiments.

2. Start small, begin with 1 hour a day or half a day every week. Working your way up to full days.

3. Humbleness, you’ll work closer to your team members that you can imagine. It will take some time before the team process is in place, but on the other hand with mob programming you will get to that place faster.

4. Territory, you will need a physical place were you can use a projector (or two). Were you can invite stakeholders and so forth.

5. Software, you will need some kind of timer that interrupts team members when their time is up. You will need a team account for computer login, email, chat, GitHub etc.

This and more are stuff we’re glad to share as a team in fact we’re doing a presentation today at 15.00 at Valtech Tech Day 2015.

Cheers,

Hugo

Say hi to Paula

image
Paula sleeping

image
Paula sleeping

Birthdate: The 19th of May 2015 at 19:57
Weight: 3360g
Height: 50cm
Head circumference: 33cm
Awesomeness level: Extremely high
Cuteness level: Almost infinite
Spoiled level: Pretty high
Smells: Like sweet clouds

image
A fantastic feeling when the whole family is united for the first time.

Announcing Fluxo 1.0, a Kanban Dashboard for Trello

 

Now that’s a great milestone Hugo but can you tell me what’s new in this release?

-Almost nothing, but let’s turn the clock back a week…

About a week ago on my way to work I started to notice how my Kanban dashboard had some trouble loading. Naturally I opened up the developer tools in Chrome and noticed a lot of “429 Too Many Requests” errors. (The Trello api has a Rate Limit that you can read about here http://help.trello.com/article/838-api-rate-limits )

That’s odd, it can’t be that many people using Fluxo at this time in the morning I thought to myself, and then it hit me. Someone had probably hijacked my Trello application key because I was using Trello’s own Client.js with the key and it was all stored on GitHub in a public repo.

From Trello’s on how to use their Client.js documentation:

<head>
<!-- ...  -->
<!-- The client library requires jQuery  -->
<script src="http://code.jquery.com/jquery-1.7.1.min.js"></script>
<script src="https://api.trello.com/1/client.js?key=substitutewithyourapplicationkey"></script>
<!-- ...  -->
</head>

I remember thinking that this client side key exposure could cause some issues the first time I started to use it but I hadn’t thought about it ever since.

Anyways I decided to do a complete rewrite and use a server side OAuth solution instead. And last Friday I actually finished it.

To sum it up Fluxo now uses a server side OAuth solution and I also added a 5 minute caching on all requests to prevent hitting the Rate Limit of 300 requests per 10 seconds.

This time no keys are stored in the repo, a lesson I’ve learned the hard but funny way,

Hugo