Feeds:
Posts
Comments

Archive for October, 2011

Ken Schwaber doesn’t tweet very regularly. It is usually only a few tweets a month. But yesterday some of the Agile community went a little in a flurry over a tweet that he sent out:

If you clicked through to the link you went to a website called controlchaos.com. For reference, here is a screen shot of it as it stands now:

Site as it currently stands

It all looks semi real. There is a message from Ken and as you read it you think ‘Okay…. so why have the tweet about Kanban when there is no content relating to it?’

This is when it gets a quite interesting. Twitter’s @Rodrigoy(aka Rodrigo Yoshima from Aspercom) posted that the site was changed only a few moments later removing this:

The old post

For those who cannot see because my wordpress likes to make everything look small:

People love Kanban because it feels familiar. Everything is orderly and known, roles are laid out, project manager is in the saddle, metrics are in place.

BUT…

Kanban’s father, waterfall, failed. As waterfall’s progeny, Kanban also will fail for software development. Kanban is for complicated work, where there is more regularity than irregularity. Such as service calls. Scrum is for complex work like software development. The right process produces the right results.

Yes, apparently it says Kanban will fail for software development and was related to waterfall and not Lean or the Theory of Constraints. The Kanban and twitter community ignited for a while amazed at the faux pa’s.

So you are now left with the conclusion that either Ken went on a small rant and then realised it was maybe not a good thing consequently editing the page or something else happened. Why he didn’t delete the tweet as well is a good question.

There might be the possibility of both Ken’s twitter and the contolchaos website being hacked at the same time. Despite a lack of deep site content he is affiliated to it through an old but still existing common link to Advanced Development Method’s CTO Dick Faris and VP Bob Schatz through Primavera. It is also interesting that he hasn’t made a comment on the web content change.

What do you think – Hoax? Error? Hack? or Truth?

Read Full Post »

In a previous post I shared my wonderment of how teams work hard to reach peak performance when they cannot see each other in the gaming world.

I see great synergies here with Agile – how different is it when software development is done in a distributed or offshore manner? Let’s take a look at the techniques gaming guilds use to reach peak performance.

ALWAYS use voice communications

Lucky you didn't see my avatar handle!

I know of no guilds that have any degree of moderate success without using either Teamspeak or Ventrilo. For those of you unfamiliar with these programs they are like Skype, but allow whole teams to be together in the same chat channel (or in various channels on the same server) without the video input/output but with amazing audio input/output. The reliability and quality of people’s voices is incredibly high. I would recommend that everyone in the team stays in the channel together as they work throughout the day. If you need to ask someone a question they are only a single button (microphone on) away.  Setup your channels something like the following:

  • Team (the default channel which everyone should be in)
  • Private meeting 1 (only if the meeting really has to be private – what is wrong with having the discussion whilst in the default channel?)
  • Private meeting 2 (see above, contingency channel)
  • Quiet Time (for when you really have to concentrate and not be interrupted by someone’s voice)
  • AFK (on lunch or bio break)
Basically you use these tools as an open-ended, incredibly cheap (both on bandwidth and cost of an instance), high quality conference call. What’s to lose?
Now I know with a 100% certainty that verbal imaging would make this even better, but the above solution has no end timeframe on the communication and is not heavy on a computer’s bandwidth. I have found Skype to be unreliable and questionable on quality and so for the moment prefer the audio.

Be present in time together

 This is going to be the hardest thing for offshore teams. I am going to put this out there: If you are doing offshoring to save money (which is a fallacy, but that is a different debate) then your partner must come to the table and provide optimal customer service. To do this they must work the same hours as the onshore team. This should not be a choice – this should be your requirement.

To put this into context – if someone from Australia wants to raid with an American guild they need to change their sleeping patterns and inconvenience themselves for the benefits that they perceive they will get out of it.

Fail often, reflect and adapt often

Who would have thought that gamers did this better than Agilists? In the gaming world, working together the feedback loop is incredibly tight. From failure to reflection of what went wrong is minutes, if that. Teams question what went wrong, search out the root cause and devise a plan to solve or mitigate the problem. The time from failure to another attempt is usually only another few minutes. The cycle continues with more information until the objective is met.

Use visual cues

Agilists do this somewhat better but probably more due to opportunity of the environment then anything else. In the gaming world special icons or symbols are used to indicate assignments, zones to move to, or behaviours to be aware of. This maps to some degree to story walls where tokens and avatars are used to denote particular significance – ie blocked cards, allocations, risks, expedites, etc. Unfortunately for distributed teams a number of tools out there don’t support tokens very well, but avatars are generally a standard feature.

Keep informed on best practice and alternative approaches

Gamers definitely do this considerably better. Because everyone is not together and because their objectives are difficult it is not uncommon for gamers to be given assignments to watch videos of similar people tackling the same issues, to seek out alternative approaches to reach objectives and to orient yourself to what can be expected. I liken this to regular upkeep of best practice of skills and new and innovate ways to approach the problems on your project. Ask your team – how many hours do you spend continuously improving yourself and the way in which you work in your private time – this is a great indication of how attuned the team is to their cause.

Read Full Post »

Most people in the Agile community are now familiar with the Marshmallow Challenge where the primary purpose is a lesson in collaboration and communication (according to the website), but for me the key takeaway is the need to prototype and fail early.

In one of the post events in Agile Australia 2011 Thoughtworks took a different slant on the game and applied a twist of seeing what happened if you distributed it. Rixt Wiersma was the co-creator of the game and I was lucky enough to have a talk to her before and after the challenge.

Taking what was used in that event and then adapting it even further creatively I have an advanced version of this game whose sole purpose is to teach to distributed teams the impact on communication rules and outcome. The result of this is below.

~~~

Time required: 20 minutes actual game play, 10 mins setup/explanation time, 5-10 minutes debrief.

Participants: Six teams of preferably four, but can be scaled up. If you have less than 24 then reduce team B and then D.

Materials: In addition to the standard Marshmallow materials, a notepad with removable paper and a pen is required. Team E will require two working mobile phones.

Rules:

  1. Read the standard Marshmallow rules. Additionally;
  2. Inform the teams that the point is not to learn about prototyping early, it’s about learning the impacts of distribution. As such they need to feel comfortable to use the Marshmallow early in the challenge.
  3. Teams A-E are split in half, the first half is called ‘Alpha’ and second half ‘Beta’. Change the names to cities if you want.
  4. Setup varying distribution limitations on communications:
  • Team A: No collaboration even at minute 0. Beta is removed from the room immediately. No crossover time allowed, no communication allowed on switch overs.
  • Team B: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. No crossover time allowed, no communication allowed on switch overs.
  • Team C: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. No crossover time allowed, communication on switch overs is allowed but only via notes.
  • Team D: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. The teams are allowed to talk for 30 seconds at the beginning of switch overs.
  • Team E: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta asked to leave the room or move to the other side of the room. Alpha and Beta are allowed to observe the other team via other communication methods – this can be done either via a video/tv hookup or simply by letting them stand at a distance and listening in over a phone.
  • Team F: Alpha and Beta are never split.

Timings: Switch overs between Alpha and Beta happen at minutes 7, 12, and 17. At minute 17 the team being swapped out can observe the outcome of the last 3 minutes (in silence).

The crux: Introduce a requirement at minute 10 to not just have one point with the marshmallow on top but to have a second point at a similar height (ie two towers as part of a single structure). You might need to up the spaghetti sticks to allow this to happen from the norm.

Read Full Post »

Phil Kan (philxan on twitter) recently sent in a problem to the The Agile Revolution problem bag:

We have a Product Manager who’s supportive of Agile in theory, but won’t do the work we need him to do. How do we manage that?

A few tweets later we learnt a little more…

They aren’t available for the discussion of stories (often away) & the highest priority work is the customer who screams the loudest. Rather than product progression, we do a lot of tweaks and minor bug fixes. We do showcases after each 2 week sprint (a release is usually 3 sprints). Are we just expecting too much from our customer?

Because we were running incredibly over time there was a little skimming of the issue and I wanted to take some additional time to cover off a few points that we might not have been awfully clear or comprehensive on.

The stance -

  • Craig: Do you have the right person?
    Is this really the right person as your Product Owner? Is someone more suitable that can give you the time that you need?
  • Tony: Stop working on the product.
    If they can’t give the time then they are obviously not committed to the product. By stopping work on it (tools down) you are testing their commitment. If they are upset that you are no longer working on their product then as calmly as you can explain that they need to provide more time in order for you to reach your goals. Ask them the question “If you wanted a renovation on your home, would you just hire a builder and say ‘Do what you want, I’m sure you’ll get it right.’” My concern is that sometimes commercially this is not a viable option.
I’ve added more behind Tony’s thoughts but it was also my instinctual response. In retrospect, can more be suggested? Yes!
  • Consider moving to a Kanban method rather than using Iterations (which was my second thought five seconds after tools down). I hear a lot of complaints (and more of them from product owners) that say Agile has too many meetings. Kanban has a more natural flow. You can still release every six weeks if you want. Or just release whenever now. Yes the product owner will still need to groom the backlog and provide details for you to build off but this is now on a more pull basis then scheduled.
  • Replace your product owner with your true end customers. This is really an extension on the above thought. If you move to Kanban you can setup a regular cadence with all of your customers at once and groom/define stories in the backlog. David J Anderson talks about this process a bit in his Kanban book.
  • Consider shifting to three week iterations. If the complaint is that there are too many meetings then three weeks will reduce the number of meetings over time, but in reality this is more of a perception. Don’t get me wrong, perception trumps and if they think it is better, even though it is the same then it is win-win.
  • Conduct a root cause analysis. Gosh we are so bad at this. Look at how we all initially reacted. Solution, solution, solution! Now in fairness, if you give a problem in a single tweet you are only ever going to be able to go straight into solution mode, but spend some time being frank with your customer. Call the spade as it is. Explain that it is an issue for the team, but that you want to work with them (the product owner) to find a resolution for all. Get to the depths of why they cannot provide the time. Get to the depths of why you need the time. If an understanding can’t be made then maybe look at the solutions above.

Read Full Post »

Follow

Get every new post delivered to your Inbox.

Join 845 other followers