Archive for the ‘Team’ Category

Things are getting silly now..

Wednesday, November 11th, 2009 by steph

When I set up Magic Milestones I never imagined for one moment that our team would consist entirely of Women.

There are 8 of us at the moment and we are all female.

Don’t get me wrong we ARE DIVERSE! Just not when it comes to the m/f split.

However, there are some major benefits for our clients in this state of affairs, which don’t go unnoticed…

1. In a very male dominated IT environment it helps to have a few females sprinkled about the place in order to keep the sport talk to a minimum if nothing else.
2. Geek women can talk tech whilst also being able to engage in “fluffy” conversational topics including (but not limited to) fashion, interior decor, cats, snowboarding? Etc…
3. Despite the bad press that female dominated work-forces get, women can actually work together pretty damn well when they put their mind to it!

However, it is potentially getting silly now… so chaps please feel free to send your CVs to enquiries@magicmilestones.biz and we promise to break the mold for the right person.

Come on… how scary can working alongside 8 female project managers possibly be?

The Six Thinking Hats

Friday, October 16th, 2009 by cindyedmonds

Someone tipped me off last year to a really useful technique. It may be one of those things that the rest of the world was aware of and I have been under a rock and missed it but in case there are some fellow rock-dwellers reading this blog I’m going to share the epiphany here. I’ve been working on a new business proposition over the past couple of weeks where it has been incredibly useful to apply this technique: Edward De Bono’s Six Thinking Hats.

The premise is that we all have a natural or preferred thinking style. For example, my thinking style is quite critical and ‘nit-picking’ whereas one of my colleagues is more optimistic and grandiose. When considering new business investments we need to apply both styles of thinking (and more) to the proposition to ensure we cover all bases. I’m sure everyone has worked with someone who you dread having a meeting with because they’re so negative or obstructive? I’m not saying I work with anyone like that right now but I have in the past and as a Project Manager it is imperative that I get the outcomes that I need from meetings and the Six Thinking Hats is a great enabler for this. (I have copied the following definitions from wikipedia)

  • Neutrality (White) - considering purely what information is available, what are the facts?
  • Feeling (Red) - instinctive gut reaction or statements of emotional feeling (but not any justification)
  • Negative judgement (Black) - logic applied to identifying flaws or barriers, seeking mismatch
  • Positive Judgement (Yellow) - logic applied to identifying benefits, seeking harmony
  • Creative thinking (Green) - statements of provocation and investigation, seeing where a thought goes
  • Process control (Blue) - thinking about thinking

Six Hats Thinking means that in meetings, for example, the team considers the issues while imaginatively or figuratively wearing each of the Six Hats in turn. Some people stay quiet during Green Hat as they can’t think that way and then jump in with enthusiasm during Black Hat. Genius!

Which Hat are you?

Scrummaster reflections

Tuesday, September 15th, 2009 by cindyedmonds

I am now a Certified Scrummaster which means I have done the formal Scrum training and have certified that I lead the team using the official and recommended techniques. During the course I was happy to see that we at Magic Milestones already follow the Scrum techniques closely so there was not a lot of new ground to cover. However, hearing the other course attendees describe their workplace environments, usually in the context of explaining why Scrum isn’t working so well for them, I was a little bit disheartened about certain trends. Because Scrum teams are self-organising and the teams make their own decisions there is a bit of a trend to not use Project Managers in the Scrummaster role and to use developers or tech leads instead. The main role of the Scrummaster is to remove impediments and obstacles to the team’s progress. In order to do this the Scrummaster needs to be empowered in the organisation so that they can suggest the changes that are often required in order for goals to be met. This is where I see the huge value in having a professional Project Manager in that role - someone who is experienced in working with top management and implementing organisational change to support the project and who is empowered to do so. If a developer or tech lead is empowered and experienced in these things then having them as Scrummasters is all well and good but if they are not, and if they are not interested in that element of the role, then the situation can arise where Scrum is shoe-horned into less than ideal situations.

By empowering teams to be self-organising and making their own decisions you can certainly get great software results and team cohesion. However, you can’t always get a team that is capable of changing processes outside their immediate area, such as integration testing or other third party dependencies, so that timelines are shortened and goals met. In the Scrummaster course there was a lot of discussion about when is a task ‘done’. It seems that in a lot of organisations it is hard to get to ‘done’ due to dependencies on other teams such as a QA team or processes that create delays before a developer can say that their task is ‘done’. An empowered and experienced Scrummaster should be able to suggest and implement process changes to remove these delays and integrate with other teams or dependencies. If the Scrummaster role is being performed, on a rotating basis, by developers or tech leads rather than managers with experience in process change then I think the team will struggle to get to ‘done’. Becoming self-organising doesn’t remove the need for management.

Magic Milestones Delivers 5 More BBC Sites

Tuesday, April 21st, 2009 by Nici

bbc-mundo-portada22

The Magic Milestones team at the BBC have been working hard over the last few months alongside World Service Future Media to re-launch 12 of their language sites in 1024 format and in a new, improved Content Management System.

Following on from the launches of BBCPersian.com and BBCBrasil.com, the team have had a launch-crazy last 6 weeks, launching 5 more sites.

BBCVietnamese.com, BBCUrdu.com, BBCWorldService.com, BBCMundo.com and BBCRussian.com were all project managed by members of the Magic Milestones team, and were all run according to Agile Methodology.

The sites are mainly news sites focusing on getting cutting edge journalism to all over the world, with the exception of BBCWorldService.com which is a support site for the extensive World Service radio network.

The intensity of the project put many demands on the team, and it’s a testament to their dedication and hard work that the sites look fabulous and that they managed to keep up the pace during this busy time.

Of course the hard work doesn’t stop here, and all involved have quickly moved on to working on the next wave of language sites to go 1024. Watch this space…

10 pointers for Agile Design

Thursday, April 2nd, 2009 by admin
  1. User research is imperative but not ad infinitum - set limits
  2. Interation with development should be informal but large scale changes need to be managed via the iterative planning session (e.g. Sprint Planning etc)
  3. Use artefacts to communicate with clients and the team
  4. Use paper prototypes to find out what works for users
  5. Too many designers spoil the user experience
  6. Documentation should be based on what is required at that particular moment
  7. Don’t invest tons of time in mock up early on as it may have to be undone later
  8. Track design somehow but be aware that using similar techniques to engineering tracking can lead to issues as design often comes together late in the day resulting in a mammouth burn on the last day - meanwhile the project manager is already pulling his/her hair out. Understand the differences between engineering and design tasks
  9. Don’t be afraid to show the customer stuff early - just set the expectations and ensure that they don’t cling to designs before these are solidified.
  10. Have courage, be transparent and remember that everyone is headed toward the same objective of a successful project