Category Archives: Team

My Thoughts On #NoEstimates

What?

The #NoEstimates idea is to break all pieces of work into similar sized chunks based on a consistent “slicing heuristic”; not give sizes or estimates up front, and hope to be able to predict future development based on how long each one of those similarly complex small tasks ends up taking to deliver. But also very importantly: ensure you deliver regularly.

It’s less about “not estimating”, and more about improving how you work such that estimates are less necessary. Deliver regularly, focusing on the flow, is key to this.

About that slicing heuristic: a heuristic is an approach to problem solving that is known to not be perfect, but is good enough for the time being. So a “slicing heuristic” is best guess at deciding how to split large pieces of work into similarly complex tasks. You’ll make it better each time you try until you something that works for your team.

An example slicing heuristic would be that a feature can only consist of one acceptance test; if you have more than one acceptance test, slice the feature into two or more features.

I’m probably over simplifying the concept, but it’s a pretty simple concept in the first place!

Why?

Whilst coming up with the latest iteration of the development process at Mailcloud, I coincidentally stumbled upon an article about #NoEstimates and subsequently various videos on the subject, and more articles, with support from more articles.

The idea is an interesting one, if only due to my dislike of day-long planning meetings/sizing sessions where inevitably everything ends up being a 3,5 or a 40.

Seems like a lovely idea, right? It also seems fundamentally flawed for reasons such as an inability to give a reasonable quote or estimate to a client up front, especially for extremely large projects. Also, the team has to be able to split the work into chunks of similar complexity, which is easier said than done; ever been in a sizing meeting where everything ends up almost the same size? You require a team’s ability to be consistently effective and efficient, as opposed to just being “consistent” (and not in a good way).

I’m no fan of huge, minutely detailed, projects, so perhaps these aren’t so bad?

Given that I’m one of those pesky critical thinkers, I went out and did a little research on the opposition. There are some extremely vocal detractors of this concept.

The most vocal and well known detractors of #noestimates appear to be those with significant experience in several large projects over more than 2 or 3 decades, with a background in statistical analysis, probability, and software project management.

A quote to sum up this perspective, which appears to have been adapted from a Lao Tsu quote:

“Those who have knowledge of probability, statistics, and the processes described by them can predict their future behaviour. Those without this knowledge, skills, or experience cannot”

i.e., stop being lazy and learn basic stats.

Most vocal and well known #NoEstimates proponents are either also proponents of XP or have more experience in small to medium scale projects and put less importance on statistical analysis.

There’s a lot of – quite childish – banter between these two camps on twitter an in blogs, trying to say who is right, when it’s quite obvious that these different approaches suit different projects; if your client has a fixed budget and a deadline, then not being able to give any confidence in meeting that deadline within that budget (i.e., no estimates) is not going to be a feasible option. Similarly, if you’re not quite certain what you’re building yet, or only know the start and are able to follow the Product Owner and user feedback, then estimating an uncertain backlog to give a realistic finish date is likewise unlikely.

As such, it would appear that you have to – as I always do – make up your own mind, and in some cases take a little from all available sources to create something that works for you and your team or company.

That’s exactly what I’m doing at the moment, and it’s possibly not anything that really exists yet; a little XP, a little kanban, a little scrum, a little noestimates (hey, why not? We’re a start-up!); and a damned lot of trello.

This is Dev Process version v5; I don’t doubt for a second we’ll have a v6, v7, and so on as the team grows and as the product changes.

Interested in learning more about #NoEstimates? You can check out the book, and get a free chapter to kick off with.

No Estimates Book

Is it hard to find good developers?

Following on from my friend’s post about Why is it so hard to recruit good developers? I had written a lengthy comment which I thought I may as well just blog instead for further discussion. This post isn’t necessarily a direct response, but some of my opinions on the problems around recruiting good people.

Motivation

motivation-1

I think this talk from Daniel Pink (author of Drive, a pretty good book) about a study on motivation sums it up pretty well (and the transcript is here)

People want autonomy, mastery, and purpose; so essentially “don’t micro-manage me”, “let me learn”, and a good reason for doing something. (e.g. profit alone is not a good enough reason)

So being told what to do and not think for yourself is demotivating, as is not being given the opportunity to learn and improve yourself.

Candidates : finding people you want to hire

The salary doesn’t need to be massive, it just needs to be enough that it’s no longer a concern. Usually people who are experienced in the industry and spend time bettering themselves through user groups, conferences, and general researching will know what the average salary is for someone with their skillset and abilities.

They’ll put this on their CV as an expectation. Recruiters will use this to match candidates to roles; if the role offers 35k they won’t bother putting forward candidates with current salary/expected salary as 50k. The people they will put forwards instead are those who have a similar salary now or expect to have something similar; usually those people are not as experienced (i.e., recent grads. Although I’ve hired some absolutely amazing grads – the most recent one is giving the seniors a run for their money). not as motivated/less willing to progress (not trying to learn or grow within the company, nor take on more responsibility in a higher paid role), or don’t get involved in their industry/field to improve themselves.

The Position : having a role good people want to apply for

Company attitude to autonomy

Look at Github or Google or Atlassian as examples of companies people would love to work for. Don’t know why Github is so great? Check out Zach Holman’s blog and read some of the posts about what it’s like to work there. They have titles like “Hours are Bullshit”, “Creativity is Important”, “From “Hack” to ‘Popular Project'”, and “Why GitHub Hacks on Side Projects”. Hubot is an incredible side-project success.

Google famously have the 20% rule, where 20% of your work time is dedicated to non-project work. Be creative. 1 whole day a week.

If you saw the Daniel Pink presentation I mentioned at the start you’ll see Atlassian do a day a quarter (or every couple of quarters) for something similar, except they make a big deal of it and provide beers and cake and stuff; the only rule is that you have to present your project back at the end of the day.

Company attitude to mastery

Sending people on courses is one thing, but having – for example – each month of a year dedicated to learning a bit more of a particular technology or language or feature of a language or design pattern or something, shows that you aren’t just focussed on the company profit, but that you love what you do and wan to make sure everyone else does too!

Company purpose

Probably not coming from the company, but from the department or at least the potential boss of the candidate: I, for example, have an aim to get my team members presenting at user groups, conferences/seminars, and the department getting recognition for cleverness in our particular sector. I want them – and by extension our company – to be known as professional developers who know their stuff, who are passionate about learning more stuff, love to share what they know, and ultimately are recognised for it.

Sure, the purpose from above me is to deliver company profit, but that shouldn’t affect their happiness and motivation (just mine!)

There’s the rub

In my humble opinion, if you’re a large company with a large development team and a hierarchy of developers and architects who ultimately prescribe what is to be built by the highly skilled development team, then that company is removing a level of autonomy.

If the focus is always on one specific technology stack and there’s no drive to assess alternatives (or the assessment is entirely outside of the development team), and the team aren’t being pushed to learn things and apply that knowledge, then that company is removing a level of mastery.

However, in my experience, not getting good candidates is usually down to being stuck with rubbish recruiters not having good contacts. Not being allowed to talk to whichever recruiters you like (so long as they can agree terms your company can accept) and evaluate the best ones for certain roles (for example I use different preferred agencies for permanent .Net vs contract UX vs QA, and this is based on good and bad experiences and initially lengthy recruitment processes to allow us to separate those who consistently send good candidates).

So, in summary

If you’re not getting good candidates applying for the role, re-evaluate the salary and the recruiters.

If you’re getting good applicants but no-one wants the job, take a look at what the company offers over others. Maybe it’s actually good but is being marketed to them badly!

This is just one guy’s opinion – I’m certainly not saying it’s working perfectly for me now – but it’s based on several years experience of both good and bad, and being on both sides of the recruitment fence!

Discuss 😉

Grading a Developer

In the beginning, there was chaos

No doubt you’ve worked in a company where progression within your I.T. department, as a developer, is not easy to explain nor measure

Perhaps there is a skills matrix which defines a “senior developer” as someone who does all the stuff you do “but better”. Or this listing might contain things that are not pertinent to your technical role and have quite obviously been copy-pasted from a generic skills matrix template for another company member, or even perhaps from your manager’s previous company which might be in a barely related sector.

I only really noticed this once I became a manager (the peter principle) and was faced with giving feedback to obviously skilled developers and was unable to explain what they needed to do to progress; for me, this was lesson #1 in management: either have good answers to good questions, or find out the answers.

After a lot of internet hunting myself and a colleague in a similarly frustrating situation found a selection of insightful articles from Joel Spolsky about FogCreek developers, SWEBOK, and a Construx whitepaper on exactly these things; defining how to grade a developer within your company, which allowed us to develop our similar system to explain;

  1. how to give complete transparency to each member of your team,
  2. how to collate your team members grades into a “team” grading system in order to identify potential weaknesses,
  3. how to adapt the system to specific roles and requirements.

I’ll try my best to give some sort of structure to this article and in doing so hopefully cover each of the points above.

 

From chaos, came the desire for structure

Following are the steps we took in our attempt to achieve a better grading model..

Recognise the problem in the department

This was the easy part, and essentially was covered in my introduction. The classic “how come he’s a Senior Dev when he’s rubbish at X and I’m great at that and I’m a Mid level Dev?!” question was enough to realise that the existing system didn’t really fit since it couldn’t give a good answer.

 

Conduct a survey of all developers to identify what constitutes a developer’s role and responsibilities within the company

This required us to use the I.T. intranet (a Sharepoint portal) to request feedback from every developer in the company (about 35-40 people at the time) on what they believe their job requires of them; i.e., their key skills, abilities, and responsibilities that enable them to fulfil their role. This took quite a lot of convincing to get enough responses given the lack of conviction in the existing system, but we got there.

 

Find a group of peers to review the outputs and group them into similar genres

This involved getting a peer group together (in this case the 5 or 6 tech leads) who were committed to dedicating time each week, regularly meeting to discuss all of the responses and group them into genres. We were very fortunate that the development team as a whole took the process on board and really delivered some quality comments. The actual results of the request for feedback, already grouped into headings (but not deduped) are below:

Standards

  • Adherence to coding standards.
  • Adherence to industry and company standards and policies
  • Follows industry best practice
  • Writing code that consistently meets standards (Dev and Architecture).
  • Writes clean looking code

Refactoring

  • Improve and maintain code quality.
  • Refactor code where necessary
  • Takes time to go back and refactor own code

Deployment

  • Ability to deploy to project environments.
  • Manage the deployment of code to environment

Environment

  • Environment management (deployments scripts and configurations)
  • Manage the setting up of the development environment
  • Has knowledge outside of development (understands how production works, how systems are administered)
  • Have knowledge of the systems and how the different services/processors etc interact and their dependencies.

Merge/Branch

  • Ability to merge code and understanding of the merge/branch process.
  • Can merge code between branches accurately and reliably.
  • Configuration management (TFS)
  • Understands the branching model and how merges work.

Documentation

  • Writes clean looking code
  • Creates clear and concise sets of documentation around projects worked on for technical and non-technical audiences.
  • Documentation – ability to produce clear documentation for both IT and non-IT people.
  • Documentation (comments in code, UML specifications, SharePoint items)
  • Writes clean, self-documenting code that is well structured, simple and documented appropriately.

Debugging

  • Can the root cause of a bug through various layers of application and is able to fix typical issues at all of these layers.

Agile/Scrum

  • Good knowledge of Agile Scrum
  • Understands Agile methodologies in general and knows how we use Scrum.

Company Systems/Domain Knowledge

  • Ability to realistically estimate tasks.
  • Has a good level of understanding of the Company systems, what each system does (high level) and how they interact with each other.
  • Knowledge of processes used by the business users of the system.
  • Has knowledge outside of development (understands how production works, how systems are administered)
  • Have knowledge of the systems and how the different services/processors etc interact and their dependencies.

Coding

  • Coding in C# (3.5/4.0)
  • Functional testing (BDD, planning, development, execution, evaluation)
  • Good knowledge of sql and adherence to sql standards.
  • Good understanding of requirements.
  • Confident developing applications at client, server and database level. i.e. JavaScript, C# and T-SQL.
  • Knowledge about the frequently used parts of the .NET framework
  • Knowledge and practice of TDD.
  • Proficient in multiple languages (to understand different styles and methods of coding)
  • Unit testing (TDD, mocking, coverage assessment)
  • Use of C#.net and vb.net.
  • Use of front end technologies – jquery, json etc.
  • Writes clean looking code

Patterns & Practices/ Design Patterns

  • Design Patterns (the most used or important ones)

Estimation/Planning

  • Estimation of work items
  • Input into planning of how tasks are to be carried out – what technologies can be used.
  • Knowledge of processes used by the business users of the system.

Presentation

  • Presentation (and other knowledge dissemination skills)

Leadership

  • Coaching
  • Interviewing
  • Meeting facilitation
  • Mentoring

Learning

  • Interest in gaining experience in new technologies.
  • Learning and research

Process

  • Interest and involvement in improving the software development process and the company policies

This gave us 16 reasonably distinct areas to focus on which the group sanitised slightly and ended up with 12 “Knowledge Areas”: Debugging, Standards, Coding, Design Patterns, Documentation, Leadership, Domain Knowledge, R&D, Agile/Scrum, Presentation, Branch/Merge, Environment, and Process.

 

Within each genre, attempt to define distinct levels of ability

Each member of the group took an area each per week and attempted to define a few distinct levels of ability; it was easier for some than others, and some actual level descriptions were more verbose than others. We had agreed initially to use the levels Beginner, Basic, Good, Great, and Superstar (the latter being an overachiever), however it became apparent that defining five distinct levels was pretty tricky for some of the areas so this became Basic, Good, Great (and if possible we added in Superstar too).

Here are a couple of the example areas with their levels defined

Documentation

Basic

Updates where necessary

Good

Create support documents

Great

Creates project handover docs, support docs, implementation docs

Superstar

“Technical Author”: takes ownership, adds missing artefacts, “tech lead assistant” (that’s not meant to sound patronising, honest!)

Domain Knowledge

Basic

Knows where to find the implementation of functionality specific to the area being developed within the codebase/database. Understands the structure and separation of the projects within a given solution and where to make necessary changes in order to implement required functionality

Good

Can identify where software artefacts exists within the domain and utilise these in order to reduce code repetition. Can identify which areas of functionality being developed should be reusable artefacts

Great

Uses extensive knowledge of the system under development and other systems it may interact with to determine various potential implementations for a given requirement, defines the impact of each on each affected system, and uses this to propose the best solution(s)

Superstar

Can suggest fundamental changes to the domain model as the requirements for functionality and development evolve, in order to better fit.

 

Entire developer group reviews the outcome; feedback and rewrite where necessary

Once all of these areas have at least 3 levels of ability defined, the entire product is shared with the development team for honest feedback. The ability levels can be altered at this point, but the main aim is to get buy in and agreement from the majority of the development team.

 

Define “Core” Knowledge Areas

Each company will no doubt have a selection of key abilities for which each developer grade must have at least a minimum rating. Another couple of sessions with the peer group decided what those were for the company:

Junior Dev

  • Standards (Basic)
  • Debugging (Basic)
  • Coding (Basic)

Mid Dev

  • Standards (Good)
  • Debugging (Good)
  • Coding (Good)
  • Design Patterns (Basic)
  • Documentation (Basic)
  • Environment (Basic)

Senior Dev

  • Standards (Great)
  • Debugging (Great)
  • Coding (Great)
  • Design Patterns (Good)
  • Documentation (Good)
  • Environment (Good)

Below is a high level template where the coloured blocks define the core level template for that grade; mauve for junior, green for mid, and peach for senior (please forgive my inability to choose decent colours in Excel).

grading_levels

 

Attempt to define a template for the various levels of developer in the company

Once the Knowledge Areas are defined and the ability levels agreed to, the next step is to try and work out what constitutes the Developer grades within the company. To do this the group took a couple of steps:

Firstly, I unofficially applied the rating system to a couple of my team; one of which I thought of as a classic Senior Dev and one as a classic Mid Dev; once I had worked through this new review process with them we had a pretty good idea of which Knowledge Areas and at what level what a mid and a senior dev should have within the company.

Meanwhile, within the group we worked out a selection of minimum levels in varying groups of knowledge areas, differing per developer grade. For example,

  • Senior Developer: 4 great or higher, 8 good or higher, 10 basic or higher
  • Mid Developer: 2 great or higher, 4 good or higher, 6 basic or higher
  • Junior Developer: 2 good or higher, 6 basic or higher

 

A breakdown of coding ability per language, weighted appropriately for the specific role (i.e., UI dev, regular dev, backend dev, sql dev, etc).

Coding is a tricky one, so we started breaking that right down and making it a little more specific. For example, the devs working on the website though not UX devs would certainly require good jQuery and CSS knowledge, but perhaps less WCF and C# multithreading. As such, a role could define a language matrix, such as this:

grading_levels_languages 

In the example above, a dev would be rated on their abilities in C# (weighted at 60% of the total), VB.net (20%), HTML (10%), and jQuery (10%). The example dev scored a 3 out of 5 in C# ability, 3 for VB, 2 for HTML and 2 for jQuery, giving them a score of 2.8. Therefore the Knowledge Area “Coding” would be able to have a coding language minimum score for each ability level. Perhaps a Junior would need a minimum of 2, Mid 3, and Senior 4.

 

Review process becomes a case of identifying/checking off each entry in the various levels of each genre.

Once this system is agreed by all members of the team, an annual appraisal becomes a much easier case of looking at the dev’s current charts, noting the areas that they’re not scoring highly on, and creating objectives which allow them to focus on improving those areas in order to progress through the ranks.

Anyone overachieving (superstar status) could be temporarily given a bonus of some type; attending more seminars/webinars/events or a salary increase in between their current salary and that of the next pay grade (a great idea from the fogcreek article).

 

Any items missing must be taken care of within a set time period

If the dev is not achieving what their job title says then they can be given a deadline in which to raise their rating in the areas they are deficient. Easy.

 

Transparency of what is required in order to be put forward to promotion

No more “why is he a Senior and I’m not” questions. It’s all out there for everyone in the team to see.

 

Supporting general guidelines for attitude, punctuality etc. cover off talented but unprofessional developers

Add in general “Code of Conduct” checklist so that you don’t end up with “superstars” who are complete…ly unprofessional. For example:

Professional Conduct

  • Team Player
  • Meets Deadlines
  • Organisational Skills
  • Communication Skills
  • Approachability
  • Leadership Ability
  • Interaction With Team Members
  • Interaction With External Departments BA’s etc
  • Attendance
  • Time Keeping
  • Quality of Work

 

Varying levels of detail in the graph can make them specific for the individual (dev-team lead), the team (team lead/line manager), and the department (line manager/head of I.T.)

By overlaying all the charts for all the members in your team you end up with a team chart; useful for deciding which team best fits which new project, which team needs what training, what skills the next interviewee should be tested on in order to help fill a skills gap, etc.

Overlay the various teams’ charts and you end up with a department chart; good for the less tekky but more senior I.T. members.

 

Use the new data to identify potential new roles

We quickly realised that someone with Superstar status in Documentation and general high-mid dev ratings should think about moving into a Tech Author role (which previously didn’t exist). If they excel in Presentation, Estimation, and Agile/Scrum then perhaps focus on becoming a Scrum Master. Awesome at Design Patterns, Coding, Leadership? Become a Tech Lead.

Being able to help people identify not only where they’re weak but also where they’re strong helps to both build a solid foundation and give direction for progression.

 

Conclusion

As far as I’m aware, this process was accepted within the company (I left shortly after it’s introduction and have since learned that another, completely different, method has been “introduced” from up on high..) and I found it much easier giving appraisals when there was a peer review system helping define people’s grades.

It also gave my team specific areas in which to define SMART objectives, and there was a general increase in enthusiasm for this process.

None of this could have been possible without the articles listed below, and the dedication of the Tech Lead team members, determined to make life better for all developers.