Meet Calvin, the security guard with Hope...

Calvin, on the day he passed his Drivers Licence

Meet Calvin, the Fidelity security guard onsite at my company.


A few months ago I would not have thought I'd help someone out by providing a renewed sense of Hope, Trust and Faith in fellow citizens of South Africa...but somehow I did. I am certainly not feeling overly proud, wishing to boast this to the world, in fact, we're taught to keep the good that we do a secret, so that it promotes humility and gratitude to God that it was only by God's will that some good has come out of your actions. There's a saying that if you do a good deed, it should be such that your left hand doesn't learn what your right hand has done, so keep it secret...

But in this day and age, it's necessary to share the little good that has been done; and with the power of social media, perhaps the same act could be repeated by others, creating a stimulus for good and create further joy in this world. So I feel compelled to publish a humble success that I hope can lead to other successes. For now I've helped someone by creating hope, and instilling self-confidence, that no matter what one's situation is, given the right motivation and support, if you're willing to try to change your life for the better, you will succeed, even at the risk of failure, as one of my mantras that I repeat often goes "If at first your don't succeed, try, try and try again"

Calvin is the security guard at my company who manages entry/exit of vehicles into the car park. We got to know each other in the first couple of months as I was using a hire car at the time, and used the visitor car park quite frequently.  We only got to striking a good conversation when I braved the walk to the local Civic Centre offices in Randburg to enquire about my SA Drivers licence.  I say "braved the walk" because nobody in Joburg really walks anywhere, and I returning from the UK after 10 years, have grown accustomed to walking anywhere.  Against the concerns of some colleagues, I decided to walk the 800 metres to the Office, to get a sense of the security myself....suffice to say, it's safe and I've repeated the walk several times hence.

On my back from the Licence office, I spotted Calvin and waited for him, a) so I could chat and b) to have a security guard as company :-) On this brief walk back to the office, I learnt that Calvin spoke very well, had strong opinions about corruption and the state of the country, he was quite curious to find out about London. He was in awe about the underground trains and more so, when I told him about the level of transparency and accountability the politicians have with their constituents, that there is a strict control over corruption and personal expenditures, so much so that politicians public resign...he wished the same could be done in SA.

I would then stop at his post now and again for a chat, and one day in August I found him really stressing about his situation. He tells me how he's been a security guard for the last 6 years, how he wanted to study engineering and was forced to leave school at an early age when his father passed away...and now he's got his Truck Drivers Learners certificate that would soon expire (Dec 2011) and he's got no money to do what's required to get his Drivers Licence before it expires. I knew in my heart immediately that I should help this guy out, and told him not to worry, these things have a way of working out, and left him with that thought - went for my meetings, and returned in the afternoon to continue the conversation.

I learnt that Calvin was serious to change his life for the better. As a security guard, he'd become friends with many of the truck drivers the company uses, and so he was aiming to get his Code 14 drivers licence with the aim of working for a trucking company. Truck drivers certainly earn much more than a security guard, so he'd started the process of, had passed his Learners test over a year ago, but just didn't have the funds to go for driving lessons and do the exam.  He also wants to study engine mechanics -- I recommended he focus on one goal at a time, first get the licence, change jobs and then think about the next step...

Without consulting my wife, I told Calvin that I'll help him get his licence.  Obviously, to a seasoned South African, all alarm bells would be going off at that moment, around trust, being taken for a ride, taken advantage off, etc... Dismissing all of the negativity, I proposed to Calvin that I will contribute the majority of the costs towards the licencing, provided he contributes some of his hard earned money to the cause.

I didn't want to do everything (although I had the means to fully sponsor it), but I felt that if Calvin contributes some of his own money, he'll be compelled and motivated to work hard, and succeed... I also grew up in tough times, I value commitment and dedication, Nothing comes for Mahala...

With this contract in place, we worked together on a plan of action and aimed that by end of November, Calvin should have been on enough driving lessons to be comfortable with taking the final exam.  Calvin surpassed expectations, and with five lessons managed to pass his Code 14/C1 Drivers exam!  We were both beaming with joy that day - you can see it in the photo!

Proof!

So what costed me just under R2000-00, which I could've easily used up on toys and take-aways, I helped enabled Calvin to step out of what was a depressing situation, and instil a renewed sense of hope.

It's not over yet...
Getting his licence is the first step. My aim is for Calvin to land a job by the start of the new year.  He must leave his job of Security Guard of the last 6 years, and take the plunge into a world full of possibilities.  I will continue to look out for Calvin, my company has a campaign called "Be More" and I'm going to send this blog post to the senior management and HR to see if the company can reciprocate or think about setting up similar initiatives...
I am also going to contact Talk Radio 702 to see if this is an example for Lead SA...

Doing more for South Africa...
When I left SA to work overseas, one of my ambitions was to return home and add a valuable contribution socially and professionally. I've made a humble start with the social aspect, but I do have bigger ambitions for the helping the professional outlook.

I'll post about this topic later, but I have a bee in my bonnet with the lack of skills/competencies in the IT/Software development field...I was really surprised that much of the workforce in my current company is outsourced to contractors from India, that there isn't any talent in our country. I blame the schools and tertiary institutions for not doing enough - so much so - that I strongly believe that it's a waste of time and money to go to a SA university: If you're interested in IT or programming, teach yourself, become self-taught, work on Open Source Projects, that's your ticket to landing a decent job and earning a salary...I've been mulling over setting up an Open Source Software academy where people can learn from high school, real world software engineering, contributing to real world projects without needing to attend University...

Agile Project Management with Scrum by Ken Schwaber

Agile Project Management with Scrum (Microsoft Professional) is a well written, easy flowing book that is clearly borne from someone whose had first-hand, real-world experiences of running and managing a variety of Software Projects over a number of years, Ken Schwaber, who is considered the father of Scrum who humbly takes no responsibility for being assigned that title, and so points to much earlier endeavours of many people, pointing to Babatunde's Process Dynamics, Modeling & Control for his first oral presentation of the theory behind Scrum; and sites Degrace's Wicked Problems, Righteous Solutions as the first people to call Scrum Scrum.

Regardless of who is attributed to formalising the Scrum processes, it is a software development methodology that is here to stay, and anyone working in software projects not familiar with Scrum should indeed rethink their strategy. Still, with so many books out there claiming to distil the secrets of Agile/Scrum, finding the right book is indeed challenging -- as with so many books, people focus on the theory without expounding on the practice, the real-world experiences and encounters that as a manager, and especially as someone transitioning from classic project management principles (not necessarily connected to the Watefall process of software development).

This book is definitely different, one that I recommend and fully endorse 100% - so if you're reading this and don't have a copy, get one now!

Why do I like this book so much?

Well, as a developer I'd worked on many projects of different styles, more recently explored with Agile/XP concepts. I've been on training courses, presentations & and participated in practical workshops such as the agile lego game. I've contributed as a developer, lead certain development efforts with a few engineers, then later went on to managing development projects using Waterfall as well as Agile; and more recently came off a massive project with 300+ people, where at the macro-level applied Agile/Scrum principles across the programme, but I didn't have much involvement in the day-to-day planning with individual component teams, where we'd assigned team leaders to act as Scrum Masters. We maintained one huge Product Backlog, not so different to that as Ken describes in Chapter 9 Scaling Projects Using Scrum.  We were developing a product that would deliver to multiple customers, each customer adding unique features contributing to the final feature set, the product itself would service tens of millions of homes -- so we had a strong Product Management group maintaining the heartbeat of the multiple projects using Sprint Time-boxing. We had macro daily planning and status updates, call it Scrum of Scrums.  So I was pretty much focussed on the high level programme and product management, than the low-level activities that a Scrum Master would normally be dealing with, I'd instruct as necessary....

As I was moving to a new job that placed me in a Scrum Master role, I needed to brush up on my Scrum Master knowledge and needed to prepare or translate my heavy Project Management experiences to Scrum principles. This book was certainly written with that purpose in mind. I was looking for real world use cases and reflections of actual projects, something that Ken describes well.

Ken touches on the key concepts of Scrum by using example projects as references, with frank and honest feedback. He includes much of the areas that would trip someone up coming in cold to Agile, and also does not dismiss the value and usefulness of applying the rigour of classic project management dogma (reporting, tracking, metrics, predictions) as old-school, out-with-the-old, in-with-the-new.  In fact, Ken advocates entirely the opposite of that. It certainly takes a while to master Scrum as a Scrum Master, and therefore takes much longer for a company with seasoned managers who know no better, to transition and accept Scrum from day one.  So as important stakeholders in the project and business, these people have a right to be given information in a format that is understandable, and this too, can still be achieved using Scrum.

What really resonated with me was...

Ken has re-affirmed much of my own understanding in that Agile/Scrum is no excuse to cut corners. Scrum is not a short-cut from applying rigour and due diligence.  Way too often, people who are either new to Scrum or have been previously burned by management, fall in love with the concepts of Scrum, especially the tenets of autonomy, freedom and do-what-it-takes attitude to get the job done, immediately put up barriers when someone starts talking about processes...

• "Oh that's waterfall approach, we are young developers, we don't do it like that anymore. We are light on process, and don't need documentation. We don't need to have a process for teaching new engineers, it's a collective, the engineer will be absorbed into the team and learn on the job. We don't have release notes any more, it's automated by Git. We don't need a version numbering system, Git labels are fine. We don't do need pre-planning, we do just enough because it's going to change anyway...."

Principles I connected with...

• The importance of taking time out to produce a Product Backlog early in the project. The argument of not knowing what you're creating because it's unknown is not good enough. Even if you're aiming to brainstorm to produce an initial Proof-of-Concept (POC), that POC is driven by meeting the high level needs of the Product Owner, so it is not an impossible activity to put thoughts onto paper, call it your wishlist, to-do list, whatever - there must be a Product Backlog to start with...how else do you determine the goals, and measure your progress accordingly??  So if you think you're doing Scrum and don't have a Product Backlog, then please go back and reconsider what you're doing...

• Ensuring the Roles/Responsibilities are clearly identified - especially the ownership of the Product Backlog - Is your project big enough to have its own Product Owner, or is this also something the Scrum Master can absorb?? The Product Owner's role is pivotal to setting feature priorities only, but not responsible for driving through scheduling or people management. That is the Scrum Master's job...So spend time to clearly outline the roles and responsibilities...

• Spend enough time Planning - the planning process described by Ken is a useful starting point. Spending a full day on planning and getting the team to uncover the tasks before the Sprint begins is definitely valuable.

• Due diligence must be followed by Scrum Master - measuring progress and reporting on progress, generating metrics and predicting the future are essential aspects to Scrum Management.  Don't be fooled by Scrum being lighter than classic project management. Scrum teams still have a responsibility to meet business objectives, how you go about doing it is the Scrum teams own business, but when asked with business-type questions, then the Scrum team better have enough data to provide professional responses

• Don't misuse Waterfall defence mechanisms - who says you don't do requirements/design/testing - Scrum says you ensure enough is done during the sprint such that at the end of the Sprint you produce a release that is shippable - so a Sprint must support requirements/design/testing/validation/release - same steps as waterfall, but it's constrained to happen within the sprint itself. Of course, one doesn't have to have heavy processes, but it is about applying core engineering principles.

• Self-organising teams are difficult to create, and takes time to master.  As a Scrum Master you have to continuously monitor the team's performance and interactions.  The hard truth is that in the real world, using distributed development or even multicultural teams with mixed permanent/contractor staff, a truly self-organising team is a rare find.

• Common sense - a large part of Scrum is essentially maintaining a common sense and pragmatic approach to things.  One doesn't have to be a certified Scrum Master to manage Scrum projects, but care should be taken in obeying & applying the rules of Scrum, which Ken concludes in Appendix A:
• The ScrumMaster is responsible for ensuring that everyone related to a project, whether chickens or pigs, follows the rules of Scrum.  These rules hold the Scrum process together so that everyone knows how to play. If the rules aren't enforced, people waste time figuring out what to  do.  If the rules are disputed, time is lost while everyone watis for a resolution. These rules have worked in literally thousands of successful projects. If someone wants to change the rules, use the Sprint retrospective meeting as a forum for discussion. Rule changes should originate from the Team, not management.  Rule changes should be entertained if and only if the Scrum Master is convinced that the Team and everyone involved understands how Scrum works in enough depth that they will be skillful and mindful in changing the rules. No rules can be changed until the Scrum Master has determined that this state has been reached.

Watch the man himself here @ GoogleTechTalks:

Managing a Digital TV Programme: Consideration for Project/Organisational Structures...

Following on from my recent post on the role and placement of the "architect" in a DTV systems project; in the same vein I'd like to expound on the role of the project team in the same end-to-end system delivery, touching on overall organisational structure, considering the concepts of:

• End-to-End Product Owner
• Feature Product Owner
• Component Product Owner
• End-to-End Programme Manager
• Headend Programme Manager
• STB Programme Manager
• Headend Component Project Manager
• STB Component Project Manager
• Headend Scrum Master / Tech Lead
• STB Scrum Master / Tech Lead

The collection of some or all these roles will make up your DTV Project team. These roles might each be performed by a person each, or we might have someone performing multiple roles.  Defining these structures up-front at the start of the project is considered Project Management 101, but you'll be surprised there are real world projects operating today where time, effort and preparation hasn't been invested in defining these organisations structures, and are operating in a quasi-chaotic state. I've been on projects where people run like headless chickens, not knowing who's responsible for what, where the boundaries lay in terms of roles and responsibilities, where due diligence isn't practiced through the overall programme: architecture, development, integration, testing & delivery...

The question of whether these roles are managed by a specific organisation unit like your classic Project Office or whether these roles come together naturally through different business units and operate as a virtual project team -- is outside the scope of this discussion.  My aim with this post is to highlight from my experiences what seems to work for DTV projects involving a launch of a new platform like VOD, or replacing old Middleware with new; again with more of a bias towards STB software, although the Headend will not be so dissimilar.  In essence, this can be drilled down to generic component product development at the micro-level, and at the macro-level these are rolled up in the end-to-end system as previously highlighted here for architecture, and the figure below that shows largely how a project team can be structured around the system.

It doesn't really matter about the internal business organisational structure, what matters is that the project has a defined structure and that these roles exist; the roles and responsibilities are well defined and clear, ownership and accountability is understood by all parties, that everyone is connected and on the same page. Of course you'd think this is Product/Project Management 101, that this is a no-brainer -- not so. 

In my experience, companies don't always have this done right, yet you might argue that products are still successfully launched, projects executed and closed, etc. Indeed, but IMHO such projects generally rely on a few individuals that go above and beyond the call of duty, the proactive, driven by a sense of urgency to get things done; filling in the gaps in process & roles -- that companies have grown to depend on.  Whilst this is great and generally seen as heroic efforts, the fire-fighting and critical moments can be saved if a little time is spent up-front by defining & clarifying the project structure.

Again, in the context of DTV projects - the structure depends on the viewpoint.  In general, if you're a broadcaster / PayTV operator (BSkyB, DirecTV, Multichoice, etc), you will have to implement a detailed project team as there is a much wider impact on the business (development, lab, testing, validation, going live, operations, support, customer service) than compared to one of your vendors (NDS, OpenTV, Irdeto, etc). If you're a Professional Services outfit acting as Systems Integrator and ultimately responsible for the delivery of the project, then you might have to mirror the same project structure of your customer.

Let us look at a picture to see where these roles can be placed. Notice this map is exactly the same layout as the architects post:

Figure 1: Overview of DTV System highlighting Project Roles

If you're an Operator focused on content delivery only, then...

You generally hire a System Integrator to manage the design and end-to-end delivery of the system on your behalf. These operators make a conscious decision not to be technical experts and thus rely on preferred partners to manage new development and operations.  The operator would still have someone who's responsible for product ownership, which could be someone from Marketing/Sales. There would also be a Programme or Project manager assigned to manage the project.

This is typical of first-time operators entering the market from cold, there are some professional services companies like NDS, who can manage not only the end-to-end systems development or customisation (generally this is off-the-shelf to enable shortest time to market, followed by product updates post launch) but also able to commission a broadcast centre and operations control from scratch...

So essentially this is an operator that outsource most of the Delivery Project Management - the organisational structure will pretty much be the same as Figure 1.

If you're a mature Operator with an established product and adding new features, but without technical ownership, then...

This scenario again relies on the Operator leaning on preferred partners for providing the technical solution, possibly spanning multiple vendors involved in development of components, system integration, delivery and deployment as well as operational support.  There would be a Product Owner / Manager that defines the high level requirements for the product's feature set. There could also be a Project Office team that takes ownership for the overall co-ordination effort from start to finish, or this could be outsourced to a professional services company to manage the whole project.

Some Operators have separate business entities owning features of the overall value chain, so the primary product spans multiple product owners. It becomes more challenging to manage this distribution of product owners especially when trying to manage an consistent brand and user experience, and coherent presence in the market. But companies are doing this today, it works to an extent, the key being effective communication is pivotal to successful product launches.

Generally though, in this scenario, the Operator has established strong relationships with its vendors, and projects may follow a typical template plan that would be driven by a Project Office team.

You might find the Operator would enlist a Project Board to manage the project's priorities, resources and budgets - that a Product Owner/Manager and Programme Manager reports and takes direction from.

Again, the project organisational breakdown will follow Figure 1.

If you're a mature Operator and responsible for developing and delivering new features, with technical ownership, then...

This can be very complicated and challenging if this is the first time the Operator is responsible for technical ownership. As touched on in my previous post, more and more Operators are taking more ownership in managing DTV projects, around the area of STB & Headend Systems Integration, EPG Development, Interactive Applications development, and some Operators are even developing their own Middleware.

In this scenario, it then becomes fundamental that the organisation starts on the correct footing, ensuring the foundations are cemented correctly, processes and practices firmly put in place as early as possible -- not doing so will definitely result in chaos, which I personally have come to label a "Project Fiasco".

So the roles I'd expect to see an organisational structure clearly defining the Architecture roles, Development, Integration and Testing; as well as a well defined Project Team.

I would expect to see a variant of Figures 1, 2 & 3 for the organisational structure.  There will be interaction with vendors. The relationships, roles & responsibilities must be explicitly communicated....

If you're a Product Vendor that delivers components to Operators, then...

Product Vendors are generally companies that provide software components for STB or Headend components that enable the Operator to function.  As a Product Vendor, the challenge is to internal manage your development organisation to maintain a consistent product line offering features that can be easily customized, tailored or profiled in or out to meet the requirements of your customer, the operator. Typically vendors manage multiple customers. Some customers more important than others - the customer usually generating the most of amount of revenue is assumed the lead customer, if not, the customer that in fact drives forward your product development and innovation.

Vendors typically have a Customer Delivery Manager assigned as an anchor support point, interface to the customer. This Delivery Manager ensures the customer's requirements are accepted by the product development team, and ensures the resulting plans are in accordance with the customer's expectations.  The vendor may choose to use a Product Steering Group that ultimately makes the decisions on customer priorities. Depending on the extent of the products being supplied by the vendor, I would expect to see an organisational structure not so dissimilar to Figure 3.

Brief Definitions

• Product Owner / Product Manager
• Operator - responsible for defining the user experience, high level requirements of the features for the product. For example, Operators looking at VOD will have a Product Owner owning the feature set, along with priorities. The Product Owner takes direction from the Project Board or even the business in understanding the market priorities and urgency of the business w.r.t. launch targets. The Product Owner / Manager will use the services of the architects and project team to get the product specified, designed, implemented and ultimately delivered.  The extent of ownership is around product specification only...The Product Owner/Manager gets actively involved in prioritizing defects leading up to the launch phase of the project, setting priorities, accepting waivers or concessions, etc.

• Vendor - as a vendor, the Product Owner / Manager is different to the role taken on by an Operator.  As a vendor, the Product Owner is concerned with satisfying as many customers as possible, without much deviation or customer-specific features; and will work hard to maintain a consistent offering. The Product Owner generally consists of a Product Team that centrally manage the product backlog. Depending on the size of the projects and demands from customers, this could be one person, or a team of people. If it's a Headend component with specific technical requirements (generally Headend component is a translator - data in, data out component) that implements a protocol, then this could be one person.  However, if this product is a STB Middleware that must sustain multiple customers, and potentially support tens of millions of boxes, then you'd need a separate team managing the product. This Product Management team will own the roadmap for the project, control the work assigned to customer projects, and ensures a coherent release schedule.  The team will also ensure the product specification and requirements are kept-up-to-date supporting the generic product as well as the customer's profile of the product. This Product team will consist of project managers driving through the product roadmap.

• In some cases the term Project Owner / Key Accounts Owner / Customer Delivery Manager is used which basically is the person who's neck is on the chopping block - i.e. the person accountable for the project delivery, who has seniority to make judgement calls to steer the project along in his/her preferred direction, etc - basically the ultimate person in charge, the "X says so" person...

• Programme Manager - this can be generalised both from Operator and Vendor side - and is typically the person responsible for the high level planning of the various work streams that make up the ultimate delivery.  There can be Programme Managers for each system, primarily Headend & STB, as well as managing the overall End-to-End delivery plan.  The Programme Manager works side-by-side with Product Owner in understanding business priorities, but the Programme Manager has autonomy in defining the plan and driving through the execution of that plan.  Programme Managers lean on their respective project managers to take responsibility for the detailed planning that delivers on the high level milestones.

• Project Manager - is responsible for planning, managing and driving through the deliverable of the assigned component/project. Reporting and taking instruction from the Programme Manager, the Project Manager handles the day-to-day issues/planning/tracking, escalating to next level (Programme Manager) as required.

• Scrum Master - can be a Project Manager or Team Leader employing the philosophy of Scrum/Agile to get the component/project team to deliver according to the milestone plan put forward by the Programme Manager and Project Manager. 

What a Product Owner / Manager is not responsible for...

When not acting in the capacity of the Project Owner, i.e. the main person accountable for the success of the delivery, then the Product Owner / Manager should only be focused on managing the Product requirements and Feature set, setting expectations and aligning priorities.  A Product Owner has no influence on the resource structure of the team, the scheduling of the development....that's what the Project Team, including the Programme Manager is there for - the Project Team provides a service to the organisation...Depending on the size/complexity of the deliverable, in DTV projects, they are large enough to warrant a clear separation of boundaries between Project Team & Product Team....Having people stomp on each others toes is not conducive to productivity...

We are an Agile Company, we don't like heavy Project Organisation...

Sure, depends on what kind of company you are. If you're in Application Development writing EPG UIs or Interactive applications, then of course, you can be light on the ground.

If you're in the Middleware business and big enough to be mentioned in the same sentence with NDS, OpenTV, etc -- and you don't have these structures in place, then you're at a competitive disadvantage. I have worked on small and large projects alike, the lack of a clearly defined and sensible Project/Organisation structure does not work...you might reach there eventually through luck, a lot of hard work and unnecessary fire-fighting...

For Operators taking the plunge at taking more technical ownership in your projects, my advice to you is "Do your homework". Spend time up-front investigating, planning and settling on a processes that has been known to work, i.e. proven - by getting real consultants in to advise...By real consultants, I mean not the people who know the theory but have never managed a real life project from Start-to-Finish, not someone who's never worked in the DTV industry before...Invest in the right people up-front, employing or head-hunting candidates who have first-hand experience and proven track records, and pay heed to the advice henceforth...

Typical Project Org Structure for a typical Operator

Below is a simple model of how an Operator might define an Organisational Structure of a DTV project...

Figure 2: A possible Org/Project Structure from the Operator's viewpoint

Typical Org Structure for a Vendor supplying components...

Below is a complicated model of a Vendor who's main business is STB development. Some vendors specialising in components in specific components will own a slice of this structure...

Figure 3: Org/Project Structure from a STB Software Vendor's Viewpoint

PDFs of Diagrams

Figure 1

Figure 2

Figure 3

Your Feedback

Please note my posts are always based on my first-hand experiences from past projects, and is a reflection of reality instead of theory. I am always interested in feedback, please feel free to comment or rate this post!

My first taste of crime in South Africa...

So it's been about six months since we moved back to South Africa and 3 months in our current house, and last weekend we experienced our first encounter with crime. It could've been much worse considering I've not yet sorted home and contents insurance out, so by the Grace of God, we got off easy in the grand scheme of South African crime...

We left home (Johannesburg) in a hurry on Friday afternoon (4th November) to drive up to Pietermaritzbug (6 hour journey) to spend Eid-ul-Adha, the festival of Sacrifice with family. It'd been 15 odd years since I last took part in Qurbani (the slaughtering of a sheep/lamb/cow) and I was going to slaughter an animal for the first time in my life. My kids have never witnessed such a thing before, very difficult to do practise this in UK...so we were all excited.

We had a wonderful Eid, returned home on Monday evening around 5PM. Being tired after the long journey, I didn't quite take notice of all the light entering the dining room and lounge. I'd deactivated the alarm on entry and getting the bags in, when I noticed the strange brightness coming in from the other room. I open the door, and to my amazement saw the dining room door wide open, the glass shattered and the outside gate wide open with the keys left hanging - we'd been burgled!

I quickly look around the house, it seemed the burglars only touched the lounge and dining room, not even the computer room (I wouldn't be typing this if they had) - and they got away with my PlayStation gear and wireless keyboard. The TV unit was shaken up a bit, but apart from that everything seemed in order - how odd, since the computer desk is in the lounge directly opposite the TV, I had my sat nav, photo frame and gadgets lying in plain sight...The only thing I could think of was the alarm had scared them away.

So I called the landlord to report the incident, then my alarm security company, who then alerted the police. I spent all of Sunday evening walking through the scene, testing the alarm, holding the security company to account, even doubting myself whether I actually activated the security system before leaving...Spent the night at my brother's place, next morning the so-called forensics team "fingerprint" experts came and went in like 10 minutes, I had to show them where to lift fingerprints off. Then the inspector came over to have a chat, he was equally baffled and blamed the security company. Spent the rest of Tuesday fighting with the security company and had the door fixed...

This morning the technician from the security company came over to download the event buffer from the alarm system. They were right, I was wrong. Actually the alarm was activated, but there were no reported incidents between Friday and Monday. I then tested some theories out and uncovered some serious loopholes with the system. If you enter the house, and crawl on all fours from the point of entry to the TV room/lounge, the sensors will not pick you up...so that's how they did it.  Now I need to get more sensors installed, more panic buttons and possibly a few more burglar gates and doors...welcome to South Africa!!

What's really scary though is that why hadn't they cleaned me out?? Why take only the PlayStation gear?? Why not come again and again?? The house was available the entire weekend - we have no idea when it could have happened. The neighbours didn't hear or see anything unusual...

Like I said, it could've been worse.  Houses are ransacked whilst people are fast asleep in their beds.  Better to have it happen whilst you're not at home, because you could lose your life...

So on the crime front, UK 1, SA 0.  But such petty crime is also rampant in UK, it could happen to anyone...In Islam, we believe that sometimes these small troubles happen in order to prevent or save you from a bigger calamity, that events are interconnected, and God has His plans and reasoning...We also have a saying to "Trust in God, but tie your camel!". In my rush to beat the traffic on Friday I didn't take the security precautions I usually take of taking all my keys with me, closing all the curtains, and leaving the property reciting verses of protection from the Quran...I also haven't sorted home insurance out...

Here's some pics of the incident:

Point of entry

Note the stone & towel used to break glass, bugger left his hat for show!

TV Area, good thing still got UK plugs

Burglar gate - bent bar

Used my ladder to scope out the bedroom 

TV unit, bottom left had Playstation gear