Mar 26, 2007

Getting the Daily Scrum right

Daily scrum meetings are meant to be a coordination and communication session for the team.  A way to kick off the day and keep things going in the right direction.

They're simple enough in concept.  Just ask the three questions - What did you do yesterday? What will you do today? What got in your way?  Easy!

But is that really all there is to it?  Well, not quite and it's surprisingly easy to get it wrong, or even worse to start out OK and develop bad habits.

Jason Yip has an article about Patterns of Daily Stand-up Meetings that is well worth a read.  I've just read through it and realised I've let a few "bad smells" creep into in my meetings, things that just kind of developed over time.  I think it's time for me to take some corrective action :-)

Mar 23, 2007

PS3 Launched in Australia

... and almost no one noticed. The midnight launch parties for the PS3 overnight were spectacularly ignored. According to the SMH article the (not so) massive 40 person strong "crowd" that turned up for the launch at the flagship Myer store in Sydney were outnumbered by the press.

Dear, oh dear... What have Sony done?

I posted about Sony ruining their brand in December, but I never thought it would be this bad.

One small positive note, they did supposedly pre-sell 20,000 units (though it might have only been 10,000) and at $1,000 per unit, that's some serious money. Of course, both the Wii and 360 both broke 30,000 units at launch.

Project Managing in an Agile Environment

Recently I went to a seminar being run by Thoughtworks - a consulting company with a focus on agile software delivery (they're the company who built CruiseControl; the automated build server I use).

It was an interesting seminar and covered a few things from a perspective I hadn't really given a lot of previous thought to - that of the project manager.  I'll briefly cover some of the areas discussed.

Agile vs Waterfall:  Initially the seminar ran through the differences between agile and traditional (aka waterfall) projects from a PM view and explained how things "feel different" in an agile environment and some of the advantages you gain from operating in such an environment.

Cost of change: The cost of changes at various stages in a project lifecycle are fairly well understood from a traditional PM view - there's typically a nice graph showing cost vs project stage with the graph getting steeper and steeper the further the project goes on.  The agile cost change model is quite different and a graph typically shows a flattish line throughout the lifecycle.  Scott Ambler has a good article covering some of this in more detail. 

Simple Approach:  The "simplest thing that works" - it's not dumbing down everything and only doing the most basic of things, but rather an approach where we do "just enough" to satisfy the customers requirements.  Avoiding overengineering solutions, writing documentation that never gets used, designing functionality that wasn't asked for, or worse actually building it as well.  An interesting stat mentioned was that a Standish Group study showed that over 60% of software functionality is rarely, if ever, used.  When you consider the time and cost of that development it's a lot of investment for very little return.

Risk Management: Being able to identify and, more importantly, respond to risk in a quick and cost effective manner makes a huge difference for Project Managers who are typically forced to be reactive to problems instead of proactive.

Changes in scope (aka Scope Creep):  Agile is all about feedback and responsiveness and we expect changes in scope, especially when customers see work in progress software and realise that their original ideas maybe weren't so hot.  But scope is a major issues when working in a fixed price, fixed time, contracted development situation.  One of the really practical ideas was, with the customer, quickly assessing the impact of the requested change and showing what the adjustment means in both project delivery times and project costs.  Showing a customer what their handful of small requests means and then getting the customer to decide what they want to trade off can be a very useful exercise and will help enforce the collaborative approach that underpins agile projects.

Test Driven Development:  What was made blatantly apparent in the seminar was the value of TDD to success with agile and how a "write the tests first" approach is fundamental in ensuring that the rapid delivery cycles can still maintain quality, provides a regular confirmation that the code really works and that the defect rate remains low.  TDD also helps ensure a simple approach and forces people to think through the work to be done before jumping in and coding.

User Stories: From Wikipedia; "A user story is a software system requirement formulated as one or two sentences in the everyday language of the user".  User stories are very similar in concept to use cases, but without the detail that sits behind a use case, and include criteria for acceptance testing; i.e. what has to happen in order for the user story to be deemed complete.  In terms of delivering work, user stories can be thought of as the summary of all the work that occurs underneath that, such as writing a use case, doing a UI prototype, developing the code, testing it, and proving the requirements have been met.  If you ever have to  deal with tender requirements, it may be a useful exercise to group the one-liners from the tender into stories and to do prioritisation and estimation based on the stories.  Then when you win the contract you can then come back to the stories and have conversations with the customer over what the real needs actually are (ie base gap analysis around stories not data areas).  More information on user stories can be found at Advantages of User Stories for Requirements, Writing Contracts for Agile Development, User Stories

Local Optimisations and Completion: One of the more interesting things to come up was a conversation I had after the seminar around velocity and what counts as completion.  When I talked through velocity I indicated that we are typically achieving a velocity of between 0.4 and 0.8.   The Thoughtworks people were actually pretty impressed with that as they typically expect velocities of around 0.2 to 0.3, however their velocities are based around story points and the understanding that delivery is not just a development process but that it involves all people on the project, and that a story is not delivered until the customer signs off on it.  Because my control is limited to development areas and because we count items as delivered when they are internally signed off I'm are really only looking at part of the overall process.  By focusing on only the areas in which I have control i may be misrepresenting the real time required to deliver an item and may be missing slow downs in other areas where we are wasting time or that could be further improved.  In other words I may be locally optimising work at the expense of the overall efficiency of the project.  Hmmm, something to think about...

Story Boards:  Prioritising work with story boards is a recommended practice with agile projects and was actually used in the seminar to prioritise the requests from the attendees on what areas to cover.  It was really interactive, really quick and very useful and seeing it in action made me realise how useful it might be to do this internally.  I always used Excel for tracking priorities as you have a permanent record and don't have to worry about cleaners knocking items off whiteboards, but seeing how easily it worked I wonder if it's worth trialling it.  After all, switching priorities in Excel can be a little bit tedious at times.

Overall, it was a very interesting seminar and gave me a fair bit of food for thought and triggered some ideas for other improvements I might be able to make in the near future.

If you get a chance to go to one, it's worth doing.

Many thanks to the guys at Thoughtworks for their time :-)

Mar 22, 2007

UI Prototyping in PowerPoint

At work we do almost all of our UI design mockups in Visio but because they're static it's sometimes hard to get a feel for what will really happen when people click on things and how usable it is.  In other words it's easy enough to see if the "look" is right, but what about the "feel"?

Well it turns out that you can emulate some limited interactivity using PowerPoint.  I hadn't thought of doing that before until I ran across this blog entry from one of the guys responsible for the Office user interface.  It's pretty interesting and it might well be time to try it out :-)

Mar 15, 2007

The Statstical Life of Feltron

I don't quite know what to make of this.  There's a bloke named Nicholas Feltron who has made stats of everything he's done this year and then published it as an annual report.

One one hand, it's a great example of communicating information and it's excellent design work.  On the other hand it's scary as hell - I mean, who does that!  Who keeps track of the hottest/coldest temperatures in places they've been.  Every day.  For a whole year!  And who notes down when they get their first grey hair!  Or the types of animals they've eaten.

I really don't know what to think, and yet it's strangely compelling.  Go check it out and let me know what your impressions are.

Mar 13, 2007

Why Contractors Get A Bad Name

Ok, I know you should never post angry, but I'll run the risk in this case.

Because of the shortage of skilled .NET developers I often have to turn to contractors to get quality people in the door in the timeframe I need.  In the past I've picked up some top notch quality people.  People I am proud to have worked with (or am currently working with), who are integral parts of their teams, who work as much for the team as for themselves and who are genuinely missed when they go.

Then there's the bad eggs.  You hear stories of those who misrepresent themselves in interviews, those who stop putting in after a few weeks elapse, or - like the one I had today - those who commit to a 6 month contract and resign 2 weeks into it because a job they've been holding out for was offered to them.  Being used by someone as a short term cash source while they wait to see if the job they really want is offered to them is an unethical and dishonest way to behave, and hearing excuses about how they "don't normally do this sort of thing" doesn't make their behaviour any more palatable or acceptable.

I really value and appreciate the contractors I've met who are genuine and open about their situations.  This other type of contractor just gives everyone else in the industry a bad name.

Mar 10, 2007

Changing a development culture

Many people can tell when a development culture isn't healthy. Much like being able to tell that the wind is blowing they can see that things aren't right by looking at the evidence around them. High development costs, substandard quality, missed deadlines, code not matching design, business priorities not being met, no responsibility taken by those doing the work, and so on.

Sometimes people think that a better process will, on it's own, cause all these things to improve. As if the process is the problem, and not the people, as if people always follow process to the letter, and as if a process always works in every situation.

The reality is that the right process is important, but that the people using the process are more important. The number one principle on the Agile Manifesto is "Individuals and Interactions over Processes and Tools". Jim Collins in Good to Great talks about this as "getting the right people on the bus".

People are your critical factor to success. So, whether you use CMMI, Scrum, XP, RUP, or any other development methodology, if the people have are poor the results will inevitably be poor. And worse, if the culture is poor, the good people you may have will be unlikely to stay.

So, how do you change and improve on a bad culture? How do you break the habits and attitudes that permeate everything that is done? Is it through charismatic leadership? Through slavish adherence to processes? Is it through ranting and raving at people until your throat is raw?

The answer is none of the above. Cultural change only happens slowly and gradually, and is really a reflection of how the majority of people in your team think and act. The hard part is, that in poor cultures, there is a reinforcement of mediocrity, of striving for the lowest common denominator, for seeking the path of least resistance, for not sticking your neck out and suggesting improvements. It's easier to complain to colleagues about how the culture sucks, than it is to actually try to do anything about it. And a bad culture is very unattractive to good people and those who look for the best, which just makes it harder to turn around.

The good news is that it's not impossible - you just need to have direction, endurance and determination. And you need to be able to motivate your people to want to change.

In other words - you need to use the carrot and the stick.

The carrot is the better method of course. Inspire people to improve through communicating what you expect. Constantly. Every day if you need to. Set your expectations and set them clearly. Do not be afraid to them high and always be prepared to measure every decision and action you make against those expectations. And ensure you meet those expectations yourself, all the time.

Constant communication is critical. People who are constantly told something will eventually believe it. History has countless examples of cultural change occurring through various forms of propaganda (both good and bad). And history shows that people who are constantly told how to behave will eventually conform to that behaviour.

You should also try to get your people passionate about what they do. In this you will have to lead by example. Show yourself getting passionate about what you do, about successes your people have, about improvements you can use as examples. Passion and excitement is infective and others will catch your passion.

And most importantly reward those who change. Those who meet your goals for change should always be rewarded - publicly or privately. It doesn't matter. And rewards don't have to be material - praise and recognition is just as good a reward for many people as a gift.

The stick on the other hand should be reserved for those who refuse to change. Do not hesitate to show displeasure at failure or unmet expectations. Do not hesitate to remove people who do not try to improve. And most importantly do not hesitate to remove the ring leaders seeking to maintain the status quo.

Some people just don't like change. They like their negative cultures, they enjoy highlighting failings in others without admitting their own, and they will actively seek to pull down any initiatives that might improve things. These people are like a cancer and must be cut out. Do not feel guilty and do not feel remorse. Even if they are your most skilled people.

From experience, removing a negative person from a group releases the silent majority from the fear of abuse by that person and gives them the permission they need to improve. It also shows you are serious about change and willing to do what it takes to see that change happen.

Obviously, you need to tailor whatever you do to your own situation, and nothing ever happens overnight, but keep at these things and improvements will occur.

It can be a long and bumpy ride at times. Good luck on your journey.

Mar 7, 2007

I've been gaming

Over the last few weeks I haven't exactly done a lot of posting. My apologies for that.

There's been a few reasons:

1. I've been absolutely rushed off my feet at work recently and finish each day mentally drained and not feeling all that bloggish.

2. (This could be the main reason) I bought a Nintendo DS Lite and got Metroid Prime Hunters and Hotel Dusk. Playing with my new toy seems to take up a lot of time...

Damn this portable gaming stuff :-)

Metroid is lots of fun, and once you get the hang of using the stylus to mouse-look it's really cool and intuitive.

Hotel Dusk is obviously a little slower, being a detective game, but it's good fun and slowly drags you in - a bit like quicksand - until you can't leave it alone.

I'll remember to post a little more often even if I have to ignore the siren call of handheld gaming!!