Oct 28, 2006
There'll be around 100-120 people attending and I get to speak in front of them all. As you would expect, I'll be taking a powerpoint presentation with me, but I'm leaving those sleep inducing bullet points and eye cluttering corporate branded master slides way behind.
It's time to take my "enlightened" presentation style on the road and see how it goes. It should be fun.
One thing I'm glad of, the presentations I've done internally and the tips I've picked up from PresentationZen and other similar web sites have really helped me improve my presenting skills. Doing this thing in Singapore should be a lot easier as a result and I know I should be able keep the audience interested for the duration of the talk. I'm fairly confident I've targeted the audience and made the presentation about them, not about me.
I'll let you know how it went and pass on anything else I learned when I get back.
Oct 26, 2006
This second assumption is incorrect, however new versions of SSL certificates are being readied that will change this. Adding this verification will help bring an end to phishing, and that's a good thing.
If you're interested have a read of this blog entry for more information.
Oct 24, 2006
The Sydney Morning Herald had an article just recently about the same subject, but from a different perspective that I hadn't considered. Basically they say that Google's attitude is that it's easier to ask for forgiveness than permission. In other words, do it and let the lawyers sort it out.
Apparently the market seems to agree with this attitude as Google shares rose over the last month (when rumours started surfacing) from about US$400 to around the US$480 mark (a 20% increase!).
Kind of scary but I don't suppose there's any other way to push the boundaries is there? Then again I don't see Apple doing the same thing (at least not as blatantly), or Oracle, or IBM, or Netscape, or Sun, or Nintendo, or Sony, or a bunch of others. The only one I can think of who acts like that is Microsoft, and they seem to be improving their attitude and behaviour over time.
Microsoft behaved/s the way they do because they're a monopoly. A monopoly of the desktop and the office suite. I sure hope Google isn't starting to behave the way they seem to be because they're a monopoly of search and internet advertising.
Like all big companies there's plenty to like, but also plenty to improve on. On the GooTube thing - for now I'll hold my judgement.
The blogger beta seems to have changed something that stops windows live writer from connecting to the site. I've tried posting, listing and even re-adding the blog but I just keep getting an error telling me I can't connect to the remote site.
I guess it's wait a little bit and see if the guys on the live writer team can't get a fix out soon-ish. Until then, it's back to cut & paste of the HTML into the blogger editor.
Well, I'm happy to say that since I went back to the drawing board 9 months ago and started again that Scrum is not only well implemented in product development but the principles of scrum are starting to filter through to other areas of the business.
I've taken a look around me now and tried to determine what has changed in the last 9 months. If you're thinking about implementing scrum in your organisation here are some of the good things that can happen.
The product development area now really owns what they are doing and takes pride in delivering a visible product increment every two weeks. Not only do they own what they are doing but they also look out for each other as well. There's a genuine sense of camaraderie and teamwork evident in the place that other parts of the business have noticed.
The teams within product development are also acting more responsibly in their coding, testing and design efforts. They want to ensure that quality is shown from the start, instead of being a bolt-on at the end of the development process. While anyone will claim responsibility for things that work well few people will stick their hands up and claim responsibility if they screw up. The team has learnt that taking responsibility for failure is OK and won't result in being shown the door.
Less Centralised Management
What do I mean? Well, when there's a problem the first person someone will turn to now is another person within their team. I'm only really made aware of issues when they are escalated or when there is a genuine impediment to progress.
The teams are also self organising - I don't need to allocate people to tasks. The team gets the priorities from the product owners and accepts a quantum of work to be done in the 2 week sprint cycle. Once this is done the team will go off and allocate amongst themselves who does what.
Estimates made by the team are typically met. In the last 40-odd sprints (multiple teams) there have been 2 failures. Just 2. Not that a 5% failure rate is desired but it's certainly a lot better than industry norms. Also one failure was early on, and the other was a result of a change in development practices (introduction of pair development) where the impact on estimates for time weren't all that well understood.
While plans will always change, there is more up front thinking being done over what should be worked on and in what order. The stakeholders and product owners feel more involved in the development process and they can talk more confidently with their customers over what will be happening in the product.
More planning also means less scope creep and less ad-hoc requests. One of the things I did was to ensure that anyone who wanted to pull a team off for other work (pre-sales, etc) would have to either plan it in advance or, if it was last minute, cancel the sprint.
This has been tested on a number of occasions but given that the requestor is usually negatively impacting other people in the business if the sprint is canceled they have changed their minds and approached the problem they have in a different manner. The previous habit of people turning to PD and sucking up resources on an ad-hoc basis and yet still expecting delivery and quality is gradually becoming a thing of the past.
Less Staff Turnover
Believe it or not, the turnover of staff has dropped dramatically. There was a period for about 6 months after I started where staff turnover was quite high. Some of that could be attributed to a change in manager, but most of it related to burn out, unclear objectives, no sense of work pride, etc.
After the introduction of scrum, the turnover in staff has dropped right off. There is still the occasional resignation, but people are working at a sustainable pace, have a sense of direction and have clear goals to work towards.
Staff retention not only reduces payroll costs and head-hunter fees, but helps improve productivity and morale. It's a feedback loop as well, lower staff turnover increases morale, higher morale reduces turnover, and so forth.
Even if Scrum didn't bring all the changes listed here then this alone would have made it worthwhile.
More Customer Focus
Agile development in general is focused on delivering business value to the customer, not on producing what you hope is what the customer wants.
Introducing scrum has not only helped us refocus on the customer but also given us a structure wherein we can have our key customers and development partners involved in assessing what we have produced, giving input into what they see as priorities, providing feedback on product ideas we may have, helping improve usability and so forth.
If we develop something as a prototype and it's shown that it's not really what someone needs or wants, we lose at most 2 weeks worth of work, which is a helluva lot better than 6 months of full on development. However because of the tighter customer involvement we have we are even less likely to screw up in the two week sprint cycle because we have improved communications and gained a better understanding of what the customer actually needs and the risk of doing the wrong thing is even less.
A Better Product
The product itself has improved. No question about it. The things we have added to the product are what customers are asking for and so our value proposition for the customer is improved. Would this have happened without Scrum? Maybe, there's no reason why not. As it turns out our product plans as at 9 months ago and what we actually produced since then are actually quite different.
The organisation itself has changed quite a bit since the introduction of scrum. We are now more outward looking and more adaptive to customer needs, there is more responsibility being taken across all parts of the organisation for what they produce, there is a greater focus on delivering value to the customer - not just in product development, but in other areas as well and there are overall improvements in morale and teamwork.
Does this mean that everything is perfect now? Of course not! We still have problems, still have people issues, customers still need support, there are still shortcomings in the product and all there is still plenty of room for improvement. Regardless though, things are a lot better now than they were before.
Was this all achieved because of me? I'd like to say of course it was and then rabbit on about how wonderful I am but I'd be lying. All of this was achieved because of a combination of factors. The biggest success factors were a willingness from the team to change and a structure with scrum that was focused on that change. The fact that an agile process is built around an understanding that it takes people to make something work and that we're not automatons is a great enabler for improvements. All I did was facilitate the change, lead a little bit by example to get things started and then get out of their way. If it wasn't for my great team then none of this would have happened and I'm indebted to them for the willingness and adaptability that they have shown over the last 12 months.
If you wish to implement scrum (or another agile process) in your organisation remember that it's the people that make it work. Scrum is not a magic bullet that will solve all your problems, bring about world peace and get you on the Rich 100 list. It's just a framework to refocus you on what's important - delivery to the customer & improving your team.
Oct 23, 2006
For those of you who have clicked through the ads on this site - thankyou. For those of you who hate them - sorry (but at least this site isn't flooded with ads as you see on some web sites).
If you were wondering the money is going - it's headed straight into my Wii fund where I'll be helping poor homeless games find a place to stay :-)
Well worth a read in full, but some of the key points that made me notice were the things I see in other presentations that drive me nuts and that I try to avoid.
1. Don't cover history. History is dull, boring, numbing and tedious.
2. Don't big note yourself. It might make you feel good to do it in front of a big crowd, but it drives me nuts and to be honest I don't care.
The number of times I've seen company presentations where the first 900 slides are about the company's history and how many wonderful other companies they've sold their snake oil to drives me bonkers. If I see them these days I'm just about ready to walk out. Why are they wasting my time!! Grrrrr...
The article also has some "do's" all of which centre around trying to make it an emotional experience (if possible). Evoke some sort of feeling in the audience - surprise, humour, desire, hope, whatever you like. Without any emotional content you'll lose your audience faster than you can blink.
It's hard to do this at times, but keep at it and your skills will improve and your audiences will be more involved in what you say (and will hopefully remember it as well).
Oct 19, 2006
The Braidy Tester has a little blog post about the mentality a tester must have.
Guess what - it's not just about proving something doesn't crash, but also about making sure it's good for the customer.
Thinking about the customer doesn't just apply to testers and testing though, it also applies to the rest of us in our design, UI, code, support, and the other activities we do and is one of the foundations of any agile methodology.
Oct 12, 2006
Of course 14 inch monitors died out years ago along with Windows95 so designing for 640x480 is silly. But 15 inch screens (800x600) are almost impossible to buy new these days and I've been wondering how many of these are still in use and why people still design sites for that resolution (or for IE 5.x and Netscape 4 for that matter).
I use sitemeter to check visitor patterns for the blog and one of the things they have is a way of checking resolution of screens. Here's what I saw when I checked recently...
As you can see, almost everyone has a resolution of 1024x768 or higher. The 800x600 resolution is a paltry 3%.
Similarly, colour depth is at 32-bit for 94% of the visitors as well.
I guess the days of designing for limited colours and small resolutions are over. 1024x768 resolutions at full colour can now be treated as the lowest common denominator.
Oh, and in case you were wondering, IE 5.x made up a whopping 1% of the visitors. It's all IE 6+ and Firefox these days. No Safari, Camino or Konqeuror and very little Opera.
OK, so everyone knows that Google went and paid more than the GDP of some small nations for YouTube. The question I'm still asking myself some days later is why?
I mean, seriously, where's the payback? How on Earth are these guys going to recover that much money in 2 years or less. Why 2 years - because that'll be about how long Gen-Y's attention span lasts before it switches onto some other instant fame fad. And it'll be about that long before the lawsuits start getting decided.
I can imagine that right now the copyright holders for music videos, ads, and movies are all going through YouTube looking for their works, and getting their lawyers amped up and ready to sue. Previosly YouTube had little money and weren't a real lawsuit target but now that they're Googled they'll be rolling in it. They're a rich target, and rich targets end up getting sued.
So why would you buy YouTube? I just can't seem to get my head around it. Surely it's not so that they're "cool", or to stop someone else buying them.
More and more Google are moving away from their core business of search (and advertising) and getting into other areas where they don't have core strengths. They're self proclaimed air of superiority, uber-coolness and the "we're smarter than the rest of you muggles" attitude (as so eloquently expressed by the walking rant machine and flame-bait Steve Yegge) is starting to get tired and wear a bit thin. It's a slippery slope Google are walking on it's likely to end with a fall.
If I had Google stock I'd be thinking about cashing in now while the going's good.
Update: A post on J.LeRoys blog covers similar territory, but looking at Yahoo losing their identity instead of Google.
Oct 11, 2006
Read the article for the description of each item, but here's my take on the 10 flaws and what you should do about it (if the shoe fits, that is)...
- Failing to have a life plan
There's a claasic little saying - "Without a vision, the people perish". No goals means you'll probably have little or no drive, no ambition, no joy of accomplishment, nothing to get up for each day, a sense of listlessness, etc.
- Not keeping your skill set current
Out of date = out of work. The best way to keep up to date is to read abuot new things, and then think about ways you could apply it to your current situation. Failing that get yourself on training courses, buy books and resources, etc.
- Failing to deliver results
It's Scrum! 'nuff said.
- Confusing efficiency with effectiveness
Talk. Ask Questions. Communicate face to face. Sounds a bit like pairing to me.
- Believing that you are irreplaceable
Don't confuse being replacable with not being valuable.
- Knowing all the answers
No one knows everything and pretending you do just annoys your colleagues.
- Surrounding your self with "brown-nosers"
"Yes men" are not supporters. They're like groupies - they're there when things go well and vanish when things turn tough.
- Forgetting to give credit to others
People know those who do good work and those who don't. Leave your ego at the door each day and support your team.
- Failing to self promote
Self promotion is not an ego trip if you do it humbly. Note that Anthony Mundine style promotion probably won't work.
- Losing perspective
No (wo)man is an island. Ask for opinions, seek advice, and remember the customer!
Oct 7, 2006
Oct 5, 2006
I've always thought that the "Head First" series of books were great. Head First Design Patterns in particular in an excellent book and really makes a lot of sense.
Well I recently discovered that the authors have a blog called Creating Passionate Users. It's all about making what you do more focused on the person using your products than on those making the products. In other words it's more about you than it is about me.
Sure, the posts are on obvious subjects like thinking about your users, but if you're anything like me, the day-to-day of working in a company has a habit of getting in the way and you find your focus drifting to the internal company issues rather than staying on finding new and better ways to solve the issues that you're users/customers have.
The good thing about the way these posts are written is that they're not condescending or insulting to your intelligence.
If you've got any interest at all in the people who use your products then I'd strongly recommend having a look at this blog.
Oct 4, 2006
Running agile development teams is great but one of the things that can happen with agile is that information gets into a few peoples heads and often stays there until needed. If those people leave or too much time elapses before it's recalled then the information is often lost. Similarly other people new to the team have to try and extract information somehow from the existing staff and that can take time, and people in one team often miss out on the lessons learned in another.
After having both of these platforms up and running for a short while now it's really interesting to see what's happening.
The blogging in Community Server has been a big hit with regular posts being made each day. Interestingly enough it's mainly the developers who have been blogging. The BA's and most testers have been really quiet.
The developers are blogging about coding practices, interesting things they find on the web and really sharing a lot of information. It's very cool seeing the team looking out for each other and trying to share as much of their knowledge as they can.
The wiki has also been used a bit, but for more of the semi-static information. Things that are popping up there are how-to's, basic guides to various processes, social stuff (like party photos), and other bits and pieces.
The forums provided by community server are still pretty much unused, but that may just be because people aren't yet sure how to make use of them properly for internal communications.
P.S. To help encourage adoption one of the things I've tried to make sure of is that I am leading the way and be an example. I'm blogging about everything I can think of, ideas I have, what's happening in the rest of the business, etc. and I'm also adding content into the wiki and trying to post questions to the forums. I'm even putting notices there and then mass-emailing people that they should look on the blog to try and get the late-adopters into it.
Oct 1, 2006
This is theoretically a show for kids, but how any show that features the Umbilical Brothers could be for kids only, I don't know. It's wierd, it's zany, it's way over the top and it's very, very funny. Just the way kids (and big kids) like it.
I've been on a communications kick recently, looking for ways to help improve my teams communication.
The team communicates well currently, but it's all verbal, email or IM communications. How do we retain knowledge, how to we make information searchable, and how do we get the information we need when we need it without flooding each other with communications spam. You know, the type of email that is cc'ed to every man, woman and child on the face of the planet just in case we think someone might want to know something.
I don't know about you, but this sort of communication gets a bit overwhelming and turns into just so much background noise. Emails get ignored, deleted unread or filed in the "action required" folder and then never see the light of day again.
For instant one-to-one communications we can walk over to someone and talk, or use the phone (no really!, it's true), or we can use skype or messenger. Any of these are viable options and work well and are currently used by the team. Of course nothing that transpires in these conversations is recorded or kept for historical purposes, but that's fine.
Then there's the delayed form of one-to-one communications we all know and love - email. Obviously email can also used for the one-to-many form of communications as well. Internally we log all the emails for security purposes, but we don't make them publicly searchable or retrievable for privacy reasons. Obviously this means that any knowledge transfer that occurs in email occurs with the participants of the email conversation alone and that's kind of OK but doesn't lead to long term knowledge retention for the team.
We also have file shares - the usual suspects where we store documents, specifications, user guides, use cases, design ideas, project documents and a whole bunch of other rubbish we just don't know what to do with. This is OK for knowledge retention and is most organisations one and only form of semi-permanent knowledge that isn't residing in the heads of their employees. The problem with this is that the knowledge is disorganised - sure people put documents in folders like \\server\share\myprojects\project1\March\2006\specs, but there's all sorts of problems with this. What happens if I can't remember when I did something? What happens if someone else organises their folder structure by subject matter instead of project? What happens when the person who put something in those folders leaves? Who really knows what information is walking out the door between that persons ears, where they kept things and how often they updated their information (if ever), and if we don't know what they did or didn't know then how would we ever know to look for it and where would we find it. Intranet search engines like the Google mini or nutch (which uses the lucene search engine) can really help in this matter, but your mileage may vary and you are dependant on permissions to folders being appropriate.
So we've got a few bases covered, but we're still missing a few pieces to the puzzle.
How do we do non-directed, non-real time communications?
How do we do non-structured information storage (especially for specs, etc)?
Wiki's help with non-structured storage for the team. Why? Because they are HTML based. You can write a spec, like a use case for instance, and link to actor definitions, other use cases, tech specs, or whatever else, all without caring about where exactly the pages for those other items live. In a file share system you need to put a reference to other documents in the main document, and hope that none of those other documents ever gets moved.
Wiki's also help with information currency. When something changes, it's easy to find the information in the Wiki (just search) and then edit and change it. File share based information is a lot harder to do because finding the information in the first place is difficult and that alone prevents most people keeping information current. The barrier is too high.
Wiki's like MoinMoin also feature historical tracking and a diff tool. Someone changes something, then you can not only see who changed it, but what the change was. When updating software to match and updated design, this is a boon. Trying to do it with file shares pretty much means relying on the "track changes" feature in MS-Word, and people will forget to turn that on, or will merge the changes before someone else can see them.
Blogs help with the non-directed communication for the team. I don't think I need to explain the benefits of blogging and there are enough other articles on the web for that. I had a bit of a look around for decent team blogging systems and saw things from the main blogging people but none of them really seemed to work well for team blogging - where each member of the team gets their own blog and can so what they like within that space. Then I ran across Community Server. What a pleasant surprise that was.
Community Server features include blogging and personalisation, but they also include forums. Now I have a mechanism for not only supporting the non-directed communications and keeping the information searchable and retrievable, but also keeping the "how do I" type of questions in an area where others can search for and find information much later (which I can't do with email).
I put community server into the team last week, and the initial take up has been positive. Like all things though, the hard part is now encouraging those that don't naturally put their knowledge down on keyboard, to start doing so.
By the way, in case you're wondering, do I think this solves all of the communications issues, or the knowledge retention or search problems I have? Not likely, but it's a few more tools to help and enable communications and in agile environments communication and openness are a few of the keys to success.