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:

Nissan Motors Production Line and Software Systems Development

This week I was invited by @Farid from Crossbolt to tour the Nissan Production Line in Pretoria, to see first-hand the Lean / Kanban / Kaizen production model in action: Cars come off the line every four minutes (cycle time), Zero defects straight-through rate.

I jumped at the opportunity without hesitation. Although I've ran software projects as a factory-line model before, I had never actually been in a real car production factory before. Fareed had decided to take his IT Operations team on this tour, after doing the theoretical knowledge-share on Lean.

He felt it would make more sense for his team to witness first hand the theory in action, where the metaphors can be easily visualised and applied to an IT Ops / Systems Integration space. Not a bad idea...

This post is just a brief dump of my personal take-aways from the visit. I will try to expand on them in later posts once I've let the ideas play around my head for a while to morph into shape. Despite what some people might say: Software is a creative art, it can't be rushed and boxed into a production line, when it comes to pushing out consumer production software, I beg to differ: there are indeed many parallels from the manufacturing sector (which is seriously way more mature than software development) that can be drawn upon and applied to software teams - incidentally this is the roots of Scrum / Lean anyway - just taking the same concepts and applying it to software teams...

There's plenty of info on Kaizen / Kanban / Lean / Poka Yoke / Scrum - I won't go into detail here. For context though, the line we visited was a multi-model line. This means that the line produces more than one type of vehicle in a continuous flow. Any team on the line could be working on a different model at the same time. Some car production lines specialise in just one model, but this line builds at least four different models. Because the flow is continuous, a car comes off the production line every four minutes, like clockwork. The team working on the line therefore, are cross-functional and cross-skilled. 

Take-aways:

Career Ladders: Avoiding chaos and anarchy in Software / Systems Projects

This post is part rant & part structured discussion around the topic of career development in the domain of Software & Systems Engineering. I have been in the business of core software engineering for fifteen years (15), and was fortunate to experience working with highly rated professional companies (from Silicon Valley, internationally renowned) whose sole purpose was producing software systems from scratch, including as providing software design services to other software companies - these companies maintained true to engineering as a discipline.

A graduate engineer would enter the company with a fairly good idea of the where he/she is starting, and the various options & opportunities that lay ahead in terms of career growth, and, depending on the company - this graduate could spend

the next 10-15 years with just one company alone and never get bored, traversing many job disciplines as he/she so desired. 

This is the baggage (rightly or wrongly) that I come with, and hence my surprise to learn that some companies in South Africa are still making a serious mistake of not having a simple template that maps roughly the career ladders for the team, covering Development/Test/Integration Engineers, Architects and Managers. I firmly believe this is a recipe for chaos & anarchy that must be avoided as far as possible, and the solution to this problem is to map out a simple Career Jobs Ladder for your technical department.

Don't get me wrong: I am all for meritocracy, flexibility and not bureaucracy - but it really irks me to see things happen in the workplace that just don't make sense, especially when promotions happen when there is no real truth, track record or backed-up peer recognition that warrants a role / title change. 

I have seen the following happen as an example of chaos:

• An integration engineer with no prior design or architecture experience is promoted to Architect
• An software engineer with no prior architecture accolades is promoted to Architect
• A software engineer with no prior team leading, people management or facilitation experience is promoted to Scrum Master
• A team lead with no prior project management or scrum mastering track record becomes an Agile Manager
• An integration engineer with no product management experience becomes a Product Manager
• A new recruit with no prior experience in the technology domain joins as a Senior Solutions Specialist
• A new architect who has never architected any product before enters as a Solutions Architect
• An enterprise architect who has never delivered to market any real enterprise-class systems product that has a user base of more than fifty is made Enterprise Delivery Architect
• A component architect who's only worked on a single software module / component becomes Enterprise-wide Solutions Architect
• An integration engineer who's only experience in embedded devices joins an enterprise systems integration team as a Senior Integration Specialist
• An automation specialist or tech lead who is misunderstood as the Head of Automation

To an observer, the above scenarios are candidates for chaos (What do all these roles mean? What's the job spec? Is there a clear map that shows the progression of one role to another?, etc. etc.), although these cited migrations would not be that far fetched if there was a career ladder to hand, that facilitates the growth path - that can be used to take the individual on the journey to reaching his/her desired goal....

And this is where anarchy comes in (again, a little rant on my part):