Skip to main content

Alexandra Stokes' Software Misdemeanours

I arrived with a jolt in the IT industry on April the 21st 1997, I had finished my final year of university as an exchange student in Nottingham, UK (from Monash University in Australia). I was culturally enriched from my UK Uni experience, it was a time of great partying, house sharing, fun and music and ‘Brit Pop’ was peeking. I could fake a neat English accent, I was ready to work and too broke to buy a ticket home.

I got a job as a analyst programmer for a UK consulting company (now US and called ‘Keane Ltd’) and worked on a couple of Workflow and Imaging projects. My first big project where I had to produce some code of substance was a traditional waterfall project at British Airways, and it had lots of other characteristics that made it a disastrous prospect - it will no doubt feature as it’s own article on this blog- at the time I recall it wasn’t a pleasant experience.

Now as a crusty sage with 12+ IT years under my belt I can look back and pin-point the reasons why it was a messy affair, at the time I just thought – yuck. I was just one of many developers and we all had a terrible time of it, the Project Manager didn’t seem to protect us at all from the furious-at-his-late-buggy-project customer and I had distinct thoughts about “doing a better job of this than her” at the time, an opinion that would award me my own battle scars not too far down the line!

During my career I’ve been lucky enough to meet some bright and inspirational individuals, many who have taken a chance on me and given me a leg up. My first career mentor Tony Harrop led a break-away faction on the Keane BA project to trial their first go at a DSDM project, he asked me to be the team leader and that was the start of my career path in IT management and the start of my passion for Agile Development methodologies. The project was a huge success and Keane became fans of using DSDM on their projects by evolving their own branded version.

A few years, roles and projects down the line, now a Project Manager with a DSDM practitioner certificate in my pocket, I started becoming interested in other Agile methodolgies. In 2001 it was the then economic down turn in Europe and there were a shortage of new projects in my organisation, and, dare I say it, a fear of trailing XP on any of them. You know what they say “If you can’t change your organisation, then change your organisation” so I looked around at who was doing more in the Agile space.

I joined ThoughtWorks UK in 2003, it was an incredibly stimulating experience, almost like an overdose of brilliant people, questioning old ways, trying new things and cranking out the most defect free software I had ever seen at a frighteningly fast rate to their delighted customers. I don’t want to paint an overly rosey picture however, it also had it’s difficulties, for example, I observed that sometimes “too many geniuses over analyse the pot” and smart people can have big egos, and sometimes the business people are left over to one side waving “hellooooo we are the business people….er….paying for the software!!” while the clever guys are vehemently arguing over technical debt and design patterns. But it was a great time of very nice interactions with passionate and dedicated people, and I’d never want to dampen the spirit of a group of people like that. They are without a doubt the world’s experts in Agile development concentrated in one shiny collective.

With ThoughtWorks I transferred back home to Australia in 2004, my husband Phil in tow, 9 years away from home was enough. I did a little bit of ThoughtWorking for them here in Aus, in between having my two beautiful boys Max and Leo.

This site is not the forum for the myriad of experiences I could share with you about my family, but it would be an injustice to them to say that all I spent my time on was a career break before returning to the industry to work in 2007. Growing my children convinced me to try a spell as a contract Project Manager, with a focus on the money, keeping an emotional distance from work and getting home at a reasonable hour to see them.

I was completely wrong about that, I joined the IT department of a fabulous little Insurance company that gets right under your skin and I’m still there running a team called ‘Project Services’. I currently have in my team and life; four Project Managers, three BAs, a husband who works part time in order to balance the life of his career-crazed wife, a nanny, some private childcare, a gardener, a cleaner and thankfully two sons that forgive me and are adorable company.

I am still an Agile fan, dyed in the wool and won’t give up the quest for doing things smarter and better with software development, but I’ve mellowed somewhat on the topic of waterfall projects. I no longer say “Waterfall projects are evil” I merely state “I don’t like waterfall projects”. I guess maturity comes with age.

I can genuinely say that with each success I’ve had in my career, and from every mistake I made, I’ve learned a little bit more. I’m also guilty of repeating some mistakes in my career and this is why I’m here.

Software misdemeanours is really a snazzy name for what is intended to be a collections of experiences and lessons I’ve learnt for having worked with software teams and projects for over ten years. I welcome all comment on anything I publish, but I would request you keep it polite and constructive, and please feel welcome to be funny.


Yellow Blade said…
Công ty vận chuyển hàng hóa nội địa chúng tôi xin giới thiệu các dịch vụ vận chuyển, dịch vụ ship hàng uy tín để phục vụ nhu cầu Tết của quý khách hàng. Cụ thể chúng tôi sẽ cung cấp dịch vụ chuyển quà tết. Chúng tôi sẽ giúp bạn vận chuyển hàng hóa đến tay người thân, bạn bè ở xa một cách nhanh chóng nhất. Đảm bảo giá cả hợp lý chất lượng dịch vụ tuyệt vời. Ngoài ra chúng tôi còn cung cấp nhiều dịch vụ khác như dịch vụ ship hàng cod, giao hàng cho shop, dịch vụ chuyển phát nhanh trong nước,... Nếu cần chuyển hàng hãy nhớ liên hệ với chúng tôi nhé.

Popular posts from this blog

Business Requirement Documents are just no good and should be abolished from the world of creating software

I had hoped the world could have wholeheartedly rejected Business Requirement documents by now. For too long I’ve seen the repeated scenario of only commencing the creation of a new initiative with a requirements document.Unfortunately most organisations that have teams developing software still use these flawed anathemas to creativity as the status quo. Despite agile approaches maturing and customer-centric modes of design emerging, requirements documents still persist. 
If you work in an organisation that doesn’t use business requirement documents any more, read no further. You are lucky; sense has prevailed at your place however in my experience, you are still the minority.
Let's face it; addressing this issue is not always the point you want to start your improvement work when there's much that could be dysfunctional with how a team is delivering software. But now, I find myself as mad as hell, and I'm not going to take business requirement documents anymore. I want to …

Gamify your children

Inspired by James Ross’s LAST conference talk on The Shamification of Lamification and the Reclaimification of Gamification I was motivated to try and “Gamify” the school holidays for my three children, Leo aged 8, Chloe 9 and Max 10.
Buy-in is everything, so the first thing we did was a quick workshop to extract the kids ideas. I asked them to write their ideas for good rewards on sticky notes, with a few examples for context, such as ‘trip to the movies or ‘play date with a friend’ . They had 5 minutes to come up with their ideas – one idea per sticky note (as always).
They then read out their ideas for all of us to hear, there were a few duplicates and also a few comedy suggestions. Even though we had ruled out crazy stuff, such as rewards of a million dollars, Leo had written down ‘A unicorn for the back yard’ reading it out with gleeful giggles.
Then they spent 5 minutes writing down tasks that they could do to earn rewards. By now they had the hang of it and quickly came up with t…

Agile Australia 2011 Series - Agile Governance

If you are in an industry that is heavily into governance you need some structure and process around your projects or you could find your Agile projects getting usurped by the culture of command and control. So it’s important not to shy away from the topic but to work with the entities that enforce and monitor governance. In this way you can create something that is fast and easy and not laborious to work with.I work for an Apra regulated organisation and we made keenly aware of our obligation under Apra to evidence documented change when audited. However in all organisations I’ve ever worked in, there are boundaries that bend quite a bit, ways to change things and ways to get by that satisfy governance process without crippling your agile process.There’s almost two alternating schools of thought here which are ‘work within process’ and ‘decide to change the process’. It’s actually pretty easy for my team to work within process. Project approvals, mandates and PIDs that are important …