Apr 28, 2007
It's a very interesting read in terms of strategy, marketing, learning from your mistakes and being willing to take big risks. After all if the Wii failed then Nintendo might well have pulled out of consoles and just concentrated on hand-held gaming. And when you consider that the DS was a huge risk for them as well then they've made 2 bet-the-business gambles in the last 5 years.
Anyone who's read Built to Last will recognize that Nintendo has exhibited many of the traits of visionary companies.
Nintendo has stuck with their core ideology (interactive entertainment), they focus on customers over profits (gameplay comes first), they've made huge gambles (DS & Wii), they've kept leadership promotions internal (Hiroshi Yamauchi - 1950, Satoru Iwata - 2002), were willing to change with the times, and they've tried a bunch of things and kept what works ("game & watch" was a success; gamecube was a failure).
In fact Nintendo corporate history shows that big gambles, trying stuff, etc are a part of their corporate culture, and for a company that was founded in 1889, I suppose it was only a matter of time before they bounced back.
Apr 19, 2007
Joseph Little has started to put together a handbook on agile called The Elements of Agile Style. It's still in draft format and it's reasonably comprehensive. It touches on all the main areas of agile at a high level and includes references to more detailed information should you want to delve into a particular area.
It's worth checking out and you should feel free post comments for Joseph. I'm sure he'd love to have feedback.
Apr 17, 2007
Yep, I've aged again. My birthday passed on the weekend and I had a great time. Quite a few presents from my girls, visits from relatives throughout the day, a cake at work today. It's all good.
I've got to say, I'm really happy with both titles. SSX is lots of fun; a really good game and Tiger Woods was even better - I played against my father in law and he really got into it. The swing motion with the Wiimote in T/W is really good and improves a lot on the controls in Wii Sports. The Wii Sports golf was quite fiddly when it came to short puts and it's sometimes hard to register a small swing without whacking the ball past the hole. On Tiger you just swing normally and never have the troubles of trying to register really small movements with the Wiimote.
Also on the Wii - I saw an article on Bloomberg (thanks to Australian Gamer for the link) talking about game makers ignoring the Wii and now being in a complete panic trying to get titles onto the platform as soon as humanly possible. The thing that surprised me was the sales figures...
US & Japan Sales for Jan/Feb
XBox 360: 584,329
The Wii outsold the other 2 platforms combined, by almost 300,000 units!
And as for the statement that the "Wii appears to be expanding the market, rather than stealing sales from rivals"; I can vouch for that. When I see my in-laws playing computer games, having fun and wanting to play more I know it's the Wii that does it - the same game on the PC or XBox wouldn't have any interest to them at all.
Apr 16, 2007
I posted a few weeks ago about an agile refresher I was going to do with my team. Well, this morning was the day I did it (in between sprints).
The presentation itself was structured and geared towards reminding people of the "why" of agile. I kept it focused on the reasoning behind agile using things like the Agile Manifesto, the differences between agile and waterfall, and the fundamental need for strong teams to ensure any agile process works and works well.
I ran through things that agile is not, the value and importance of face to face communications, the goal of reducing wasted effort anywhere in the process, the inspect & adapt philosophy, and the understanding that change in your only guarantee.
I then did a Scrum refresher - deliberately keeping it at a high level and encouraging teams to evaluate what they are doing and how they are doing it to improve items. The last thing I wanted to do was tell the teams how they should be operating (kind of breaks one of the principles) so instead I showed them what some of the other scrum teams around the world have done using photos from the web and suggested that they think about doing the same. Some will, some won't - but that's their right.
I then ran through a series of tips on how to make scrum a success and wrapped it up with a Q&A session.
I got a sense from some people that they still weren't sure about "this whole agile thing" and that they were doing it because they had to, and yet at the same time there was also a sense that even though they didn't get it, that if they stuck at it then maybe something would click. I've got no problem with a healthy skepticism and would hope that those people who felt this way would come up and ask questions until they "get it".
The results? Pretty positive. The energy today and the communication was the best I've seen it in a long time, maybe ever. One day obviously doesn't make a real difference, but if the buzz in the place remains over the next few weeks it'll become habitual and seem like a normal working environment. If that happens, I'll be a happy boy :-)
If you are wondering - here are my tips for success
1. Work as a Team
Team work is a critical success factor for any agile methodology. A dysfunctional team, or a group of individuals will never be able to regularly and successfully deliver on their commitments and will ultimately fail.
2. Work for a Result
Effort is not what you are measured on. It's delivery of working software so keep at the front of your mind that the result is the most important thing. How you get there is important, but secondary to the goal of delivery.
3. Blame Doesn't Fix Bugs
Try as you might, shouting at a team member until you're blue in the face and you've made them cry because of something stupid they've done will not get a bug fixed. It may make you feel better, though it probably won't, and it may even help you vent frustration but what it's absolutely guaranteed to do is prevent you working well as a team.
Correct the bug, educate the person on their mistake and move on. Whatever you do - don't fall into the mistake of personal attacks. It's a zero-sum game.
4. Don't Work in Isolation
How can you be part of a team if you are on your own? How can you be alone and communicate with your team members? It just doesn't add up. Even if you don't use pairing involve others in your work. No exceptions.
5. Use Test Driven Development
Quality is critical. It's hard to be agile with a bug list any long than your little finger, let alone one as long as your whole arm. In a 2-4 week sprint cycle, the only way to guarantee quality is via automation. TDD ensures that the tests are there, ready for the code to be written.
If you don't use TDD then at the very least, write and use unit tests. Failing to do that makes agile very hard to achieve.
6. Don't Take Shortcuts
It might seem smart to take a shortcut, especially if it means you can convince the customer that you delivered on time when time is short. The problem with this is that you're almost sure to have to come back and fix things later and it'll take much longer second time around to do it right than if you spent the time up front to do it properly in the first place.
More often than not, a shortcut is never removed from the system because the cost and time involved in fixing it is just too much. Then you get kludgy workarounds for the original shortcut and over time it turns into a nightmare piece of code no one can maintain or understand.
7. Question Until You Understand
Don't make blind changes. If you don't understand why you're doing something then don't do it. Taking action with a lack of understanding is just a different form of taking a shortcut.
8. Keep it Releasable
If your build server (you've got one, right?) says that the build is broken - don't go home until it's fixed.
9. There is no Spoon
And there is no ideal solution either. Stop overengineering, stop arguing over the fine points of an architecture. Just make a decision and get on with it. If you can't agree get a few other team members involved and vote on it. The more time spent on arguing the less time you spend on delivering.
10. Keep It Simple
Simple but not simplistic. Minimise wasted effort by delivering only that which is required. Bring the YAGNI principle to bear (You Ain't Gonna Need It) on over designed solutions.
11. Collective Ownership
Agile is a team sport. A success is everyone's success and a failure is everyone's failure. The code is everyone's code. The design is everyone's design. The quality is everyone's quality.
If you have people who think "if it's everyone's responsibility then someone else will do it" then you'll need to educate these people and single them out when this kind of thinking hinders the team. The thinking should be "if it's everyone's responsibility then it's my responsibility"
Following these tips won't guarantee your agile projects are successes but it will certainly help.
I'd love to hear your feedback and if you want a copy of my presentation you've just gotta ask.
Apr 9, 2007
It's amazing what you can do with a whiteboard/fridge/stove top, a whiteboard marker, a camera and a willingness to take a risk.
The thing for me is that while it's a promotional presentation for a book it has a visual presence, sense of humour and conversational style that sets it far apart from the millions of faceless, insipid, cookie-cutter book marketing web sites that are out there today.
Check it out
Apr 5, 2007
If you're organised then you probably have an induction process where you give people a run through of the processes - what is Scrum, what are the principles you live by, what are the things you value, and so forth. Unfortunately, even if you have a good induction process, you probably find that most people don't really find their feet for a month or so and much of what they took in during the induction is completely lost on them. For people without an agile background the transition to agile is quite jarring and represents a large mind shift; combined with joining a new organisation, learning a new product, and meeting new people it's no wonder they struggle at times. As a result many people start out with the right intentions and think they get all this agile stuff, but soon the comfortable ingrained behaviours of years gone by eventually resurfaces and they start exhibiting behaviours that are a well intentioned mix of the agile and non-agile practices.
Having a large influx of new people can also cause problems. It can easily trigger existing people to fall back into their old ways for a time and a team can lose it's identity, direction, effectiveness and ability to deliver on it's commitments. Much of the good work a team has done in establishing itself can be quickly unravelled.
So what do you do? I don't know about you but since I've just seen this happen with one of my teams I'm going to do an agile refresher with all my staff.
It's not going to be just a repeat of things they've seen before or reiterating the processes they are expected to follow but rather a reminder of why we do the things we do. The guiding principles, the fundamentals is it were that underpin the day to day. For the newbies it's a chance to go over the things they were introduced to in week 1 and match up what they do with what happens (or at least; is meant to happen).
For the experienced staff it's an opportunity to review the principles, marry them up to what actually happens and to hopefully come up with gaps where theory doesn't match practice and do something about it.
I'm running the refresher in a bit over a week and we'll see how it goes and how much value there is in it. If it's effective I'll make sure I run one of these for every new staff member about 3-4 weeks after starting.
Stay posted and I'll let you know how it goes.
P.S. If you've done this sort of thing yourself I'd love to hear from you.
Apr 4, 2007
Web Worker Daily has a short little post on options for tracking time. It's fairly glib but has a few links to comparison lists for specialised time tracking applications. So, if you need to track time and your memory fails you from one day to the next (let alone a week later when you fill in time sheets) then have a look. There might be something there you find useful :-)
Apr 1, 2007
At this stage I've just been doing some initial testing and dog-fooding it. A few things have been "interesting" and there's some kinks to work through but on the whole I'm pretty happy with it.
What are the kinks - well Symantec A/V doesn't work in Vista. Symantec told us that they had a 10.2 version that works in Vista and that they'd make it available for us, but after 3 days and repeated attempts they haven't. Yeah; nice work Symantec. I'll be sure to tell all my friends about your above and beyond service - not.
What else - VS2003 isn't supported (what the... !?). We still have some older .NET 1.1 code to support so we need it. It's meant to work but "advanced debugging" features are busted. I've still got to try and find these problems, and if I run into them then I guess it'll be a virtual pc image for the support work.
VS2005 has to run under admin privileges. Not really a big deal, but it's a pain hitting the button to run under admin each time. The same applies to SQL2005.
IIS7 is installed with Vista so setting up a web application is a little different but so far so good.
What else? Um, not a lot really; other than a big learning curve trying to figure out where everything lives, and trying not to get gadget-distracted.
Office 2007 is really, really nice. I'm still getting used to where some things live and some of the changes, but it's very cool.
So, this week. I'll trial it with a few more people and see what problems they have, and then start a rollout for everyone.
After that - time to look into the servers. Sharepoint 2007, Exchange 2007, etc.