How to appraise a developer (part 3) – A worked example

This post forms part of series, if you’ve not done so already you may want to take a look part 1

Last time round I promised to provide a worked example of how the scheme might work, this post will chart the early careers of two fresh out of university  programmers, Alice and Bob. Alice and Bob are both smart people but have very different skill sets, Alice is a hard core dev and really has no desire to go into management, Bob on the other hand is weaker in terms of pure programming but is better with people and organisation.

This example is a little artificial since, in order to show case the scheme, Alice and Bob are pretty much polar opposites. Real world examples will be much more subtle, though hopefully by demonstrating a toy example it will become clear how to apply the same ideas once real people are involved.

Day 1

Our story begins as Bob and Alice join FantastiCo as graduate programmers. At this stage it is only necessary to identify the Core Knowledge Areas for their respective roles.

Alice

Alice is working on FantastiCo’s core platform, she has no customer facing responsibilities and while she works within a larger team, has no responsibilities outside of the code that she produces.

Bob

Bob will be writing plugins to unleash the awesome power of the FantastiCo’s core platform, the plugins are typically developed with a lot of client interaction and while Bob will not be expected to deal with clients on day one, once he gets up to speed this will become a significant part of his job. At this point his Core Knowledge Areas are the same as Alice’s but also include the ‘Client Comms’ Knowledge area.

6 Months

Alice

Alice is progressing well and coming along as expected, she has made less progress in areas such as Quality and Design though at this stage this is really just a reflection that her role is not yet providing the necessary opportunities.

Bob

Bob is clearly a good communicator but there are concerns that he doesn’t spend enough time testing his code. Like Alice, Bob has not made very much progress in Design and Quality but at this stage this is not a concern.

18 Months

Alice

Alice is demonstrating considerable technical skill and this is reflected in a strong performance in Construction and Technology. She is starting to approach the criteria for progressing up to Software Developer ii. The best way to do this is look at moving Operations or Design up to full Practitioner. It is also worth noting that Alice is starting to develop Project Management skills despite this not forming part of her Core Knowledge Areas

Bob

Bob continues to develop well in communications and while not as strong at Construction he is close to reaching Practitioner status. He is still not making progress against Testing and Quality which is starting to limit his effectiveness. In order to be promoted to Software Developer ii he needs at least three Core Knowledge Areas at Practitioner and the remaining Core areas at least Introductory. He’s getting close but he needs to start taking more care in ensuring that his code does what he says it does. Like Alice, Bob is also making progress against Project Management.

2 Years

Alice

Based on the proposed Ladder Levels, Alice is now at the stage where she can be considered for promotion to Software Developer ii. Her manager is very a happy for this to happen and Alice is promoted.

Bob

Bob has shown improvement against Quality and Testing, but still does not have the practical skills to adequately test his code, ultimately this limits Bob’s overall effectiveness and blocks him being considered for promotion to Software Developer ii.

2.5 Years

Alice

Now that Alice is becoming increasingly able she is taken on more responsibility for Project Management, while she does not have formal project management responsibilities it is now an important part of her role and has been added to her Core Knowledge Areas.

Bob

Following his previous review Bob has worked hard to improve his testing skills and he is now ready for promotion to Software Developer ii. Bob has joined the mentoring scheme and this is reflected in his progress against Line Management.

4 Years

Alice

Alice is now a highly respected developer and is starting to approach the point we’re she can be considered for promotion to Software Developer iii. Note that despite the fact that she has started interviewing, Recruitment is not a core part of Alice’s role.

Bob

Bob has recently shifted roles and is the Technical Project Manager of a small team. As such his Core Knowledge Areas have changed, in Bob’s case it is appropriate to remove Construction and Testing. Note, Bob’s role has changed but he still remains at the same ladder level of ii, having said that his new role means that he has greater responsibility than he did as a Software Developer ii and is compensated accordingly.

5 Years

Alice

Alice has been promoted to Software developer iii but has also shifted roles to Tech Lead , her project manager considers her input into the personal development of team as an important part of her role and Line Management is now a Core Knowledge area, despite there being no expectation that Alice will progress past Introductory. The shift to Tech Lead brings with it greater responsibility and this is reflected in her compensation, it is important to note that Alice could have stayed as an individual contributor without this negatively affecting her ladder level.

Bob

Now as an experienced Project Manager, Bob has reached Technical Project Manager iii status. He has become rusty development wise and his score against these areas has deteriorated since Construction and Testing are no longer Core Knowledge Areas, this is not a problem.

Walk Through Conclusion

After 5 years Bob and Alice consider themselves to be peers despite following very different paths and having very different skills sets. Alice worked consistently well through out the period whereas Bob was initially held back by his skills in Testing and Quality.

Series Conclusion

The scheme’s original aims were to

  • Provide junior and mid range staff something to aim at and work to.
  • Provide senior staff who do not wish to enter management an alternate career path without the fear of adversely affecting their seniority or salary.
  • Be flexible enough to account for nuances in the role of individuals

I think the scheme as it stands makes some real progress against these goals but there is still plenty to be done. Future work might include improving the examples section, refining the Knowledge Areas and tuning the criteria for ladder levels.

This is the last post in the series, I’d be very interested to hear of the experiences of others trying to solve a similar problem, please feel free to get in touch via comments or if you would prefer via email (neil at this domain).

How to appraise a developer (resources)

This post provides support and resources for the ‘How to appraise a developer’ series, If you haven’t read the series this post will make no sense whatsoever.

There are two main sections

Suggested Knowledge Areas

Knowledge Area Description
Coding The creation of software according to a specified design. The primary activity is creating code and configuration data to implement functionality using the selected languages, technologies, and environments.
Design The bridge between requirements and construction, design defines the structure and dynamic state of the system at many levels of abstraction and through many views.
Technology The use of tools, technology, methodologies, and techniques for software engineering.
Operations System installation, deployment, migration and investigation. Working safely with live systems.
Requirements Working with partners/commercial colleagues on an ongoing basis to translate their ideas into something that can be tackled in software.
Quality Activities performed associated with providing confidence that a software item conforms or will conform to technical requirements. Quality is related to testing but considers broader questions such as what strategies necessary to ensure systems work as expected.
Testing Practical means to verify behaviour of a component through unit testing, system/functional testing or manually. Testing is related to Quality but focusses on the practical aspects.
Documentation Activities associated with recording or expressing information about a how a system works.
User Interface Design Designing clear, discoverable user interfaces so that Partners are able to make full use of our systems.
Internal Relations Ability to communicate with and relate to those within the company.
Client Relations Ability to communicate with and relate to clients.
Supplier Relations Ability to communicate with and relate to technical suppliers.
Project Management Resource,task and process management, essentially making sure the right things get done.
Line Management Pastoral care, support and development – most commonly relating to direct reports.
Recruitment Includes CV assessment, interviewing, strategic direct recruitment.

Capability Examples

Below follows some examples to help with assessing a individual’s Capability level for a given Knowledge Area.

The examples are not exhaustive and should be added to over time, what’s more it is not necessary for the employee to satisfy all examples. The examples aim to answers questions like “What does a Practitioner in Design look like?”

Before diving into Knowledge Areas specific examples it’s worth considering the following broad guidelines that can be applied across all Knowledge Areas.

Introductory Rarely coaches others.
Looks to the team for support and guidance.
Practitioner Occasionally coaches others, usually those at Introductory level
Occasionally introduces new ideas and practices to the team.
Leadership Regularly coaches others, their own skills and expertise are amplified through the help that they provide.
Regularly introduces new ideas into the team with examples of where these ideas have been adopted.

Coding

Introductory Can complete simple 1 week (ish) well spec’d tasks/stories alone with some guidance from outside.
Can complete a medium complexity series of tasks/stories spanning a few weeks starting with a fairly loose spec, working along side a more experienced developer.
Practitioner Can complete a medium complexity series of tasks/stories spanning a few weeks starting with a fairly loose spec.
Proposes alternate and superior approaches to problems.
Leadership Takes the lead for large and complicated projects.
Takes the lead on high profile or time critical projects.

Design

Introductory Suggests sensible designs for small stand alone pieces of work.
Practitioner Can be relied upon to reliably produce sensible designs for loosely spec’d medium size projects.
Is sensitive to trades offs between flexibility at the cost of complexity.
Understands the need for maintainable extensible design work.
Leadership Takes the lead for the team’s most difficult design work.
Their work often has system wide architectural implications.
Can point to a number of projects where their design has stood the test of time.

Technology

Introductory Is aware of the technologies used by the team and has some idea of the reasons why one might be more appropriate than another.
Is not expected to make technology decisions, but should have opinions on what technologies they might use for their own tasks.
Has some experience of the technologies used by their immediate team.
Practitioner Has a good level of experience of all technologies that the immediate team make use of.
Has had exposure to technologies not actively used by the immediate team
Can reach decisions about library choice for some supporting technology, should we use JMock, EasyMock or Moquito as a Mocking framework?
Leadership Can make broad reaching project level technolgy decisions – what are the implications of upgrading to MySQL 5, is it sensible to do so?

Operations

Introductory Can spot obvious problems and make sensible first stabs at resolution.
Knows when to escalate a problem within the team.
Can provide basic support to those outside of the team e.g. A first line support team
Can perform system redeploys, noticing obvious problems, however needs the support of team to fall back on.
Practitioner Confident in the use of investigative tools, events logs also Wireshark or Jprofiler to diagnose and fix problems.
Is capable of deploying systems in isolation.
Leadership Handles the teams’s most complex operational issues, potentially diagnosing bugs in libraries that the team relies upon.
The person turned to for the ‘oh bugger’ moment.

Quality

Introductory Understands the rationale behind dedicating time to quality be this unit testing, pair programming, integration testing or otherwise.
Practitioner Regularly suggests ways in which improve the overall quality of the team’s work.
Encourages all members of the team to adopt practices to improve quality.
Leadership Considers the team’s long term strategy.
Can point to series of effective changes that they have instigated to improve quality.

Testing

Introductory Understands the importance of unit and integration testing.
Adheres to the team’s testing expectations
Is capable of writing tests where the code lends itself to testing, struggles in more complicated scenarios.
Practitioner Is capable of writing unit tests in all cases where it is sane to do so, making use of additional libraries over and above JUnit where appropriate.
Has a good understanding over what to test for, and writes tests in away that reduces maintenance load over refactoring.
Through system level testing can build a trusted series regression tests.
Where appropriate can devise manual test to reliable verify the behaviour of the system
Leadership Handles or advises on the team’s most complicated testing challenges, suggesting edge cases and reviewing testing strategies.

Requirements

Introductory Can spot subtle ambiguities in projects on which they are working and asks for clarification.
Practitioner Can work with parties outside of the team to nail down exactly what is wanted, offering advice where the requester is unsure or unclear.
Leadership Is trusted with requirements capture for the team’s largest projects.
Is able to identify alternate approaches to delivering large blocks of functionality.

Documentation

Introductory Where prompted can write clear descriptions of system behaviour.
With guidance can pitch documentation for the intended audience.
Uses code comments to explain how the code works
Practitioner Understands when and where to document
Does not over document
Code comments often explains why rather than what the code does
Leadership Notices where documentation is missing in a structural sense, creating new wiki/web pages as appropriate
Through good doc design, encourages continual maintenance since doc is often used.
Looks for ways to doc in an automated fashion

UI Design

Introductory Adheres to the team UI style
Considers the impact of their UI decisions
Can propose sensible ideas for simple UIs
Practitioner Proposes sane workable designs for complicated UIs
Leadership Takes the lead for the most complex UI challenges faced by the team.

Supplier Relations

Introductory Can raise well bounded faults.
Can express themselves clearly to suppliers
Typically chooses to communicate asynchronously over email (or similar)
Practitioner Chooses a suitable communication means though is confident to use a real time method.
Can follow up and present a clear argument where the supplier does not agree with our assessment of a fault.
Leadership Draws upon a network of contacts to circumvent bottle necks to achieve their goal quickly.
Through excellent interactions improves our relationships.
Understands when and how to raise matter through commercial channels

Internal Relations

Introductory Can express themselves clearly at a team level.
Practitioner Pitches their communication to a suitable level taking into account their audience and the context.
Has dealings with multiple departments within the company
Leadership Talk confidently to senior members of the company in different departments/countries.
Handles difficult or sensitive issues on behalf of their team.

Client Relations

Introductory Typically chooses to communicate asynchronously
Understand the difference between internal discussion and client facing communication.
Practitioner Understands that some information is sensitive and should not always be given to clients.
Can get to bottom of what clients are *really* asking for.
Can say ‘no’ in a constructive way
Chooses a suitable communication means though is confident to use a real time method.
Leadership Handles sensitive issues with large clients.

Line Management

Introductory Mentors junior members of the team
Assigned to help new members of the team to get up to speed
Practitioner Has formalised Line Management responsibilities
Leadership Line manages other managers.
Introduces new ideas to other line managers
Track record of handling sensitive or difficult line management issues

Project Management

Introductory Can keep track of non trivial lumps of functionality, perhaps they are not the only person working on the project.
Can provide sensible estimates and commitments for non trivial blocks of functionality.
Practitioner Has formalised project management responsibilities. Manages team projects on behalf of the team.
Leadership Manages multiple teams, provides advice and guidance for other PMs
A track record of successfully delivered blocks of functionality.

Recruitment

Introductory Assesses CVs
Can interview along side a more experienced recruiter
Practitioner Able to interview 1st rounds solo
Provides advice on CV review
Implements and develops direct recruitment projects
Leadership Develops interview/ CV assessment system
Instigates new direct recruitment initiatives
Meets with agents
Experienced final round interviewer

How to appraise a developer (part 2)

This post forms part of a series, if you’ve not done so already you might want to check out part 1.

So last time I talked about why on earth you might want a performance appraisal process, this time around I want to go over the scheme I came up with. At this point, I’d like to stress that an annual review is useless without continual follow up via day-to-day interactions as well as specific time set aside for 1-1s. Furthermore, without good management you will always fail, whatever the process.

The key aims of such a scheme are to

  • Provide junior and mid range staff something to aim at and work to.
  • Provide senior staff who do not wish to enter management an alternate career path without the fear of adversely affecting their seniority or salary.
  • Be flexible enough to account for nuances in the role of individuals

Warning

This post contains phrases like ‘Core Knowledge Area’ and ‘Capability Level’, I have managed to avoid ‘Leverage Synergies’ but you get the idea. You have been warned.

Areas of investigation

Before starting it seemed sensible to see if there was anything already out there that I could make use of. By far and a way the best resource I found was the Construx Professional Development Ladder, which in turn is heavily based on SWEBOK.

I also looked into Dreyfus modelling, which is a way of characterising improvement in a particular skill and used by coaches of all disciplines, from what I can tell the SWEBOK (and Construx) capability levels are based on the Dreyfus approach.

Overview of the scheme

Overall performance is split into a number of Knowledge Areas, this means that strong or poor performance in one area does not affect performance in another unrelated area. Once defined, Knowledge Areas are assessed against standardised Capability Levels and the resulting spread of skills is reduced to an overall Ladder Level.

This means that people with wildly different roles can be expressed in terms of one another, this is absolutely crucial in tackling the question of progression for senior developers who do not have formal management responsibilities.

The appraisee has full visibility over the analysis which forms the basis for further professional development and only the final aggregated level is made public.

Knowledge Areas

Before anything can be done it’s necessary to find a way to break down the role into specific skills, this means that feedback can be provided in a very targeted manner. Good appraisers do this naturally but since the feedback needs to be quantifiable the extra layer of formality is necessary.

I’ve identified 15 knowledge areas, these are largely based on the SWEBOK areas with a few additions/alterations to reflect my specific working environment. Were I thinking about including a wider range of roles (e.g. Sys Admin or Support) or to consider such a scheme for another company, then this table would need to be adapted.

The full list lives here, but a couple of examples include :-

Knowledge Area Description
Coding The creation of software according to a specified design. The primary activity is creating code and configuration data to implement functionality using the selected languages, technologies, and environments.
Design The bridge between requirements and construction, design defines the structure and dynamic state of the system at many levels of abstraction and through many views.
Technology The use of tools, technology, methodologies, and techniques for software engineering.
Operations System installation, deployment, migration and investigation. Working safely with live systems.

Core Knowledge Areas

It is not the case that all developers should expect to score highly in all areas, in fact the point of the scheme is to recognise variance in roles. As such some Knowledge Areas will be unavailable to some appraisees, Recruitment is a good example. However it is important to recognise that some Knowledge Areas areas are central to the performance of the individual regardless of what else they are able to contribute and that they are expected to score well in these areas. For example it is hard to envision a Software Developer for whom Coding is not a core skill however it may not be necessarily be a core skill for a Project Manager.

For each individual the appraiser must select a a group of Core Knowledge Areas to reflect what is most important about the role. Roughly ten Core Knowledge Areas from the total fifteen feels about right.

Capability Levels

Once the Core Knowledge Areas have been identified, it is time to grade each level. This part is fraught with problems and I’d be kidding myself if I thought this step could be completely fair. However I found the following to be a serviceable starting point.

Capability Level Description
Introductory The employee performs or is capable of performing basic work in an area, generally under supervision. The employee is taking effective steps to develop his or her knowledge and skills. In general the employee looks for support and guidance from the immediate team
Practitioner The employee performs effective, independent work in an area, serves as a role model for less expert employees, and occasionally coaches others.
Leadership The employee performs exemplary work in an area. The employee regularly coach employees and provides project as well as tech team level leadership. The employee is recognized within the company as a major resource in the knowledge area

In the future it may be necessary to define a level of achievement above Leadership, in which case it could be defined as “The employee is universally acknowledged by those who have achieved Leadership in a particular knowledge area to be a company expert in the area – essentially providing leadership for those already at Leadership level”.

Mapping actual performance to Capability Levels is made much easier through example and I’ve included a selection broken down by Knowledge Area here. In the general sense I have found the following to be a good guide.

Introductory Rarely coaches others.
Looks to the team for support and guidance.
Practitioner Occasionally coaches others, usually those at Introductory level
Occasionally introduces new ideas and practices to the team.
Leadership Regularly coaches others, their own skills and expertise are amplified through the help that they provide.
Regularly introduces new ideas into the team with examples of where these ideas have been adopted.

Ladder Levels

Once the appraisee’s Knowledge Area’s have been defined and assessed an overall ladder level can be assigned. This is important because this is the only part of the scheme that it made public to the company as a whole. In my current context three levels feels most natural. Other teams may benefit from a higher resolution.

Level Requirements Description
i Default grad level Entry level position, makes a positive contribution to the team but requires support and guidance from those around them.
ii 3 areas at Practitioner and Introductory in all other Core Knowledge Areas A key member for their team, they are able to work with little guidance and act as a trusted peer to other grade iis as well as providing support to those less experienced. Team members on this grade will have a few years commercial experience.
iii 3 areas at Leadership, 8 areas at Leadership and Practitioner combined and finally Introductory in all other Core Knowledge Areas A leader at development team level and a significant contributor to the tech team as a whole.

Summing up

So in summary, look at the appraisee’s role, pick the most important attributes and mark them as ‘Core’. Then grade them against all Knowledge Areas, this forms the basis for further professional development. Turn the handle and convert the assessment into a ladder level and hey presto people with disparate job roles can be recognised for their seniority regardless of whether they are pure devs or pure managers, or most probably some combination of the two.

As with anything, I’m always keen to reduce process to the barest minimum possible without things  descending into chaos and I’m aware that at first glance this scheme might feel quite heavy. However without formally breaking down a role, I can’t see a fair and transparent way to appraise technical staff.

Next time round I’ll post some worked examples of how to apply this in practice.

How to appraise a developer (part 1)

So you have a group of young, smart, driven developers working within a much larger team of young, smart and driven developers. This is in many ways ‘great’, particularly since over time these smart driven developers will drop the ‘young’ part and then things really start cooking.

The thing I’ve noticed is, in groups larger than those that can be counted on fingers and toes, there is a very real need not only to have really good feedback over progression, but also for that progress to be recognised publicly.

Most companies address this need via job titles and annual reviews, in many cases they don’t do a great job and in truth do more harm than good.

My current place has grown rapidly from start up roots and for most of my time there everyone vaguely technical had the same title and we didn’t worry too much about it. As time went on we needed a little more structure and a combined project manager/tech lead/line manager role sprung up.

The difficulty being, that suddenly it then appeared that the only way to get ahead was to move into the management role. Having your best developers move into management for no better reason than it being the only option is toxic. It was clear that it was time to map out a technical path for those who wanted to stay close to the code.

The problem is if you do this, then you need a way to tell people where they are today and what they need to be doing to be considered for the next rung up. If this is going to work it’s going to need to be very flexible otherwise you’ll be forcing people to follow the ladder rather than their own natural progression. Let’s keep motivation intrinsic, kids.

Ordinarily when faced with a really tricky management problem the interwebs are awash with great advice. You need to hire great people? No problem, my meetings suck, easily solved, I’m scared to deploy, are you kidding? But on the subject of an objective method of providing developers feedback, that can then be used to feed into pay reviews and job titles, mainly silence.

I say mainly silence, that’s not fair, there’s SWEBOC that inspired Joel Spolsky and Construx, there’s also the quirky but smart Programmer Competency Matrix.

So I decided to write my own, and I thought I’d share it here. Maybe I can even get some feedback.

So the challenge,

The scheme must satisfy the following :-

  • Provide junior and mid range staff something to aim at and work to.
  • Provide senior staff who do not wish to enter management an alternate career path without the fear of adversely affecting their seniority or salary.
  • Be flexible enough to account for nuances in the role of individuals

In part two I’ll outline what I came up with.

Motivation (almost) for free

Individuals and interactions over processes and tools

So reads the first line of the Agile Manifesto. Agile (and Lean) frameworks differentiate themselves from traditional software project management in the value that they place in people.

I’m always confused when I people attempt to separate out line and project management in the context of software. To me they are intrinsically linked, and cannot meaningfully be considered in isolation. In fact I’d go so far as to say that one of the principle drivers of the agile movement is not so much what it says about project management, significant as that is, but more what it says about motivation and simply letting smart people get on and do their jobs.

As an illustration, I’d like to use Martin Haworth’s ‘Ten Tips About People Management’ as a representative article of a more general approach to people management. For each point I’ve highlighted how it is commonly addressed in the context of an agile team.

1. Talk to Your People Often
By building a great relationship with your people you will bring trust, honesty and information. This gives you a head start in Performance Management of your people.

Daily stand ups provide a frequent and regular period to interact with the team. It doesn’t provide one on one time but it does mean that raising impediments and sharing of ideas is common place such that it then feels much more natural for one on one conversations to occur.

2. Build Feedback In
On the job two-way feedback processes gets rid of the nasty surprises that gives Performance Management such a bad name. By building it in as a natural activity, you take the edge away.

Agile is all about rapid feedback. Both at a technical level in the form of TDD and CI and a personal level through daily stand ups and a commonly agreed definition of done.

3. Be Honest
By being frank and honest, which the preparation work in building a great relationship has afforded you, both parties treat each other with respect and see each other as working for everyone’s benefit.

With lead times measured in days, trust and openness are essential for any agile team, where honesty does not exist the whole process collapses.

4. Notice Great Performance
When you see good stuff, shout about it! Let people know. Celebrate successes and filter this into formal processes.

At a team level daily stand ups and visualisation of work flow provides this for free. Furthermore, since features are delivered in a state ready for production, regular product demos provide the customer with a hands on measure of progress.

5. Have a System
Performance Management is a process and needs some formality – especially for good personnel practice and record. This need not be complicated, but it needs to be organised and have timescales.

Agile frameworks have little to say directly on the subject of performance management, though there is an assumption that team members are continually looking to improve their skills and performance. Agile working models introduce the idea of cadence where there is a period dedicated to retrospection and continuous improvement.

6. Keep it Simple
But do keep it simple. If you have a relationship with your people that is strong anyway, you already know what they are about. Formal discussions can be friendly and simple, with formality kept to a minimum.

With an emphasis on verbal communication, it’s easy to have serious conversations in a relaxed but constructive manner.

7. Be Very Positive
Celebrate great performance! Focus on what’s going well. It’s about successes and building on strengths, not spending ages on their weaknesses – that serves no-one. Go with the positives!

Again, constant feedback through regular delivery of working software, reinforces and encourages good practice.

8. Achieve Their Needs
Remember that we all have needs that we want fulfilling. By working with your people to create outcomes that will do this, you will strengthen your relationships and channel effort in a constructive direction.

Since teams are typically cross functional, team members are exposed to a range of challenges, and have a clearer idea of where they feel they are strongest. While an agile framework does not specifically look to fulfil the longer term needs of an individual, it at least attempts not pigeon hole them into a specific roles.

9. Tackle Discipline
Whilst it often happens, Performance Management is not about managing indiscipline. That has to be managed in a different way. By setting clear standards in your business that everyone understands and signs up to, discipline becomes much, much easier.

In the same way that team success and good performance are highly visible to the team, individual poor performance is also obvious. Expectations of good practice are generally arrived at through team consensus and so could not be clearer. If the expectations are inappropriate or unrealistic then the team has the power to amend as necessary.

10. Learn from Mistakes
As part of regular on-the-job and informal review, mistakes will come to light; things will go wrong. By using the ‘What went well? And ‘What could you do differently?’ format, the unsatisfactory performance becomes controllable and a positive step.

Where teams are correct to take take credit for their success, it is equally important that take responsibility for failure. Examples include retrospectives or Lean style 5 Whys root cause analysis.

Software is an industry not always known for the strength of its people management, by pushing human issues to the fore agile and lean frameworks ensure that not only is the management of of the project considered, but also the management of the people. In a practical sense, while applying agile principles won’t necessarily make me a good manager, they make me less likely to be a bad one.

Agile makes me SMART

Performance review 101, objectives should be SMART. Theoretically, SMART objectives make an awful lot of sense to me, but when asked to set objectives for a developer to cover the next 6 months it really doesn’t feel practical.

Normally, where I have a management problem, the agile community is a great source of inspiration and advice. It turns out that while it has little to say about performance review (why should it?), I’ve been using SMART objectives all along in the form of stories.

Let’s have a look at what SMART means and how it applies to stories.

Specific

By breaking down epics into manageable features it’s possible to isolate a small chunk of behaviour, such that all involved have a clear of idea of the scope of the problem.

Measurable

Acceptance tests provide a clear means to determine when the story is done. In many cases the tests can be expressed in terms of ‘Given a set of preconditions, when a specific event occurs, expect the following behaviour’, this serves to reduce ambiguity and provide black and white tests to determine success.

Attainable

Stories are estimated by the developers charged with their implementation. If the developers cannot see a way to approach the problem then it will not be possible to provide an estimate and the story cannot be accepted. At this point the story will either need to be broken down, or reconsidered before being re-estimated in its new form.

Relevant

The story must in some way relate to the bigger picture, to do this stories refer to features recognisable by the customer as opposed to tasks recognisable only to the development team.

Time Bound

Working in time boxed iterations, or alternatively a work in progress limited flow, means that clearly defined expectations for delivery exist. Where these expectations are not met is is clear to all and it is time to discuss what went wrong.

I have a long held belief that one of the main reasons that the agile movement has been so effective is that it builds good management practices in from the ground up. SMART objectives in the form of stories are just one example.

Bad reasons to adopt Kanban

David Anderson recently posted Why do we use Kanban?

He proposes two lists, one entitled ‘Why do we use Kanban’ and a second entitled ‘We do not use Kanban because’, the second list contains complimentary practices that are themselves not a reason to adopt Kanban. For instance it is not necessary to adopt Kanban if all you want to do is dispense with iterations.

The thing I found really interesting about this post is that the reasons my team first adopted a kanban system were drawn almost entirely from the second list. In particular our dissatisfaction with time boxing.

This may, in part, be due to us coming at this very much from a software development perspective, rather than considering the entire value stream.

David lists the following as reasons for practising Kanban

  • Evolutionary, incremental change with minimal resistance
  • Achieve sustainable pace by balance throughput against demand
  • Quantitative Management and emergence of high maturity behavior in alignment with senior management desire to have a highly predictable business
  • Better risk management (the emerging theme in the Kanban community)

It’s only through practising kanban and learning more about the lean principles underpinning it that the real benefits such as improved risk management and greater predictability have become apparent.

Anatomy of a technical Interview

So you decided that you need to hire a new developer , advertised in the right way , vetted the CVs and even thought of some questions . Unless you’re in the 0.1% of people that think that a 90 minute chat is the best way to assess the skills of someone you may end up working with for the next 5 years you’re going to need to think really hard about how to give the candidate the best chance of showcasing their skills in a face to face interview.

This post won’t help with what questions to ask, but it will help with structure and maximising the chance of getting a good performance from a candidate.

Calm them down

First off let’s start right at the beginning, you’ve just met and are about to commence on some small talk, perhaps give an overview of the company – to be honest it really doesn’t matter what you say at this point, the candidate simply isn’t listening. Years of evolution are telling them to fight or flight  and it’s your job to calm them down sufficiently that you can move the interview forward.

Your end goal is to get to the point where you can ask them some really hard questions with a fighting chance of doing themselves justice, but first off there’s ground work to do.

Get them talking

Having helped them settle into their surroundings, it’s time to turn things up a notch and actually get them talking. A pretty good way is to go through their CV, their past work experience, university projects etc. This is stuff that they definitely know more about than you do, and should help them ease into the interview. The key point to remember here is that by asking very open questions and listening to what they consider to be most important or interesting, you can learn a lot about them. Good candidates will start explaining cool and interesting tech that they have used, while others will start talking about co-ordinating this and managaing that. Give people a chance and press them on the tech, but if they’re not confident or worse disinterested, then this is your first warning sign.

During this period you should be thinking about what sort of person you have in front of you, people handle stressful situations in different ways and if you don’t pick up on this you’re likely to miss some good candidates. e.g. if they are shy they’ll need some encouragement or if they are brash and perhaps little arrogant you need to be challenging them and forcing them to justify their assertions.

A final point, and one that I am most guilty of committing, is to make sure that you don’t go too far and overly relax the candidate. Doing so will make it harder for them focus once you start firing technical questions at them.

Getting technical

Before we get into asking any questions, I’d advise the following approach. Present the problem in a form that will probably be too difficult to answer, expect the candidate to need some help and judge their performance on quite how much help they need. This means that you’ll get an idea for how they think, smart candidates will have stretched themselves to solve the problem and poor candidate can at least solve the problem eventually, meaning that they won’t be so traumatised that they can’t concentrate on future questions.

As an initial technical question I’d recommend something pretty straight forward. Something like Fizz Buzz, I find candidates answer these sorts of questions in three different ways.

  • They write out the answer without even having to pause to think and you move on quickly.
  • They struggle a little bit, think things through and get the answer out. This isn’t necessarily a bad thing and might be down to inexperience, but it does mean that they are unlikely to hit the ground running.
  • They really can’t get the answer together and need a lot of leading. Alarm bells are ringing.

Next up I’d raise the difficulty, I’d suggest something wordy and open ended, perhaps some sort of systems level discussion. This means that the candidate can still push the discussion in a direction that they are comfortable with, but make sure that have at least of few things in mind that you will definitely discuss. Again judge them on the amount of leading they need before completing the question.

Now you’re ready to unleash the killer coding challenge, in many respects the whole interview has been leading up to this point, you’ve learnt a lot about them including how to get the best from them, but the next question will really set the best candidates apart. At this point in the interview you also need to consider whether it’s time to bail, if the candidate struggled with the toy programming question and couldn’t impress with your follow up question, then you really have to ask yourself whether it’s worth skipping the final challenge.

I would chose something that is initially tightly bounded but has the potential for significant extension should the candidate be up to it. Exactly what you go for is up to you, but if you don’t stretch the best candidate they won’t want to work for you.

Any questions?

Lastly it’s time to ask the candidate if they have questions, this in itself can be illuminating, though to be fair at this stage, the best they can do is reinforce a good performance. Questions about working attire and hours are generally a bad sign especially if not a final round, questions about version control, project management practices or something that came up as part of the interview are generally good things and provide an opportunity to sell the role.

After the interview

Once the interview is over, it’s time to come up with an decision. How you do is will be entirely down to your specific circumstances. For first rounds I tend to allocate a point for their programming, their systems and general technical common sense and finally a point for how well I think they’ll fit in. Anything over two and half, i.e. a strong performance in two out of the three and a good performance in the third is a thumbs up. For final rounds you can’t afford to let them leave the room if you still have any concerns unanswered. This is someone who you could end up working with for years so err on the side of caution.

Ultimately though, the only way to arrive at a good system is to have a lot of practice. Make sure technical staff are involved at the earliest possible stage and if you make a bad hire, don’t blame them, blame your process and learn from you mistakes.

In Defence of ‘Scrum but…’

Scrum, as a framework, is practiced in many different organisations and can be considered a mainstream approach to software development. To me agile is way of scaling common sense and while I no longer practice Scrum I consider it an excellent implementation and would happily return to it if my circumstances were better suited to time boxing. However as with all great ideas that are adopted widely, there are many instances where people are simply doing it wrong.

Warren Buffett has a neat way of describing this:

First come the innovators, who see opportunities that others don’t. Then come the imitators, who copy what the innovators have done. And then come the idiots, whose avarice undoes the very innovations they are trying to use to get rich.

In the case of software it’s reasonable to replace the goal of getting rich with that of successfully delivering software that is valued by the customer.

As such there are a wealth of posts discouraging the adaption and variation of Scrum, in fact the notion of Scrumbut is so well understood it even has a definition.

scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word “but” when answering the question “Do you do SCRUM?”

Project management will necessarily vary from company to company. As such the ubiquity of a term like Scrum has less value within a specific company, since the shared understanding of the company’s approach ought to be evident to all. When I talk to people outside of my company it’s useful to reference commonly understood terms as a starting point. For time boxed approaches Scrum is an obvious point of reference, but the specific system that I wish to describe is highly likely to deviate from Scrum in some way and I do not necessarily see this as a bad thing.

The challenge of software development is to produce something that someone will find valuable. There are plenty of different ways to achieve this and all are highly dependent on the context of the project. Generally an iterative and incremental approach that bakes quality in from the start is preferable and a number of ready made implementations exist such as Scrum, Kanban or Evo. In some cases it may be appropriate to lift something like Scrum wholesale, but in many other cases, there are legitimate reasons for adapting the process. For example a team might be writing an implementation of a system where the behaviour is well understood. In fact in order for the system to be compliant and therefore usable it must adhere to a large pre-written spec provided by an external party. Clearly this is at odds with Scrum but there is no need for the team to drop time boxing or stand ups as a result.

So adapting a process is not in itself something to be frowned upon. Clearly bad project management is bad, and if the manager blames their own failings on their inability to implement a methodology then larger problems exist. The key point is that good managers should not worry that they are running Scrumbut, or indeed if they are ‘doing it right’ as the only metric for correctness is that the team maximises the value they create.

How to do Nothing

Doing nothing is harder than it looks. As a developer I sometimes found it hard to understand what on earth my boss did all day. In fact the better the boss, the less they seemed to do.

Fast forward a few years and I found myself in charge of other developers, it quickly became apparent that doing nothing was actually quite a challenge. Try as I might something always came up, and I found myself doing something, which as previously mentioned was not a good sign. It turns out that doing nothing is pretty much a full time job, and I’ve put together some tips on how best to achieve it. Now bear with me, some of these activities do technically involve doing something, but if you are careful not to get caught no one will ever know.

  • Anticipate rather than react.

In some senses dashing in to save the day at the last minute is exciting, all the more so if your hair happens to be on fire at the time. However, there is no surer way to appear to be doing something than by intervening in this way. It is much better to notice that something will need to be done ahead of time and to act before anyone else notices that you are doing anything at all. This does mean that you will need to be constantly on the lookout for things that need doing before anyone else notices, however it is a small price to pay for doing nothing.

  • Maintain relationships outside of the team.

Occasionally, despite your best attempts at anticipating problems, your the team will get blocked and require some action on your part to resolve the matter. This is a dangerous situation since if they have nothing to do they are more likely to notice that you are in fact doing something. Therefore you need to act quickly. At this point it’s important to know the right person to talk to and what’s more have a pre-existing relationship with them. That way it will appear that you are just having a nice chat rather than actually doing something.

  • Big visible task boards.

A sure way to get caught doing something is by having your team ask you about what to do next, you can easily get around this by delegating the responsibility to a whiteboard. That’s right you can use an inanimate object to replace a previously essential function. To make this work, it does mean that you may need to do some planning ahead of time, it might even mean talking to more commercially minded folk on the other side of the office but nobody ever said that doing nothing would be easy.

  • Team collaboration

The more time the team spend working together, sharing ideas and learning form one another the less time they have for catching you doing something.

  • Small incremental changes

If you must be seen to make a change, at least be sure that it feels like a natural progression and sensible to all, that way your doing something won’t be as obvious. Once the change has been made, it is critical that you resist the temptation to tinker, not only will tinkering make it more likely that you will be spotted doing something, you’ll never learn what effect your change brought about, which means you might miss out on discovering new ways to do nothing.

  • Inspect and Adapt

Further to the previous section why not ask the team themselves to contribute ideas in order to refine their working practices, this way you can actively do nothing in their presence.

  • Hire great people

Unfortunately there is no getting around this one, while there are plenty of excellent guides available (1,2,3), sadly all of them advocate that you do something. However since it is likely that much of the process will occur in an interview room you can at least hide the fact that you are doing something. You may also find that you spend much of the time listening which can be easily be mistaken for doing nothing.

  • Commit to personal development

It’s much easier to do nothing when your team comprises of highly skilled geniuses. By working hard to consider the needs of all team members you can help them approach highly skilled genius status thereby reducing the need for you to do things. Over time you may even find that they appreciate taking on greater responsibility, further reducing instances where you will appear to be doing something.

Finally, having assembled and developed a great team, don’t blow it all by checking up on them every forty five minutes, just stand back and do nothing for a bit.