When Agile goes wrong...

When Agile Software Development goes wrong?? Really, Agile/Scrum is the best thing that's happened to the softwared development fraternity, how can it ever go wrong?? It's the latest trend (not exactly, it was the latest straight after XP eXtreme Programming, but the current latest trend is a mixture of Agile and Lean development or Kanban, so much so that some people are calling it "Scrumban").

Let me point out that I am a huge promoter of Agile/Scrum, have seen it in action from small project teams (less than 12) to large-scale projects with 200+ people distributed across the world - Agile/Scrum does work, it's basically common-sense pragmatic practices, with the aim of getting the product development right early on, involving early requirements feedback with regular customer interaction, continuous and incremental testing, etc, etc.  You can find a lot of reading material online or many books published on the topic.

I feel that some people are too quick to jump on the Agile/Scrum bandwagon, after reading a book or going on a quick training course covering the essentials of the methodology.  This is where the danger comes in - when newbies fresh into the concept after being exposed to the classic style of very well-structured, co-ordinated and controlled project management practise of software development -- are keen on dropping all concepts done under what is now generally labelled as classic "Waterfall" development, and whenever challenged with understanding or improving the project processes, people are just too eager to show the "Waterfall" trump card: "That's Waterfall, we're Agile now, we don't do it that way..." - and basically this drives me nuts sometimes because people don't fully appreciate what these terms mean, quick to dispense with the "Agile" vs "Waterfall" cards, especially when these remarks come from people who really cannot call themselves seasoned experts, or seasoned developers that have consistently released real-world products into the market, not only experiencing the development phase of the product life-cycle, but also the ongoing maintenance, support and upgrading efforts that result from a successful product launch...

Let me come back to topic. So how does Agile go wrong??

Firstly, as stated above - newbies start the process, without much thought or planning, or without grasping the inner core of what Agile/Scrum really means.  They basically fall in love with the Agile manifesto, and because of being heavily managed on previous projects, adopt a mindset that is close to the euphoric 1960s where everyone is basically free to do what they want, respect and love the team, allow the team to self-organise and self manage...

Lets look at the Agile Manifesto again, as I'm going to touch each point in context of my real world experience, especially with Set-Top-Box software development:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

What else can cause Agile to go wrong?? 

Essentially this boils down to being in love with team freedom and dynamics -- and forgetting that even with Scrum, there is some process overhead.  The fundamental driving force behind driving a project with Scrum, is the Product Backlog.  Not only do you need to have a Product Backlog, you need to have prioritized Backlog, owned by a Product Owner, executed by the development team through the guidance of a Scrum Master (usually this is someone who's come from leading a development team as team leader, or an old-school project manager looking at managing software projects with a fresh eye).  The backlog is not a list of requirements, the backlog is a list of work packages, use cases or stories that describe a piece, area or feature of the product that can be done in a short amount of time (i.e. a Sprint) that can be developed, tested and demonstrated at the end of the Sprint.  The backlog is not a ToDo list of atomic requirements for burning down...

Any intro text on Agile, as in Agile Project Management with Scrum (Microsoft Professional) expresses the importance of maintaining an up-to-date, prioritized backlog, owned by the product owner who is supported by the Scrum Master - a missing backlog is a fundamental flaw in a team's adoption of Scrum/Agile...

What else can cause Agile to go wrong??

So we covered over indulgence of the manifesto; missing product backlog for Product and Sprint planning.  The next thing that goes wrong is not enough pre-planning the Spints: What are we doing now, and what do we plan to do next??  Despite the flexibility of Agile, sprints must execute fluidly, systematically, almost like clockwork. The sprint process should be almost natural to all on the project team.  Poor planning up-front in identifying the possible stories to focus on the next sprint, doing the due diligence to ensure that for the upcoming work the team will be as free from impediments as possible.  Planning is not just choosing a bunch of requirements that people like to do, it's about sitting with the Product Owner and agreeing what is desirable for the next Sprint.  Poor planning and not identifying the work packages before the sprint, that is, not doing pre-preparation is likely to result in blockages, waste and inefficiencies during the sprint, resulting in less than optimal user story completion, injecting obscure data into your metrics gathering for predicting throughput/velocity of the team...

What else can cause Agile to go wrong??

The size of the teams.  Put 30 developers & testers in a team, and controlling that is going to be challenging, especially when a)No real structure to team; b)No backlog; c)No Pre-planning.  It gets worse when the team is further segmented into different teams, Team A, Team B, Team C - all get to choose which "requirements" to work on for the next sprint. All being managed by one or two Scrum Masters -- this brings with it communication challenges obviously, but also poor team dynamics. Instead of having people with cross-functional knowledge of the stack, instead we get people specialising in certain areas, with a natural tendency of reluctance or insecurity to work in a different area of the product.

Is that all I've got?? No - there is one more thing that can trip you up: using the wrong metric to measure performance of the team.  With the absence of a prioritized backlog of user stories, some projects use Requirements Implemented as a measure of progress - so much so, that when reporting progress, we report on X/Y requirements done, not what is more important that being features completed.  Some projects even predict the number of people requirement, and use "One requirement per developer per day" and base their argument that over time, this value averages out and can be trusted.  Thus, number of requirements completed is measured for team output, and with a fragmented team, this measurement is per team, not per project.

I am of course talking from experience. In fact, I am experienced this Agile mentality in my current job, thankfully with the help and assistance from another scrum master, between the two of us, we have slowly been instigating changes, turning things around such that we now have a Prioritised backlog, we now focussing on use cases and stories, we're now measuring throughput in terms of features, and we're now doing some pre-planning. It's not perfect but it is a start, hopefully in the right direction....it's not yet smooth sailing though, because management have pulled the rug from right under our feet by changing focus to implementing a brand new UI. Good thing we're doing agile and we can deal with uncertainty....BUT....

BUT Agile is not easily applied to Set-Top-Box development projects, especially when the aim is to launch a new generation EPG, Middleware and new hardware.  Changing requirements almost two years into the project whilst still expect the team to still deliver to original time-scales is woefully optimistic to say the lease, but management have also misunderstood Agile, and flaunt the term willy nilly, assuming that the team is flexible and can cope with change!

Why is a STB project a difficult Agile Project when you've fallen in love with the Agile Manifesto?

A STB project involving new hardware, new middleware and new EPG is NOT like writing a web site or a smartphone application.  You don't have the luxury of setting up test websites, beta sites to ask for feedback, neither can you release and retract a release because everything is on the server for such web apps. STB projects are intensive, expensive, involve a lot of third party vendors, and thus realistically implementing core Agile principles from the outset is going to be difficult. I say difficult, but not entirely impossible -- however, it comes with a lot of management and administration overhead to indeed run a true Agile STB project.

Of course, assuming one has all the components like Hardware, Drivers, Operating System, Middleware to a mature state of completion, then you can definitely run an EPG development project using Agile/Scrum, assuming of course, you have a clear picture of the end goal. A clear picture of the end goal, doesn't that defeat the purpose of using Agile/Scrum then?? Yes, in some ways - but remember, we're aiming for time to market here - if we keep changing our minds, launching a product is not going to happen to plan, especially when the underlying implementation might need to be extended, changed or remodelled to fit the changing requirements of the EPG application.  I will expand on EPG design in a future post...

If the EPG & Middleware are under development, then you cannot escape notion of pre-planning: work out what the dependencies are in advance of each sprint. Ensure that Middleware development leads EPG development, ensure there is a path to the teams for communicating and resolving issues, etc...

If the Graphics Design, EPG & Middleware are under development, then you add another layer of sprinting for the graphics team, such that the graphics team leads firstly the middleware, then EPG.

If you're in the business of documenting every requirement for each layer of the stack, then you'll have to either specify the requirements up front, but because the graphics design and user experience is open to interpretation, requirements cannot truly be closed or published, unless the team have been through an iteration or two of proving and testing.

Lets look at each point in the Agile Manifesto

Individuals and interactions over processes and tools

Yes, this is all well and good when the team is small, but when you have a team that is more than ten, say thirty individuals who are a mixture of full-time and contractors from India, not local talent - then you will need to have processes for communication, planning and tools for enabling collaboration.  EPG development does not end at the point when development is complete, there is a strenuous batch of user, hardware and security acceptance testing that must take place to get to launch candidate. Changes that come into the product needs to be controlled and managed, hence there needs to be a change request process in place. You cannot just have a whiteboard with post-it notes posted to keep track of development, you need an audit history to refer back to when it comes to maintaining and enhancing the product in future.  Within the local development team however, to get the job done within the sprint, then the team is free to do what they want or need to do to get the job done and show something visible at the end of the Sprint.

One also has to be careful with the amount of freedom given to the team. A self-organising, self managing team does not happen overnight. Of course, management must provide enough autonomy and leeway to make this happen, but if the individuals within the team do not have the talent or competencies to self-organise, take initiative on their own without having to follow direction, that they understand the big picture and are in-tune with the overall goal of the company and project -- then you will find it difficult to have a self-functioning team.  Instead they will look for direction from a senior person, be it the team lead or architect.

On the subject of architecture, the architecture and design patterns that underpin the software stack must have a central owner, the one responsible for the technical integrity and coherency of the architecture.  Yes, the architect must accept enhancements and open to criticism, but the architecture must be documented in sufficient detail to allow people to make a valuable contribution.

A design review process must be in place for the EPG - at the start of any new work, the concepts must be dicussed and a design review held. Important architectural changes must be documented as this is fundamental to the future maintenance of the EPG.

The make-up of the team is important - Contractors are there to just get the job done. Don't expect them to gel well, form a self-organising team and help the scrum masters in getting the backlog burned down on their own initiative. The more work contractors have to do, the longer they stay in a job.

I don't think all of the old-school of development is dead, that's why Fred Brook's The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

, especially the essay on The Surgical Team and other parts of the book dealing with people issues is still very much relevant today.

Working software over comprehensive documentation

Yes, we all want that. An EPG needs to be sufficiently documented not only in terms of architecture and design, but also on user manuals that enable independent third-party testing.  Comprehensive where necessary in terms of describing the requirements from third-party component vendors, less detail when the team is local and in control of the development. At the end of the day, a working product is needed as we can all agree, it makes common sense - but for the maintenance and enhancement teams down the road, sufficient documentation is required to enable the longevity of the product.  It becomes especially important if the development team consists of a bunch of contractors not loyal to the company or product.

Customer collaboration over contract negotiation 

If you own the EPG in-house, i.e. you're the customer - then of course, collaboration must happen regularly.  But even in places where this is the case, the company is fragmented into different departments, each with their own expectations of the end product. Sometimes, as happened in my project, a year and half down the line, people took note of the product's deficiencies to make a U-turn and almost start-over again.  Regular feedback must take place.  However, in the case of a third-party supplier, then contracts must be negotiated as part of any good project, it is project management best practise after-all. You have to know what you're signing into or signing up for, and take necessary measures to ensure your IP is protected, and you make a nice profit in the end.  In this day an age though, and in the market of Digital TV, the players are small, some are even part of the same parent company - so naturally contract negotiation takes a back seat...

Responding to change over following a plan

There must always be a plan, not the traditional Gantt chart project management plan of tasks and dates and deadlines, tracking every minor slippage etc, etc. There must be a plan in principle with key milestones in place, with checks and balances - ensuring the development parties are fully aware of the constraints being placed upon them - and for them to work with this certainty as a hard-deadline, and dealing with the uncertainties within that - so deal with change, but be cognisant of the fact you are delivering code in the end.

At some point in the business of EPG development, change must stop - there is so many user experiences one can think of - if you continue to respond to such changes, you will not ship your product.  Your plan must cope for some change of course....

How it feels to be back home again in South Africa after 10 years...?

Well it's been almost 3 months now that we've left the UK and settled in South Africa.  Only last week did I get broadband ADSL and a telephone line installed, life is slowly achieving a sense of normality again.  The first two months was hectic, although we were sorted in terms of accommodation - but that in itself also took a little getting used to...it was new for all us!

Let me start off by saying that Multichoice, despite what products they have currently on market that is causing many people great pains, the corporate services handling my relocation was absolutely tremendous. Although it had taken a lot of effort on my part in terms of organization (visas, relocation quotes, car shipping quotes, travel arrangements, facilitating payment, B&B booking, etc) - once everything was finalized, the relocation pretty much went smoothly.

We spent 3 nights at the Holiday Inn  prior to making our final departure to SA. It was a challenging 3 nights because the family shared a large bedroom (1 double bed, 2 single sofa beds) with the 3 kids - we'd emptied our house of all furniture and needed a couple days to tie up the loose ends.  We flew Emirates, London-Dubai-Johannesburg, business class - it was a very comfortable experience. The kids loved it, unlike our last trip cramped in economy class - so when we reached SA, the family was all fresh and relaxed.  My brother and parents greeted us on arrival, and we were chauffeured to the guest house which incidentally was a flatlet in my brother's property.

Initial Impressions of SA
To be honest, I was blown away by the sheer contrast of it all. On the one hand the place is sprawling with impressive buildings, suburbs, the latest model of cars being driven around, the rush and pace of it all was a little overwhelming -- on the other hand, the evidence of poverty quite literally knocks on your windscreen at every robot (traffic light), intersection, junction, etc...Bear in mind, I've never really lived and seen Gauteng (Johannesburg) before...On face value, without thinking too deeply about it and not involving the complex politics to understand the sheer magnitude the current government of SA has to solve; just looking at the infrastructure alone, around developed parts of Joburg - one can't help but get the sense of how great this place once was, in terms of buildings, residential estates, etc. One can noticeably see the decay, the lack of attention paid to what was once well looked-after estates -- yet at the same time, one naturally thinks about how well the white guys had it in SA -- they really had it made for themselves, enjoying all the luxuries of Apartheid...only recently opened to the Blacks (includes Indians & Coloureds).  That's just looking at historical, old settled neighbhourhoods.  Traffic lights are always offline, the use of the four-way stop is dominant in Gauteng - not sure why the road planners didn't opt for roundabouts (traffic circles) which IMHO is more efficient than forcing motorists to stop-in-turn even when there's no traffic...

So you do get a sense of decay, it’s quite evident in most places that once-upon-a-time the areas were quite nice, roads in good condition, well maintained and well looked after. Some areas are trying hard to maintain that state, but the majority of the areas it’s quite evident that maintenance of the basic services are falling short. Interestingly enough, this isn't just my opinion - others also relate this was the very first impression they got too  "I could not believe the decay in areas that were once beautifully maintained. I am talking about the public areas of course - once inside the gardens of the private houses things seemed ok…" -   But they’re working hard to improve, no roads have turned to mud/dirt tracks yet, and the new developments are looking great.  The world cup was a boost to most parts, so for most of the time you could get away with thinking you were driving in UK.  We experienced a few power cuts, most of the traffic lights (robots) are out-of-action when it gets bad – again, don’t think there’s enough focus in the services area...

Kids
Despite what people say that kids adapt well to change, my two boys aged 5 & 4 -- at first thought they were on holiday visiting family just like last year -- until we enrolled them into school the third day on our return!  What a shocker it was for them. Coming from the caring UK environment where the teachers are loved almost more than the parents themselves, where the learning environment is through fun and games rather than structured "listen to me and learn" routine -- my boys absolutely hated school. For two whole weeks they resented going to school, crying almost daily to go back to the UK, they don't like the teachers, the teachers are not friendly - the children are not friendly, making fun of them, etc, etc.  We put them in a private school, Greenside Primary - which apparently was supposed to be a good, decent-enough school.  Perhaps it is, but my initial reaction wasn't that great, I still have my reservations about the school, but haven't had the time to sit down seriously to consider the options.  On the strength of my brother's and sister's-in-law opinion the school is suitable for their daughter (who happens to be the same age as my son), we went with the flow and sent our kids to Greenside.  Anyway, this school is a privately run organisation, and charges a flat fee of R14300-00 per year per child, regardless of age - that is, a 4 year old pre-primary child pays the same school fees as a 12-year old primary school leaver. Obviously to me this didn't sound quite right because little kids demand far less resources and time that older kids, and when I asked a bit more about this policy, my wife was given a very curt reply "This is how it is in SA. If you don't like it, you can find another school. There a plenty of people wanting a place in this school. All school fees are flat fees and count towards paying teacher's salary". I also inquired about the extent of school supplies needed to the level of toilet roll and soap dispensers -- so really, we pay for everything, right down to my child's usage of toilet & toilet paper!!  You can of course imagine that this is non-existent in UK, that parents don't need to pay for anything, in fact the government provides almost everything...so really, it's a big disadvantage that my kids have left the UK educational environment for a South African substitution - this is conscious decision on my part, I can only hope that the cultural experience the kids come out with would surpass that of the UK (On the other hand, if you look at the recent riots in London one would question the worth of UK education system)...
I've been speaking to a few people who've had family members as teachers, and from what I hear is that teachers are not passionate about the job anymore. Teachers that were once very qualified and passionate are left disenchanted, repugnant and ready to leave. Those that cannot leave stay behind doing the bare-minimum.
It is a sad situation really, the kids had their first sports day a few weeks back.  One notices the sheer lackluster of the event, the sports ceremony and procession lacked enthusiasm, fun, passion and joy.  As parents we didn't even realise the sports day was on, we were notified two days earlier!  Anyway my kids seemed to have some fun, my 5 year old did come out third for his race; my 4 year old completed some races as well -- but the little fellows weren't even rewarded any medals.  So the 4-6 year olds were forced to attend from 9AM till 4PM, stretched the whole day to see the all the sports events through to completion, coming back home drained and tired...
I do have a bone to pick on the schools subject, one that I'd like to participate in future, once I've sorted all the other stuff to get the house and family settled down.
Currently though, the kids seem to have transitioned - a little too well maybe, because they've almost lost their British accent, and are speaking like real Gautengalengs!

Work
As I said in the opening, I've nothing but praise and kind words to offer Multichoice HR and the hiring managers. They've been very supportive, patient and generous. I'd run into a few hiccups with getting my car imported, which the company graciously attended to.  Professional-wise, well - you'll just have to read some of my other posts on working.  Suffice to say, working in SA does take some getting used to. A clash of cultures and personalities exist, the apparent lack of professionalism and due diligence is apparent in most places, with the cow-boy attitude of just getting things done, quickly to market, ready to launch without any thorough detailed analysis...lets just say I'll be kept busy for a long time.  I am however appreciative that people are not discounting my ideas and push for process changes outright, and so far no one has come back to tell me "Shut up Mo, this is SA. Don't try to do what you did in UK/BSkyB/NDS as it won't work here" - so I'm treading lightly, and building upon that patience that one so desperately needs in SA...

Crime
Alhumdulillah, so far so good.  Whilst nothing has happened directly to me and the family, we are always attentive and on-the-lookout.  Our house is currently burglar alarmed, plus have security gates inside the house. As I write this post, my house alarm doesn't work because I recently requested two remote controls to control the garage door, and activating the alarm system remotely. It so happened the garage door now works, but I can't engage my alarm anymore without setting the alarm off!! So the technicians failed to carry out detailed regression testing.
One of the friends I made at work, whom I attend Friday Jumma prayer with - had an incident in his home about a month back. Early one morning, three men entered his house and burgled it, whilst his elderly mom and dad, and wife was still in the house. They were all tied up, trampled upon, father was beaten - and thieves went away with almost all monetary goods.  It was a terrifying experience indeed - and what was more concerning - is when this colleague was recounted the story in the kitchen, another female colleague chipped in and said she also experienced being house burgled first hand, and the most awful thing that plays in your mind is "wondering if they're coming back to the house to kill you once they've done loading the car"!!!!
To most South Africans this is normal, I've yet to build that sense of normalcy -- it's hard to come to terms with the unpredictability of it all. 
I worry every day, and pray for not only my family but for everyone to be safe and not experience a spot of crime...
Even now as my security system isn't fully operational, I wake at the slightest of noises. I'm not sure if the security on call is actually patrolling the area, but was told they will be doing regular drive-throughs... this is another conscious decision on my part to return to SA, but then again - look at the recent riots in UK where three Birmingham muslims lost their lives to an irrational event...
One has to take precautions for example when purchasing cars - don't get high risk cars like BMWs, VW Golf, Audi, 4x4s...you try to rationalise this with faith, that everything is predefined in destiny - regardless of being in UK or SA, if it was meant to happen to you, it'd would happen...but still, you are responsible for your own actions, take the necessary precautions and you gotta live with hope, otherwise the more you dwell on the negative, then negative things start to happen to you (or seems to happen all around you!)

The Future
I really can't put hand-on-heart and say that moving back to SA is permanent. I can however say it was definitely the right decision at the time, taking into account the various scenarios that were playing out: family dependencies, career aspirations and start-up opportunities. As it so happens, the EU is in a bad shape at the moment, the first world economies are struggling, and people are looking at emerging markets as a safe haven for future investment. Apart from China and India, Africa especially South Africa has tremendous potential for growth, opportunity and a promising cultural evolution that I'd like to be part of....

Resignation Letter

Writing a resignation letter is not a straightforward task, although I did write mine in an hour. It was quite rushed at the time because I'd left it for too late, and was under pressure to get it out in time to fit in with my contractual notice period.

There are lots of example letters online, effectively the broad outline of this letter should contain:
- Introduction -  start with the intent to leave the company
- Body - some reasons why you made this decision, and thank the company for the experiences gained
- Conclusion - try to close gently, aim to keep the ties, don't burn any bridges

So this is how my last resignation letter went:

RE: Letter of Resignation effective Monday 21^st March 2011 (8-weeks, ending 13^th May 2011)

Dear Colin,

After considerable thought and soul-searching, I have decided to resign my position as Senior Project Manager/Principal Engineer at NDS. I assure you it was not an easy decision to make especially because working in a culture like NI was a long awaited dream of mine, as it would have allowed me to experience what it’s like to work with new ideas from the ground-up, something I always aspired for, in the hope of running my own start-up one day.

As you know, I left the country of my birth, South Africa (SA), over 10 years ago leaving behind all my family. Due to personal circumstances and obligation to family, I’ve decided it’s now time to return home. I’ve managed to verbally secure a job offer with the local SA broadcaster, but nothing has been formally agreed yet nor has anything been formally signed. Regardless of this fact, my decision to return home has been made, and I’ve already begun preparations for the move, aiming to be in SA at the end of May 2011.

Thus, in keeping with the terms of my contract of employment, the notice period being 8 weeks, effective from Monday 21^st March 2011, this makes my termination date to be 13^th May 2011.  As agreed we could renegotiate the exact end-date mid-way through this period around 15^th April, but at present, I am keen on working the full notice period.  I will aim to complete as much of the work expected from me during this period.

I value the past 8 years experience with NDS. I’ve had the opportunity to work in different areas of the business, and with teams from around the world, having built-up a good network. I’m confident that this experience will be very useful to me in my future career.  If NDS ever sets up an R&D/Professional services/Delivery office in SA, I would hope NDS would contact me to discuss potential opportunities for working together again.

Yours Sincerely,

Muhammad Khan

Senior Project Manager/Principal Engineer

My BBC Interview 2010 - Questions exposed

Last year I experimented with the market as I was feeling rather undervalued and not appreciated at work, more so looking for positions that offered more senior roles that wasn't being made available to me at the time. One of the companies I applied to was the BBC.  BBC is considered the grandfather of broadcasting not only in the UK, but quite possibly world-wide.  They have quite an intense application process with setting up an online profile, online testing with scenario videos, psychometric tests and the lot.  Should you pass all the screening, you will then be offered an interview - I'm happy to say I made it to the last stages, competing with 3 out of an original batch of 30 applicants - however, we all know how that ended :-) Not successful, bottom-line, BBC thought I was carrying too much process baggage and not agile enough; as well as I didn't have prior line management experience which is what they were seeking for the technical team leader role.

Anyway, my interview was a surreal event because I wasn't applying for one role. They laid out the following possibilities to me: Technical Team Leader, Project Manager, Programme Manager, Scrum Master.  So I was subjected to a varying degree of questions. In retrospect, I think I came off a bit too confident, strong, and determined to change the world.

I will now share with you my responses to the questions that opened the path for the face-to-face interview:

Q1 - We’re looking for strong technical leaders: excellent at designing & delivering complex solutions while at the same time motivating & inspiring a team. Please give an example of an IPTV/On-Demand/Interactive TV project you lead from concept to deployment (2000 character limit).

[BSkyB Anytime+ HD On-Demand/Interactive TV (1943 characters) 2008-2010]

A highly visible project to secure NDS’s position in the Middleware market for the foreseeable future, involved seamlessly  replacing an existing Middleware (OpenTV) on multiple STB platforms (deployed 2 million+ homes), with no noticeable difference to the user, plus the addition “Anytime+ Progressive Download”. A new Middleware & device driver model, consisting of 80 components with a 200-person development team geographically dispersed: 2 UK sites, France, India & Israel; as well as working with suppliers worldwide: Broadcom, Amstrad, Samsung, Thomson, Wipro, Red Embedded & S3Group. The project is often described as “not only changing all four tyres on a car whilst you’re driving, but also giving the engine an overhaul & the body work a re-spray at the same time!”

I had global accountability as Middleware Dev. Owner, overall project management responsibility for delivering feature completeness within the set timescales; managing a team of senior architects (design authority), 200-person development/integration team to deliver a backlog of 200+ work packages.

My engineering background allowed me to build rapport with development teams, gaining project-wide respect, as highlighted:

• Quickly gained architectural design knowledge, allowing me to hold technical discussions with the customer without needing to include senior architects.
• Participated in customer defect review meetings in negotiating issue severities, assigning ownership & allocation to component teams (usually the job of chief architect)
• Conducted impact assessments of change requests, before passing on to architects for review (Software Migration, Download, IPv6)
• Mentored Hit Squad teams consisting of senior engineers, in resolving critical issues (steering performance improvements, providing tools to find memory leaks), sometimes spending late hours with engineers going through code (shared OpenTV knowledge)
• Produced much-valued technical status reports on critical issues
• Proactively drove the setup of the end-to-end system for home field trials allowing people access to latest builds via software download
• Appreciated the technical challenges placed on engineers, often siding with the engineers that “it cannot be fixed any sooner without consequences”

OPTIONAL ADDENDUM: Additional Responses to Q1 from a senior engineer, technical leadership perspective

[Speaking EPG – Interactive/Accessible TV (1987 characters) 2007-Present]

This example may not immediately appear to be relevant to the question, however I think it’s worth sharing as I strongly believe that strong technical leaders must possess great vision, determination & an unfailing desire to succeed through persistent perseverance.

For the past 4 years I’ve created a following both inside & outside of NDS for the need for accessible, usable EPGs targeted at the aged for independent living, blind & partially sighted, dyslexic & the illiterate by spearheading the concept of a Talking EPG: a STB with built-in speech synthesis.

This was a project “greenhouse” outside of work hours, purely out of interest & a passionate desire to add value to people’s lives. Despite many obstacles - I had little networks & influencing-power, NDS being a large company – I pushed the idea from a concept, simulator, demo to prototype on real hardware to engagement with customers - in the years to date have now inspired a team of 7 people contributing to my greenhouse project.

I kept abreast of Middleware roadmap (as I was working in the IPTV HeadEnd group at the time & wasn’t involved with STBs) & decided to experiment with the platform. Working closely at the driver level, I ported an open source speech engine, complete with voice dictionaries & databases & got a STB to perform real-time text-to-speech synthesis.

To provide a realistic experience, I partnered with another project that was working on a simple zapper middleware, providing the platform exposing the service information, menus & graphical text representative of an EPG experience.

Having integrated the two projects together, we were successful in demonstrating a simple zapper EPG in 2007, speaking out menus, key presses, channel information, reading a book from a text file, speaking out the time, changing different voices, etc.

I created an open API framework that could be used for integrating commercial speech vendors, & published the API for recommendation into the official middleware product, where it’s currently under review, the original audio stream requirements were approved & included in the current product build. The feature has also been added to the product roadmap, making it a success.

I’ve persistently spreading the message, still seeking external interest, all in the background. I suspect this will remain a passion should I end up with the BBC!

[DirecTV USA – Interactive TV (1974 characters) – 2003-2004]

This project can be summarised as porting of a DVB stack to DirecTV’s DSS APG domain, implementing a new EPG, resulting in excess of 200K lines of code in ~6 months, currently deployed in 30 million homes.

I was part of a core team of 3 people that eventually grew to a team of 12 as the project matured. I was heavily involved in the gap analysis phase, where I had to understand the DSS system, the structure & APG protocol creating a mapping to our existing implementation in the DVB domain. We inherited EPG code from a previous project that was quite mature & exclusive to the DVB domain that included conditional compiles for different projects, for a PVR profile. The code was huge, complicated & new, it meant investing time to understand the code, identify all API dependencies, highlighting APIs that needed changing, defining new APIs, identifying the useful & useless code, removing conditional defines. It also involved understanding & correcting the architecture model of the EPG.

The biggest challenge for the EPG was on developing the complicated new features of DTV, whilst at the same time reusing as much of legacy code as possible. I led, through a team effort, the de-construction of the EPG, fixed the architecture to adopt the model-view-controller pattern allowing us to work in isolation, independent of the user interface screens, the model & controller could be written separately. We identified further services that we could make independent, called “engines” that provided the screens with the functionality desired. We were able to develop the UI, work on the services & controller in parallel, & with a few integration points synchronised could deliver incremental functionality & experience together. I also took the lead in defining the shared services that implemented generic algorithms that served the needs of many similar use cases avoiding the need for repetitive code.

Of particular note, the program grid was the most complicated code of all that I’d written from scratch in two weeks, comprising over 30000 lines of code, which to this day, has remained largely untouched. We maintained a strong preference to maintaining the architecture UML model, the engines, controller & model were updating along with important sequence diagrams so that everyone on the team would have a source of documentation for reference.

Q2 - Using the example that you provided above, tell us how you ensured your project met the original business requirements & was of acceptably high quality.  How could you have improved it further? (1000 character limit).

BSkyB Anytime+ HD - On Demand/Interactive TV (1073 characters)

High-level features translated to system requirements, then to product-use-cases, realised through Work Packages (WP), a self-contained unit that can be tested & verified tracing back to original requirements.

Code quality: MISRA standard, Zero Compile/MISRA/Lint warnings, 100% API & Line Coverage, 65% Branch Coverage, 100% test mapping, used static analysis from KlocWork, Blackduck for open-source violation.

Multi-level test approach, unit tests, component-group, Middleware suite of 1000+ regression test cases targeting 98% pass rate, stability & performance tests – build fully automated, testing at all levels driven by continuous integration tools.

I helped resolve key defect process problems: clarified severity criteria (Showstopper, Major, Minor); published a workflow for importing customer defects, defined project-wide defect process. Reported metrics regularly, target zero showstoppers. Managed regular root cause analysis & iteration reviews.

I instigated specialised on-site teams (Hit Squad) fixing critical issues; evangelised Microsoft’s “Eat your own dog food”, enabling home testing catching critical issues early.

What would I change?

Start full stack testing early in lifecycle, better traceability at full stack back to requirements. Do continuous delivery at full stack.

Q3 - Using the example that you provided above, tell us how you went about instilling/ enforcing agile development methods where they did not exist, or reinforcing where it did. (1000)

BSkyB Anytime+ HD - On Demand/Interactive TV (1090 characters)

NDS adopted Agile company-wide in 2006, changing the physical layout of the office-space providing floor-to-ceiling whiteboards, break-out areas, meeting rooms for Scrum & associated software tools; as well as a manifesto for software development.

Mature process: WP backlog, incremental feature development, continuous integration, parallel delivery to customer, releasing early, releasing often, 6 week iteration cycles that evolved naturally to 3 week cycles, later to 1 week deployment cycle. Development teams are self-managing, owning local backlogs, managing team progress independently. Regular meetings, metrics & reporting were already in place to gauge project progress (Velocity, Planned VS Actual, Burndown).

What agile methods did I change/reinforce?

• Identified waste in QC, turning 3 weeks QC cycle to 1 week, synchronised with our release cycle. The problem was that defects raised in QC were 4-5 weeks out-of-date with the current build.
• Recommended customer-support team on-site to collaborate, resolve & fix key issues on the spot, unblocking QC.
• Managed daily Scrums, XP, brainstormed, mentored engineers, getting hands-on with debugging & code reviews.
• Kicked off one-roof-integration teams bringing together geographically dispersed engineers & testers to share the team experience.

Review: Dissecting the Hack: The F0rb1dd3n Network by Jayson E. Street, Kent Nabors, Brian Baskin

This book is interesting in that although it tells a fictional story of how two hackers innocently & accidentally fall upon and help prevent a serious threat to national security, everything about the technology is all real, and explained in good enough detail to make anyone interested in security threats, wanting to learn more. 
The book is divided into two parts: Part story, Part references. The references can be used again and again to sharpen your skills in being more security conscious or paranoid in your every day activity, beware of the bit-trail you leave behind.