Sticky Metaphors for Software Projects: Bankable Builds, Surgical Mode

In this post I share an experience from a recent project where I influenced the senior management team to change strategy & tactics, by moving away from the standard Development->Integration->QA Team 1->QA Team n (which lasted anywhere between 2-4 weeks) approach to a more controlled Agile, Iterative/Lean approach of weekly Build & Test cycles, to a build-every-three-days, in order to make the deadline (that was fixed). We did this entirely manually, where our Agile processes were still coming of age, and had little in terms of real-world continuous integration. What I wanted to share really, is the way in which I influenced and got people to change their mindset, by using simple metaphors that were actually quite powerful, and can be used to sell similar stories:

• Bankable Builds - Reusing concepts from The Weakest Link
• Surgical Mode - Taking a page from medicine - Surgery is about precision, don't do more than what's required

It is interesting that these concepts really stuck with the entire department, so much so that it's become part of the common vocabulary - almost every project now talks about Bankable Builds & Surgical mode!

The post is presented as follows:

• Story & Background
• Bankable Build Metaphor
• Surgical Mode Metaphor
• Sample Snippets from Management Feedback
• Recommendations I set at the kick-off

Note: Like any high-profile project with intense management focus, the decision to make these changes came from senior management, which put a spanner in the works with respect to granting our "Agile" team autonomy & empowerment. Although a little resistance was felt at the lower levels, the teams nevertheless remained committed to do-what-it-takes to ship the product. The teams and vendors did share their concerns in the retrospective feedback that the one-week release cycle was quite problematic to the point of chaotic with large overheads.

The facts can't be disputed though, that our agility was indeed flawed from the get-go by not having a solid continuous build, integration & regression test environment (lacking automation) in place. It was a struggle, with a lot of manual overhead, but it was a necessary intervention, that got us to launch on time. Not having done so, would have meant us missing the target deadline, the project was too high-stakes to ignore this intervention.

Going forward however, the principles of bankable builds is still a solid one, one that is well known to teams with mature software processes, I can't emphasise the value of investing in up-front automation with continuous build, daily regression testing & automated component / system tests will help make life so much easier for software development teams.

Invest time and effort getting the foundations set up at the expense of churning out code, continuing to do so will build a huge backlog for QA down the line, teams ending up spinning-their-wheels in putting out fires that would've been avoided, had the right discipline been set in place.

Custom Voice Recoder App: Instant Recorda

OK, before I get labelled for being lazy and not searching enough on the iOS Appstore or Google Play store, I have searched but couldn't find the specific features I need from the various Voice Recorders out there. Perhaps you might have come across a suitable app, so please get in touch with me!

Basic Idea / Elevator Pitch
The idea was borne from the many commutes to work and back, listening to the car radio, or reading some big billboards that caught my attention. For me, when listening to adverts on the radio, or some plugs during an radio interview, I would try to make a mental note (especially some new websites to check out), or when checking out some billboard, try to remember the site or key terms to follow-up for later in the day or whenever I have some free time.

What happens often though, by the time my journey is over, I've forgotten most of the stuff I wanted to follow-up on! What was that URL again??

So I thought wouldn't it be nice that whenever I came across something interesting to follow-up, there would be something that I just trigger, or tag for follow-up, it will record the last audio stream of whatever it heard: If the radio was playing and I gave the signal like "Tag", then the last ten seconds would be recorded. If I saw a billboard whilst driving, then I speak it out, and say "Tag" and presto, it gets recorded. At the end of the day, I go back an review all the things I tagged (no need for me to forget anymore). You could also have some way of triggering the device to record, hit the screen or button, or something - the trigger will just instruct the device to save the audio buffer into this playlist.

Then I thought about it a bit more, realised this could even be useful in the work-place as well, during meetings or keynotes, just take stuff for following up (audio stream).So I thought there should be an app for this: Call it instant Recorda :-)

Basically the app listens in the background, constantly recording the audio stream, waits for the trigger, and saves the last ten seconds. The file is tagged by date & time, and could be stored in playlist of some sort. And the opportunities grow from there… I have discussed this idea with colleagues and friends, they seemed quite positive about it, so hopefully there is some merit in pursuing this further.

Idea is shared Public on Trello

I've started a draft backlog of the work to do, sharing in public with the rest of the world. If any app developer comes across this, please get in touch!Check it out here: https://trello.com/b/fEv5GaWt/instant-recorda-app

Architecture Interview Questions

I've written about architecture topics in the past, especially relating to the role of "Architect" in Digital TV Systems & Software projects. Though I'm no architect myself, although I could very well have become an architect if I chose to maintain on the purely technical path; I still have to be across the technical disciplines at the high level, when it comes to program or project managing large-scale technical projects. 

When I start or join a new project, one of the first things (apart from familiarizing myself with the product spec) I do is to seek out the architects, looking for any technical information in the form of design,

(document/wiki/etc) that scopes the high level system design or architecture that we're trying to implement & deliver. 

Failing that, having found no clearly defined architect role, I would go about setting up this role as a matter of urgency. No architect means no technical ownership, means flaky interfaces, chaotic system integration points, and a very bumpy project ride lays ahead!

In the past I have worked very closely with many great architects, both as an engineer as well as manager, that I've learnt from this experience enough to know what to look for when seeking out architects. If a project requires it, I do get involved with the interviewing architects, system integration managers, project managers and other roles. 

I thought I'd share a list of some of the questions I generally tend to ask when interviewing for the role of Architect in a Software/Systems project - hope you find it useful. If you read my other posts on architecture, you will get to understand I have a more holistic expectations from architects, rather than just answering this list of ~100 questions!

Agile team goals - straw man...

Over the past few years, going back since 2004, when I first started working in an agile-like fashion to present day, I've seen companies and teams transform their development practices, maintaining a strong desire to continuously improve from past experiences. I've seen such transformations driven top-down (where senior management saw inefficiencies with existing processes, accepted a step change was needed to survive growth challenges and thus set about a strategy to implement new processes). I've also experienced the change coming from within the team themselves, experimenting at first (in the background), proving the value added to not only the local team, but to the wider organisation as a whole (although it wasn't easy, it is generally harder to influence bottom-up).

In order to derive some success from these transformational initiatives, there is usually a person who takes on the role of catalyst or driver, maintaining a clear vision of the goal and desired outcome - keeping people together, constantly reinforcing the message, always constant reminding. Generally this person is energetic, evangelic and carries enough of an aura for people to just believe & follow, the mark of a true leader. This is also made possible by having a team that has been through the mill, have battle-scars to show for it, and are really sincere in adopting the new strategy.

But what do you do, when you have a relatively young development organisation, cobbled together from various parts of the world, all differing skill levels & competencies, and when the leadership is lacking (incoherent) such that no one in the department has ever delivered a project successfully using Agile/Scrum before, have never really seen the development, people & cultural transformation required to realise the change from start-finish, and not have had the patience & privilege to live the agile journey of a few years??

What do you do when a team of aspiring young engineers that are just starting out on delivering formidable, real world-class products for the first time, who have been used to the heavy-handed old school project management styles of yesteryear -- suddenly fall in love with the premise of Agile -- but unfortunately lack the depth and breadth of understanding the real challenges of software engineering (product development, not proof-of-concepts)??

In the business of Set-Top-Box software product development, this is the software that provides your TV services like Personal Video Recording, Video On Demand, Linear TV, Electronic Program Guide, etc. A mixture of hardware design, low-level drivers, middleware operating system & high level user interface. Technologies are Java, Flash, HTML5, C/C++, embedded environment. This space is becoming highly competitive, how do such software providers remain competitive??

The answer generally touted is "We're adopting Lean/Agile/Scrum - we deliver fast, work with a rapidly changing market, flexible & practical" principles for product delivery -- but in reality ain't that easy - Agile adoption is a journey of at least three years, including time for experimentation & failure - it doesn't happen overnight. Some foundations need to be in place, principles that become the substrate for the future - a team without these foundations is operating in chaos, or as they say "Paying lip service to Agile"...

In this post I provide a straw man around goals that a development team could strive for in their quest for Agile. Just as they teach you in business school, that you need to have a plan guided by a mission, vision, strategy & plan of action -- so too can a development team ground themselves around goals that are SMART (Specific, Measurable, Attainable, Realistic, Timely). Moreover, if a team can latch onto some Real, Tangible, Concrete, Credible messages, these can be quite powerful in galvanising the teams around a singular purpose:

• Straw-man goals to drive Agile Development
• Sample Software Development Team Charter

Review: The Deadline

I came across a review I wrote for Amazon sometime back 2010:

The Deadline : A Novel About Project Management is a novel attempt at describing life as a practising project manager in the software development industry. Choosing fiction as a means for distilling this experience was the right call, since many books on software project management talk about mostly the process, but less so on the fundamental human experiences.

This book attempts just that, a perspective on the people elements, and it doesn't do too bad a job either: It tells the story of a Mr. Tompkins who takes on the job of managing an army of software engineers, to create and deliver 6 software products from scratch, limitless resources. So he sets off creating an experiment: create 3 project teams for each product, each with the same goal of delivering the product by an artificial deadline (that was later made real by a tyrant manager bringing the deadline many months forward) and set about observing the progress of each team, thereby understanding the implications of their actions - in an effort to understand the secrets behind real world processes...

Whilst this book does get my recommendation, it must be noted that this was written and published over 10 years ago - which makes much of the experiments seem a bit out-dated and irrelevant. The shrink wrapped software industry age has passed on, which is why I feel the book has missed out on exploring modern practises seen with open source development, off-shoring, outsourcing; large scale distributed development, test driven development, agile, etc - with real world demanding customers, where companies are driven by competition, so hard that there is really no time for proper planning, estimating, playing around with models and predictions is a luxury rather than necessity - the deadline is really about winning new business and keeping your customers happy; and your competitors at bay; delivering software that is of acceptable quality to your customer, stressing less on established processes like CMM level 3/4/5 (depends on the industry of course), etc.

This book is considered  a work of fiction but it does contain real world references for follow-up reading. One such interesting reference is the topic of modelling your hunch-base, using for example, iThink a systems thinking tool that allows you to model business processes, using parameters for tuning and testing output of various scenarios. This, along with archaeological project data mining for metrics, will provide invaluable resource to a team when considering new projects.

If you're an experienced software manager however, then most of the encounters will not be new to you. It feels like there should be a sequel to this book, updated to support and test out current theories, offering more detailed explanations of each experiment, which is lacking here. One gets the overall idea that the project management laboratory is an interesting topic, but there is so much more to play with rather than just over staffing and design philosophy...

All in all, I am nevertheless pleased I read it and would definitely recommend to anyone involved in software projects.

2013 Update: Although times have changed since DeMarco & Lister's experiences, much of the essence with the challenges of Software Projects nevertheless remain relevant today. For those of you not familiar with DeMarco, I strongly recommend you follow-up on their works - I've read & own all of these - highly recommended, I learnt quite a bit from these, further amplifying my passion & respect for the Software Engineering Profession:

Summer Reading List over December

Since returning home* to South Africa in June 2011, life has been really pretty damn hectic, they say relocating your family & household contents is one of the most stressful things you can do in life - added to that, working with a new company presented itself with a massive culture shock. So I had my hands full with handling not only work but also family transitioning to the new life. Not to mention I quit my permanent job and ventured into consulting territory. This transformation has set me back someways: in particular, my reading list fell on the back burner, and it's only now that I'm starting to rev it up again. Another reason for not maintaining my reading as I used to in UK, is that South Africa is way behind in the online shopping space, the deals I used to get on Amazon were so great in terms of price (not to mention service!), that when I pick up books from the shelves in stores here in SA, or even online (Kalahari), I often cringe at the price tags (definitely cheaper in UK, wait). I still haven't made the leap to the Kindle yet which is the sensible thing to do (although the Pound/Rate exchange rate is crazy!), I was an early adopter a few years back, but I really wasn't impressed at the time - so still prefer my hardbound copies! I do have my eye on the Kindle Fire HDX though...

Here's a snippet of the handful of books piled on my bedside table for reading over the South African summer break: