I had one of those moments this week while overhearing part of an episode of Engie Benjy.  In it, two vehicles were having a race.  They were both trying their absolute best but eventually tied.  The vehicle owners cheered and congratulated both vehicles saying, “Well done you two. You’re both winners!”.

Ordinarily I’m not a big fan of that sentiment; it’s so desperately overused on childrens’ TV programming that, as an adult, one can become very cynical about the idea.  It makes me cringe.  The real world doesn’t operate that way and that message, in my view, sets up an unrealistic expectation in children of how things work.  In school sports, exams or employment opportunities for example, we don’t all get to be winners.  Someone comes in first place and others miss out.  That’s just how life is.

But what about the office environment and corporate culture?  Is it reasonable to expect that there should be one winner and one or more losers?  Do we have to accept that office politics and judicious use of communication is just a fact of life in business?  I would argue that in a company (or at least on a team) there is an over-arching common goal that is shared among all staff.  While it might sound idealistic, working together towards a shared goal not only means that goal has the greatest chance of success, but ultimately will ensure everyone involved comes away a winner.

Corporate Culture and Office Politics

It should be noted that not all office politics is bad.  The process of building a community; making it healthy, cohesive and satisfying for its participants can be as much a political feat as that associated with negative connotations.  The difference between pathological and healthy, constructive politics is an important distinction to make.  To quote DeMarco and Lister:

An organization that succeeds in building a satisfying community tends to keep its people. When the sense of community is strong enough, no one wants to leave. The investment made in human capital is thus retained, and upper management finds itself willing to invest more. When the company invests more in its people, the people perform better and feel better about themselves and about their company. This makes them still less likely to move on. The positive reinforcement here is all to the good.

Individuals and teams alike are motivated and catalysed by the feeling of accomplishment; that delivering a quality product or result is worthwhile.  You can take pride in the workmanship or style in which that result was achieved.  If the sense of achievement and common purpose is removed through pathological politics, everyone very quickly begins to see that hard work and dedication – while being a nice organisational virtue – is not as important as butt-covering and protectionism.

If a team is assured that extra hours at the office will be well-rewarded and recognised if it means that a product can be delivered on or ahead of schedule they will likely put in the effort needed to achieve that goal.  This will be at the expense of time at home with the kids, out with friends or doing the sorts of things that give people respite in their own personal time and allow them to “recharge the batteries”.  Now assume that, having delivered the aforementioned product, the team is told that the recognition or appreciation promised won’t actually be in the form of a bonus, or won’t be an elevated pay rate for the additional hours, or will be merely remembered when the next round of performance reviews are due.  The motivation, enthusiasm and dedication of that team is immediately stripped and replaced with resentment.

If a senior manager is concerned that the team will collectively argue their case for, say, a promised day off or bonus, and decides to take each individual aside and explain that “we didn’t actually give specific assurances and you can either take what we’re offering or leave it”, politics come into full play.  Each individual on the team feels pressured and intimidated without any support from his peers.  People aren’t stupid.  They can see the divide-and-conquer approach being taken in the relative privacy of the manager’s office and react by becoming defensive, resentful, angry and disloyal.

People are by nature reasonably perceptive creatures and will interpret what they view as being unfair, unilateral or otherwise negative changes or initiatives (rightly or wrongly) as deliberate acts; thereby reinforcing a feeling that they need to guard or actively work against that person or their efforts.

Successful change comes from open and honest communication, genuine attempts to share responsibility and credit and by allowing each person on the team to make equal, worthwhile contributions to that team’s success.  A manager’s role is to motivate change, create vision and develop political support (getting the team’s “buy-in”) even before any transition occurs.  If a team feels excluded or disempowered, the task becomes an “us-and-them” issue and no matter how well-intentioned any project, idea or goal is, it will at best be a struggle to achieve as individuals work to achieve their own needs; or at worst actively work against the goal becauses they feel so removed from the decision-making process that affected them.

Office Politics is totally unavoidable in the workplace, but it can be a force for good so that everyone wins if all members of the team – at all levels of the hierarchy – recognise the contribution they each make and actively work together to achieve those goals.  Maybe my reaction to that children’s TV show was just me projecting my resentment that life wasn’t so optimistic and inclusive in more companies, in which case maybe I need to take steps to see if the relationships and communication within my wider team is improved to the point where everyone’s main goal is to help each other succeed above all else.  Ultimately, isn’t that the best option to make sure we’re all winners?

Suspicion

I was recently given an account from a friend that reminded me of an article I read by Esther Derby on Bully Bosses.  Esther’s article paints a very grim of some of the worse-case situations employees might find themselves in: abusive, yelling, coercive or threatening managers who for whatever reason feel they need to exert authority and control over their staff.

The case I heard differed considerably from these extremes – which I’ve had the good fortune to have never experienced – but still fits into the Bully Boss category: the defensive manager.

Conservative Defensive Management

Defensive Management is a style coined by Tim Lister and Tom DeMarco in their very excellent book, “Peopleware – Productive Projects and Teams” (Dorset House, 2nd ed. 1999), which assumes that your staff are generally incompetent or mistake-prone.  Staff can’t be trusted to make the right decisions and their errors will reflect on you.  Only your judgement is competent; anyone else’s is supect.  Therefore you should vet and approve any and all important decisions before they are put in place.

Conservative Management is a style I’ve seen particularly prevalently in the public sector and in the finance sector.  These industries are by nature very risk and change averse and prefer to stick to well-established historical practices regardless of what might be happening in today’s market.  The management of these companies is often of a similar vein, with a career upbringing in strict heirarchy and an habitual acquiescence to upper management decisions.  An old-school management style of “if I say to you that the walls might look better painted green, you say ‘What shade?’”.  I could be wrong, but this type of disciplined management style is generally only found today in the armed forces.

Put these two together and you have a manager who expects all staff to conform to his way of thinking and agree unquestioningly with his decisions, who doesn’t trust his staff with any meaningful autonomy or authority and who needs to be involved in every decision.  This type of manager can be even harder to work under if he is prone to dark moods or creation of arbitrary deadlines that must be delivered.  This is a form of micro-management, but done in an intimidating way such that staff are afraid (or at least reluctant) to speak up or disagree.

As DeMarco and Lister argue,

the only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded.

Staff who feel untrusted, coerced and insignificant are less inclined to form together and work well as a team and are less likely to feel motivated at their work generally.  Productivity can only inevitably suffer as does innovation and growth.

This type of Bully Boss is something of a unique variety because he may be cheerful and approachable for much of the time, but as soon as something happens that doesn’t fit with his expectations, he can become grumpy and condescending, asserting his view of the way things should have been done and making people feel small and guilty.  Employees who have this type of manager typically adopt one of two coping mechanisms: they tolerate the behaviour and just try to get on with each work day, or they leave.  Esther’s article (above) lists other effects including stress, information hiding and a lack of engagement (a signficant one in my view).

Read Esther’s article (or better – subscribe to her blog!) and consider some of the coping strategies she suggests.  Have you had your own experience with a particular personality type in your direct management?  Tell me about it.

The most common scenarios I’ve seen are when a new Technical Team Lead has been appointed to the role (or been press-ganged into it) and a hospital pass is handed to that lucky candidate to own the task of getting the standards up to date, implementing them, or in more extreme cases, writing them from scratch.

I’ve found myself in this situation on more than one occasion and it is a completely overwhelming prospect when there is little or nothing to start from.  In this post, I will give a quick run-down of the key things you should include in your standards documentation and provide you with a working sample that you can adapt and improve as needed.

Starting From Scratch

Starting from scratch is probably the most intimidating position to be in.  You will often be lumped with this problem if the team is new, or if you are new to the team and no one has bothered to get around to it yet.

If you need to build out your standards from the very beginning, here are a few questions and considerations you need to address:

• Architecture: Classic or SOA? What layers should you generally have (e.g. presentation, data access, business logic, security, etc.)?  What clients does your business usually target (e.g. thin, fat, mobile)?  What integration concerns do you need to standardise?
• Technologies: What code is accepted / disapproved? What data storage and retrieval technologies should you use?  What scripting frameworks?  What languages?
• Tools: What testing frameworks should you adopt?  What about mocking? What version control systems and policies do you have in place? Continuous Integration?
• Documentation & Support: What are your minimum documentation expectations? How should your code be commented / documented?  Do you use documentation generators (e.g. Sandcastle, Live Documenter)?  What are your peer review expectations?  Who needs to be considered at handover when coding is complete and ready for delivery?

Updating Existing Standards

Being tasked with updating your company’s existing standards is a much more problematic situation.  The existing standards may either have evolved or stagnated over time and may not, in their entirety at least, reflect the true nature of your current development landscape.

Standards Review Process

The trouble is in the sorting of which content should remain, which should be modified and which should be removed altogether.  Start by identifying those standards that are completely obsolete or irrelevant to your current work; unsupported frameworks and languages, obsolete tools or unneeded documentation requirements.  Once this housekeeping task is taken care of, you can start on the more challenging part of adding new content in.  Pick your top problem area and define a workable approach to eliminate or minimise the impacts from that area.  After a couple of iterations, review how that standard is working and refine it.

When you feel that your team is operating well on this functional area, pick your next performance issue and repeat the process.

Documentation Isn’t Standards

It is quite common, especially in larger organisations, to have explicit provisions for various documents included as part of the team’s development standards.  Different people have different views on this topic, but my personal view is that documentation does not constitute a development standard; it is part of your process.

There are no doubt times when you need to supply a solution architecture document, design document or some other written artefact, but this is most often an internal requirement and does not affect how the actual product is designed and coded.  As mentioned before, unless it adds direct customer value, it isn’t really needed.

Your team may have some procedural requirement that outlines all the written material that is expected for a given deliverable, but this is effectively meta-content that only supplements the product – it doesn’t underpin it.

Don’t standardise your documentation deliverables unless (and even here I’m not that convinced of the need) there is a direct customer benefit and the standard can be scaled to both small and large solutions.

10 Commandments

As a pretty good rule of thumb, your full standards document will probably grow and evolve to become something of a behemoth.  You can expect your new developers to read this a total of once while they are still

1. Full of enthusiasm about starting with a fresh new company and are eager to impress
2. Bored out of their brain while they ramp up their understanding of how your team works

After this, you can expect your full standards document to be referred to in about one in every 100 cases.  This is normal (unless you run a code dictatorship, in which case you have bigger problems than whether your compliance rates are 100%).  It is because of this that you should have a standards 10 commandments list – preferably in soft copy (e.g. on your team’s SharePoint site or similar) that is easily found.  These ten commandments should summarise – in bullet form – as briefly as possible what your top ten minimum expectations are.

An example might be:

1. Code must be checked in to version control at the end of each week at a minimum and must not break the build.
2. Unit tests must accompany all complex code and should ideally drive the design of the behaviours they test.
3. JQuery is to be used as the accepted JavaScript framework in all web applications.
4. Code should have full XML comments such that they are sufficiently descriptive when documentation is generated from it.
5. Hungarian notation will summon the four horsemen of the apocalypse and should therefore be avoided at every cost.
6. Never write from scratch in JavaScript that which can be found in a stable, supported jQuery plugin.
7. Include only those features that have been explicitly asked for by the customer.
8. Major features cannot be released without first passing a peer review.
9. Business values and variables should never be hard-coded under any circumstances.  Offenders will be exiled to supporting IE6 for the rest of eternity.
10. HTML should never be rendered explicitly through code.

A list of key concerns such as this doesn’t undermine your larger standards document; nor does it replace it.  It is a quick reference so that developers can get an immediate grasp of your expectations around delivery.  If further information is needed, the standards document is where this should be found.

Baseline Standards Document

Having outlined all the considerations for writing a good standards document, it seems almost unfair to then expect you, dear reader, to then go off and write the whole thing from scratch.

Start by having a look at this development standards baseline document and see whether it might serve as a good starting point for your own internal documentation.  This document is written with Microsoft .Net shops in mind – particularly web application producers.  However, it should be easily adaptable for any development situation.

Much of the content is taken from the Microsoft Coding Guidelines site, with business-specific content prepended.

Hope this helps.  Enjoy.

Within this waste category are seven subcategories:

• Partially done work
• Extra processes
• Extra features
• Task switching
• Waiting
• Motion
• Defects

Partially done work, to quote Mary & Tom Poppendieck’s book, Lean Software Development: An Agile Toolkit:

Partially done software development has a tendency to become obsolete, and it gets in the way of other development that might need to be done.  [It] ties up resources in investments that have yet to yield results.

If the partially done work never makes it into production, that effort is effectively written off, which carries a significant financial impact.

But what about software that’s already obsolete?

Without citing chapter and verse about TQM and Quality Assurance processes, software carries an implicit total cost of ownership.  So often, we see a business or client who, on receipt of the product, smiles thankfully and never touches it again.  But software is like a house: it needs maintenance or it deteriorates.  The longer it is left to languish, the more holes begin appearing as time or technologies move on and extra features are gradually added over time, reducing its stability while increasing complexity.

So does obsolete code fall under the “partially done work” category?  In my view, close but it’s not quite a fit.  What about defects?

According to the aforementioned book:

The amount of waste caused by a defect is the product of the defect impact and the time it goes undetected.

This is probably a better fit for out-of-date code, but still doesn’t quite grasp at the insidious effect age has on software.  Even if no actual defects are encountered in a 6 or 7 year life span, the real implications aren’t felt until it’s time to upgrade the hardware or add that one last feature that requires a full rewrite.

I don’t believe it is any one person’s responsibility to ensure that software is regularly maintained and updated.  However as the team lead / development manager, you have a responsibility to clearly illustrate the costs and risks of aging code to the executive, client and any other decision makers.  Chances are this is the sort of topic that has been given approving nods and murmurs of agreement, followed by “we’ll definitely put that on our list of things to do… right after we finish the current backlog of work for this other project”.  Putting it off till tomorrow is a guaranteed way to ensure that it gets put off indefinitely.

Typically cost is another reason why investment is not made in existing applications or sites.  Too often the perception that “we just don’t have the budget for that right now” is an acceptable final word on software maintenance.  And that may well be true, but what is also left unappreciated is the rising cost to ultimately make the decision to upgrade.  The longer this is left, the harder to carry out it is.  Code ages, environments and operating systems come and go and complexity (or worse, convolutedness) increases as different developers come and go, adding their own style to the code base.  Saving a little money now neither does the developer, the client or the company any favours in the long term.

There are two (well, there are plenty but I’m picking on two) solutions to addressing obsolete software: push for (demand, even) a commitment from upper management to invest back into their software to ensure that the application doesn’t cost more to maintain (or even completely rewrite) in future.  Alternatively, just get on and start upgrading.  Explain that no more major enhancements can be facilitated until the code base is in a more stable and maintainable state.  One of these will probably meet more resistance than the other.  In my experience, it is often the former.  If a business has neglected an application to the point where it should almost be condemned, it also means they probably aren’t paying much attention to their software assets generally and are therefore either unwilling or unable to make good, cost and risk-based decisions.

Because ultimately, what is the alternative to fixing now or fixing later?  If your company is prepared to let its developers spend twice as much time (or more) adding new features or fixing bugs than they have to, perhaps it’s not the sort of company that has the sort of sustainable culture that allows a developer to thrive anyway.

This is the first time I’ve actually had the word “Lead” written into the role, which to many people might be quite alarming.  Why hasn’t this job function been formally recognised before?  The answer is that in all my previous roles, I have built a new team from scratch as a senior developer and the job description has never really adapted to reflect the broadened job functions.  This time I’m going into an established team and therefore a pre-defined recognised position.

Given that my job function will now require me to actively manage my team of developers (as opposed to the implicit “develop first, workload management second” expectation of my previous role), I feel I have finally reached a point where I need to place considerably more focus on my management skills.  This will be a challenge because, like many technical team leaders, I’ve had very limited chances to observe really good management in action.  Much of my line manager’s day-to-day activity has happened “behind closed doors”; precluding me from learning the tasks and challenges I need to understand.  To quote Esther Derby and Johanna Rothman, “poor managers create the illusion of productivity through busyness”.  Fairly or unfairly, my line managers’ productivity has often seemed illusory because it was actively hidden through unshared calendars, high levels of unavailability through absence and a lack of communication.  I should point out here that I am not suggesting my managers have always been unproductive.  Merely that I have not been given an opportunity to understand how they structure their workload to create an effective management style.

So I have elected to seek out an alternative source of management training in an excellent book called “Behind Closed Doors” by Esther Derby and Johanna Rothman.  As I progress through my new role, I will be writing here about my experiences in learning about the people and the work, building the team and its capabilities and identifying areas where my team can add real value to the business overall.  I’ll look at how the development team’s commitments and capacity are placed and how I can strengthen the team’s processes and throughput.

My next post (due at the end of June) will look at my first week on the job and the challenges I face in learning a new company’s products and services, my team’s role in facilitating those and how I ease myself and my team through the processes of Forming, Storming, Norming and Performing.

My hope is that these regular posts provide some valuable insight for others in similar situations.  I would be very surprised if I was the only one who found himself faced with these new challenges and hopefully I can pass on some experience and useful ideas to you along the way.

Technical Debt

Every developer has at one time or another faced the situation where the client asks for a “minor change” to the stated requirements.  Often this might be wording, layout or styling.  Other times it could be a functional change that appears to be a minor tweak but has far-reaching impacts that cause your household appliances to eat your pets.

The difficulty (at least for me) arises when the client says something like

It’s just a small change, isn’t it?  It should only take you an hour at most

This always makes me uncomfortable because I want to do what the client’s asking (I like to please people) and from their point of view, they’re quite right that the change they’re asking for appears to be a very simple one.  However, I also know from experience that since they’re asking for this change during our release phase (i.e. we’ve done testing, UAT and pre-production) and it Just Can’t Wait it’s extremely risky and means that the testing I’ve done will effectively be rendered invalid and my version control will no longer reflect what’s being released into production.

So what are some good counter-arguments to clients who simply have to get that one last JavaScript animation on that text block?

Your Software Mortgage

Your Software Mortgage is the technical debt you incur whenever you have to “just get it done” at the expense of code quality or attention to process.  This might mean you don’t comment anything and just throw it together quick and dirty in time to meet your deadline or you don’t document this part for your handover & support notes.  The upshot is of course that you’ll have to go back and do it right at some point.  The cost of having to do this instead of concentrating on your next iteration is your technical debt.

It’s not a 1:1 relationship either.  To get your code back to an acceptable standard (“paying your mortgage off”), you have to forego spending time on your next set of deliverables.  This means that not only is the client paying for deliverables that can’t be started yet, they’re also paying again for work that has already been delivered.  In order to make your debt repayments, you either need to deliver the next set of requirements early (ideally without incurring more debt) or negotiate a reduction in scope for the next release.

In order to evaluate the cost of technical debt against cost of lost business opportunities, the client usually benefits from seeing the impacts in dollar terms.  This is would be easy if it was actual money being discussed, but technical debt is a more abstract concept and therefore difficult to quantify.

Quantifying Your Liquidity

Liquidity determines your ability to pay your bills

Being able to put an actual figure on your liquidity gives you more leverage to negotiate paying off your existing debt or avoid taking on new debt.

If your liquidity ratio is high (i.e. you have a high capacity to take on new debt), borrowing against your software quality will likely be less of a risk and you may feel more comfortable taking a quick and dirty approach in order to meet a deadline.  However if you have low liquidity (i.e. you’ve already taken on a lot of debt) there is considerably more risk in falling further behind on your mortgage payments.  As already mentioned, your code base must be maintained to keep a minimum standard of quality and supportability or you risk Software Decay:

[Software Decay is] …code decayed to the point in which fixing anything in a hazardous proposition – every fix is likely to break something else.

So how do you calculate your liquidity?  Accounting has a number of different approaches, but most are more complex than the abstract idea of software management allows.  However, the current ratio, which is the simplest measure and is calculated by dividing the total current assets by the total current liabilities can be loosely applied to code.

Depending on how granular you wanted to get with your reporting, you could either measure Lines of Code (LoC) or discrete functional blocks for a broader view.  Let’s assume you have exactly 100 separate methods that made up your application.  If your latest release required that 10 of these methods were rushed through and needed work, your current ratio would be 100 ÷ 10 which (obviously) equals 10; or – to put it another way – a ratio of 9:1 (i.e. for every code block needing refactored, you have 9 others that are considered optimal).

Deciding what constitutes an acceptable ratio depends a lot on your application’s complexity and size, but a general guide might be that a ratio of 3:1 (i.e. 25% of your code needs refactored) should be considered to be the maximum sustainable leverage your code base can afford and anything over 2:1 should be setting off alarm bells.

In short, keeping your unintended debt down gives you more room to intentionally take on debt when it’s useful to do so.

Risk Ratio

The later through the development / deployment process a change is submitted, the greater the risk associated with it becomes and the higher the cost to fix the consequences of that risk is.  If the client is asking for a change to be made after all testing phases are complete and the release is being deployed, it stands to reason that there is a much higher risk of introducing new problems than if the change had been done in the design phase.  This Risk Ratio is the proportional increase in the amount of work required to fix something relative to when it goes wrong.

The Risk Ratio is an extremely valuable bargaining chip that quantifies the potential cost to the client of their requested change.  It forces them to consider the financial impacts of the change from a cost/benefit perspective.  An example Risk Matrix that has risk weightings from a scale of 1 – 10 looks like this:

This matrix provides a quantifiable measure of how serious a change is based on the iteration’s progress.  You could use this as the basis of a calculation to determine the potential cost in dollar terms for any adverse impacts resulting from an unplanned change.  For example, if the client requested an existing style to be changed on your web application during your UAT phase and that style affected the layout for three pages, then you are tell the client that based on experience, there is a 60% chance that introducing a change at this point will cause a problem further down the line.  Given those odds of just under 1 in 3, there’s an extremely good chance that one of the three pages affected will suffer.

Alternatively, you can use this matrix to argue that any change being made at this point will require 6 times more effort to fix than if it had been raised during the outset of the project.  This is not an outrageous claim when you consider that the requirement might need to be formally documented, approved, developed, unit tested and acceptance tested again.

Technical Inflation

Technical Inflation could be viewed as the ground lost when the current level of technology surpasses that of the foundation of your product to the extent that it begins losing compatibility with the industry. Examples of this would be falling behind in versions of a language to the point where your code is no longer compatible with main stream compilers.

Managing your technical debt and inflation requires you to have a very clear understanding of how your debt is distributed.  Documenting candidates for refactoring is the best way to get a clear idea of the scope of work required to keep your application well-maintained.  This might be done using a source control system such as Microsoft TFS, where tasks, bugs and other work items can be recorded against a particular change or section of code; or using third-party tools such as AgileZen.  Think of this as your Application Balance Sheet where your assets and liabilities can be easily reported on.

Technical Inflation is a direct product of sustained low liquidity and software decay.  The longer you leave something before fixing it, the more expensive it becomes to fix.

Ensure you have a clear idea of how much debt your application currently has so that you can make informed and reasoned arguments against adding any more work to an otherwise hard-to-see pile.  If you need to push back on a client’s demands so that you can ensure the sustainability of the client’s application, you will need evidence of why.  Having your books in order is a critical piece.

Further Reading

Don’t Enron Your Software Project

Monetizing the Technical Debt

Dilbert on Agile

It’s scary how common this situation seems to be.

So often as a developer, I find choosing to acquiesce in the client’s insistence that their enhancement or change is vitally important and, while they’re sorry it’s such late notice, needs to go out right away.

Rather than demand that I am supplied with at least some semblance of a requirements document (thereby incurring the Outraged Stare of Daggers), I reluctantly smile pleasantly and get on with adding the feature.

Problems can snowball

It should therefore come as no surprise to me (or anyone else) when, after the fifth “last change” the client comes back for, I find myself wishing I’d saved everyone the cost, effort and frustration of having things explicitly written down from the outset.  Yet this situation is just so very common that it makes me wonder why it’s such a hard lesson to learn.

The difficulty in these sorts of situations arises typically when the change being requested is “just a small 5-minute job” or when “the colouring-in department won’t approve this feature unless we change these items”.  Each concession on a development iteration creates a precedent that becomes the expectation for all current and future iterations.  In other words, each unmanaged change that is allowed through without written requirements carries an exponentially proportional degree of risk the further through the delivery process you move.

Why is this so difficult? Well, the client (or their appointed representative) has a great deal of personal ownership in getting the feature exactly right.  If they’ve forgotten or omitted to include a detail that – while arguably insignificant – they absolutely must have, they will plead, cajole, argue and assert their case to the point where it’s often easier to simply comply than to appear pig-headedly stubborn.  The downside here is that you create – or at least contribute to – a sort of Parent / Child relationship where one party is always trying to bend the rules or circumvent established processes and the other is always resisting the temptation to concede to those demands.  It’s unhealthy for your team, it’s unhealthy for your process and it’s ultimately unhealthy for your client because that risk adds up: either as technical / design debt, increased development and testing cost, decreased auditability of design, or any combination of these.

So what’s the solution?  To always say “No” every time to teach your stakeholders a lesson?  Say “Yes” every time and make sure you document the discussion somehow?  Neither of those options are realistic or sustainable.  The best approach is to ensure you have communicated a clear and consistent process for handling this sort of situation up front before the issue actually arises.  I’m a recent convert to the Lean Software Methodology because I like the freedom it offers for requirements changes as part of a defined process.  The specifics I’ve outlined for my stakeholders work like this:

• The development team works in 3-week development cycles with an additional week for requirements review and workshops (workshops MUST include people from development, business analysis and the client)
• Changes can be made at any time so long as those changes have absolutely zero impact on delivery timeframes or test effort
• Any changes can be added to the requirements but will only be commenced once development is complete on the originally-scoped requirements being used as the basis for the current iteration
• Changes that absolutely must be included in the current iteration can be included as long as all parties accept the delivery impacts and risks

To help make the Production Line run as smoothly as possible, there are some basic rules that will help grease the wheels:

1. Always have clear lines of ownership. Know exactly what you are supposed to do and ensure others know your domain of responsibility as well as theirs.
2. Know your environment. You can’t know everything, but what you can know try to know it well.
3. Always factor in at least 10% contingency.  Try to build a culture of “under-promise, over-deliver”.
4. Credibility is king. Don’t make commitments based on uncertain knowledge; always deliver on commitments.
5. If you find yourself in a hole the first thing to do is stop digging. Old cowboy saying.

All these strategies are well and good as long as the business have defined clear and thorough requirements up front, but I can’t stress enough the importance of rule number 1, above.  Make sure your production line process has clear expectations defined for not only what your outputs are, but what your inputs need to be.  The business has an implicit obligation to provide as full and complete requirements to you sufficiently ahead of time so that you can review them, refine them and respond with accurate estimates.  If you regularly find yourself in a situation where you’re being asked to “just sneak this one little change in”, something is broken. You owe it to yourself and your broader team to get it fixed. Fast.

Empty Production Line

You would think after 18 months of forming and stabilising my development team that we’d have a pretty strong and settled process in place.  But the development team is only one player in a larger ecosystem and how that team is fed depends heavily on the requirements that they are given.

When you’re in the software building business, the pressure to deliver something – anything – by a certain date can be quite intense.  Sometimes its because a marketing campaign is scheduled, sometimes because a product is being released that the software needs to tie into or it may be that a service has been promised to customers or end-users by that date.  Whatever the reason, developers work best when given a fixed set of requirements to deliver by a committed, set target date.

Contrast this with a situation where one or more of the following situations occurs regularly:

• The client provides requirements with an assurance that they are “final and signed-off”, but continues to insist that small additions or amendments be made right up until – or even after – the final testing process has begun.
• The client – in agreement with you – settles on a deliverable date by which all scoped work should be provided.  This is then casually pushed out to accommodate scope creep or alter the requirements.
• The functional requirements are running late and the client asks that you just get started with what they’ve documented so far and the rest will be added in as you go.
• The final requirements provided to the development team include numerous assumptions, vague functional specifications and “documented omissions” that will – assuredly – be provided in due course.

People generally don’t enjoy working like this.  There is motivation, job satisfaction and a personal sense of pride (among other benefits) to be found in the challenge of achieving a goal.  People – and developers in particular – work well under conditions of managed stress and challenges where there is a tangible reward to be found at the end.  That reward is self-respect, the pride in achievement, appreciation, recognition or respect of the client and stakeholders and satisfaction in the delivery of a quality product.  Take away the measures for those motivators and you take away the motivation as well.

The Problem

Consider these scenarios:

1. Your development team is working to a tight deadline, busting themselves to achieve it.  At the last minute it gets moved out. Your team was expecting victory, some congratulations and appreciation (maybe a cake), and instead all they get is more work.
2. The team is working to a difficult deadline, and must cut corners. They build things quick-and-dirty because time is short and it’s better to have something ugly that works than something beautiful half-built. The deadline is pushed back and now the team (or, more likely, the Team Lead) have to explain why they did such a rough job. The time to clean it up is longer than the extension.
3. The deadline gets moved out, so the team realigns priorities, working on the new goals for the altered requirements.  The estimate for work is recalculated and work carries on towards the new deadline.  This happens once – maybe twice – more before the final deliverable is released.  The line manager asks the Team Lead how the original estimate compared to the actual development cost and the Team Lead must explain why the scope and cost started at Point A for $10 000, but finished at Point C for a total cost of $25 000.  (Even worse is if you have no adequate measurements of effort spend per developer and cannot even provide figures for how the estimate compares with the final product).

Vague deadlines open the door for:

• Delivery dates that are hard to commit to
• Meaningless estimates
• Impact on scope for other deliverables

Conversely, vague requirements lend themselves to

• Scope creep
• Technical deficiencies
• Redundant or inaccurate estimates

As a product owner, line manager or client, you should be concerned about this because

1. Your development costs begin to run away on you
2. Your product quality slips
3. Your development team becomes disillusioned, disaffected or cynical
4. Future projects are put at risk as your development team becomes accustomed to deadline extensions and scope changes

Any one of these issues should be enough to cause concern – if not from a purely cost point of view then from a risk and succession planning one.  So what steps can be done to ensure that the psychology of your software shop team is healthy and robust?

The Solution

When it comes down to it, there are two broad ways in which you can remedy the state of delivered requirements and conditions under which you are expected to deliver the final product: influence the client (i.e. require them to adapt their processes to accommodate your needs better) or influence your environment (i.e. adapt your own internal processes to compensate for those factors outside your control).  The first is harder to achieve in large amounts although depending on what is asked of the client and how the request is packaged up, some results may be better than others.  The second allows more immediate and practical scope for change, but may not provide the breadth of control needed to effect meaningful results.

To this end, the following strategies can help you add value to your own service delivery:

• Ensure you have tools for defining when a deliverable has been satisfied.
• Ensure estimates are based on tiny tasks, each no longer than a day or two.
• Ensure requirements are measurable (e.g. “Function X should work in exactly this way…”) and work with the client until they are.
• Build to your own shorter fixed time frames (e.g. monthly) that can be dove-tailed into the client’s delivery deadlines.
• Deliver only to your agreed time frames and initial scope, with any deadline or scope changes being pooled into a backlog to be commenced on completion of the original project requirements.
• Ensure you leverage the tools you have to give you meaningful information about how your production process is performing and identify ways in which it could be streamlined.

The concepts around Lean Software Development provide excellent, non-prescriptive strategies for approaching the development process and for looking at key areas in which to improve: in particular, minimising waste.

Well-Tuned Production

Ultimately, the best approach is to engage with the client and agree on a requirements / product delivery process that affords each party the flexibility they need coupled with the policies against which they can most effectively operate.  Setting the expectation with the client that late or incomplete requirements will result in those affected features being delayed for a future iteration (or until the requirements are satisfactory) and then committing to that will create a culture where there are consequences for a relaxed approach and reduces the waiting around or re-work for the development team.

No project – or any other relationship for that matter – can operate in strong and healthy way unless both parties are communicating effectively and often.  The development team can feel empowered and resolute with fixed, predictable deadlines and a set of confirmed, explicitly-defined requirements.  The client can feel more comfortable about their requirements delivery knowing that they can provide only those instructions that have been properly thought-out and need not operate under pressure to some intangible time frame.  Both parties know that if something can’t be provided in this iteration, it will not be forgotten and gets scheduled for completion on the next pass.

Protecting the head space of the development team is often stated to be the sole responsibility of the TTL, however the reality is that it often takes the contributions of a number of stakeholders to really create the sort of environment where the developer can fully thrive.

As the TTL, it is typically your role to ensure that team members are shielded as much as possible from counter-productive working conditions; minimising their effects where possible and trying to effect some change where practicable. However trying to achieve this on your own can be taxing at best and near-impossible usually. This is where your own line manager comes in. Just as it is your job to work on clearing the path for your team to work at their best capacity, so it is your manager’s responsibility to enable the same for you. Having an effective and actively engaged manager is a – regrettably – often rare privilege.

Engage with the team and understand their project

Having an active interest in the project helps ensure the development team feel recognised, appreciated and valued.  This doesn’t mean taking an active hand in the running of the team, micro-management or making decisions on the team’s behalf, but just having a physical presence adds a great deal from a psychological point of view.  The TTL will generally feel that their work has visibility and adds value, the fact that management aren’t interfering but still taking an interest sends the message that they are on the right path and the TTL will feel that issues or problems will be taken seriously and can be addressed easily because the manager is readily available for those types of discussions.

Support your Team Lead and back their decisions up

Typically the TTL role has only implied authority but no formalised line management, financial responsibility or personnel (hiring) authority.  Therefore, when the TTL makes a strategic decision or delivers a communication around a particular issue, it is reasonable to expect that such an act is well-informed and well-intentioned.  In these cases, the TTL needs to know that their line manager has faith in their ability and will support their decisions.  If  the manager just sits on the fence or tries too hard to please everyone, then the risk arises of an implicit message, “You have no autonomy or authority and I will undermine your decisions if they don’t fit my personal style”.

This form of Defensive Management is destructive and shows that the manager doesn’t trust his / her own people.  People who feel untrusted have little inclination to feel engaged in their company or to bond together as a team.

The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded.

Respond to TTL communications and proposals in a timely fashion

It’s to be expected and quite understandable that managers are typically busy people and are often away from their desk. The usual approach to this is for the TTL to send an email asking for a response or an approval for a particular action. Not responding (or – at a minimum – agreeing to respond by a certain date) sends a dual message of “Not only am I not physically present when you need my input, but I don’t view your communications as being important”.

This point relates to the previous in that a development team, and the TTL in particular, rely on the reassurance that the team is headed in the right direction.  Think of it as the “I told her I loved her when I married her” style of management.  If management aren’t treating issues, communications and requests for action with an audible degree of urgency (even if the response is, “let me think about it and get back to you by…”), then the team members are left to fill in the blanks to their own detriment: “my manager doesn’t respect this team”, “this company doesn’t care whether this team performs or not”, “I only hear back from my manager when something goes wrong”.

An effective leader is one who doesn’t need to interfere, audit or control the operations of a development team, but is available for discussion, makes a physical effort to show their presence on a regular basis and acts quickly on communications sent by the TTL or team members.  He or she will give the TTL freedom to act in the best interests of the team they are leading and the freedom to be wrong in the manager’s eyes.  In short, they act in a way that sends the implicit message that the team’s efforts are valued, respected and visible to those outside of the immediate project.

Recognising a team’s work and their efforts regularly demonstrates tacit approval, encouragement and respect.

Documentation - The TTL's best friend

What about writing a longer essay that described your job function in greater detail? Would it become a description of an ideological role that you couldn’t really achieve in practice?

I was recently required to write just such a document: a Technical Team Lead “Charter” that described what my job function was, what the measurable goals of that function were and (as I found out later) something that would then be used as the basis of performance measures in the upcoming year.

My first attempt can be viewed here. Comments and feedback most welcome as usual.
Technical Team Leadership (PDF)
Technical Team Leadership (DOCX)