Categories
Insights Teams Uncategorized

“Hiring good developers is just like sexing chickens”

A memorable – if not a little disturbing – simile once used by an industry legend during his seminar.

Sensing the discomfort of the crowd, he frowned & bellowed, “Well, you know what I mean, right?” Not a clue, but you certainly have my attention… “It’s like being able to tell the gender of a baby chicken just by looking at it.”

Apparently it’s a subtle art (in the loosest sense of the word) developed with many years of experience, one you can attain to determine chicken gender, or, more usefully in our line of work, developer quality.

I don’t know about you, but I certainly don’t know anyone that has the ten thousand hours required to master that skill.

Anyway, we’d prefer to hire whole coops, sorry, teams of developers for a number of reasons.

  1. The developers already work together so have a quicker startup time.
  2. Cross-functional teams will be able to fulfil all the roles required for project delivery – UX, development, QA, DevOps & so on.
  3. They usually have a project project manager, scrum master or coach who’ll take responsibility for helping the team organise their efforts, report on progress & deliver the project.

Hiring teams is a completely different proposition to a single developer – we can’t make them all do whiteboard interviews. Here are some of the things we look for & ask at Digital Village when hiring great development teams.

Show us what you’ve done (please)

Stand & deliver. We’re technology agnostic & focus on the best processes for delivering reliable value in. In short, we spend less time looking at tech teams work & more looking at the projects they’ve completed.

Are the projects ‘significant’ & did they challenge the team’s ability? ‘Significant’ is of course subjective, but we’re looking for teams with strong capability & ambition.

Are the projects accompanied by glowing testimonials? Unfortunately self-assessment can be a little, let’s say, biased from time to time.

Now let’s talk about it

A curated brochure of past products is nice, but we aren’t window shopping here. We need to dig into things a little (lot) more. A good ol’ fashioned interview with some representatives from the team is a perfect way to find out:

  1. What challenges the team faced while building one of their showcased projects & how they resolved them.
  2. What they enjoyed about the project. Seriously, we’re all supposed to enjoy this or what’s the point?!
  3. Which projects they’re most proud of & why (forgetting pride is of course a Sin).

Abiding by the old proverb, “it’s not what you say, it’s how you say it,” & without dabbling in amateur psychoanalysis, there’s a lot more you can take away from the interview.

Are they excited to talk about the projects? Do their eyes light up when explaining technical triumphs. Perhaps an eye-roll when describing the challenge of containing scope with an ambitious client?

Honestly, the last thing we want to see is ambivalence. We want to see anything to show a deep engagement with all the challenges (technical & otherwise) that arise during a complex project.

If they pass both stages with flying colours, hire them & give them everything they want.

Ok, just kidding. I’d feel very hesitant to hire a team purely on this basis. So, I hear you ask, what are the key questions Digital Village asks before engaging with development teams..?

How do they know they’re building (whatever it may be) correctly?

A simple yet serious question. How do they know what they’re building works as it should? It’s an opportunity to understand their practices, processes & also attitude towards producing quality software.

The answer, of course, should involve a seven letter word that causes more headaches than most: ‘testing’. But what kind of testing? QA staff are great & will pick out errors like a sniper, but automated developer tests are also important.

The bravest programmer you’ll meet (& the one you want to meet) is running a gauntlet of unit, feature & integration tests. “Does my change break anything?”, is just an automated test run away.

Adopting such methods allow teams to stride quickly & ambitiously because the safety net of automated testing is always waiting to catch them after a misstep.

How do they know they’re building the right thing?

At least this one’s simple… “it’s what the client asked for”. Get out.

Every project is a big investment for a client, so how can we be sure the investment is going to pay off?

At Digital Village we have a huge range of clients: start-up to enterprise, tech wizards to non-tech founders. With each client, we assume full responsibility for helping them understand if the proposed project is going to make their business more successful.

If not, we can steer them in a better direction even if it means having difficult (but always positive) conversations. Clients come to us looking for guidance & it’s fundamental to our service that we find the right solution.

So our question for any team is, “how will the client know if what they’ve asked for is what they really need?”

If they reply, “the client agreed to the specification, if the code meets the spec then they’re getting what they want,” they’re not the kind of team we personally like to work with.

I’d love to hear how the team proactively validates work delivered to a client, their strategies for eliciting feedback & how they manage that moment when a client says, “wait a minute, this isn’t going to work”.

So, where is everyone?

Long gone are the days of expectation & necessity for singular locations. We’ve worked with all kinds of teams: onshore, offshore & a hybrid of both. So far, we’ve found each model brings its own benefits & challenges.

If a team has offshore members, great! Some of our current teams that contain offshore members produce incredible results at a fantastic price-point.

Traditionally, communication is seen as a potential pitfall for offshore teams, but our success is due to amazing team leads who are responsible for communicating with project stakeholders locally & team members offshore… a conduit, if you like.

So let’s hear about who is responsible for communicating the client’s needs to the team & relays the team’s questions, concerns & suggestions.

What’s the silent killer of projects?

To be clear, I’ve never asked anyone, “what’s the silent killer of projects?”. One, because it’s over dramatic, & two, there are always symptoms.

I would love to know, however, what the team thinks is most likely to derail a project. Although answers will vary, if this were a game of Family Feud I’d expect “communication problems” to be a top answer.

As Bernard Shaw, a man that revolutionised comedic drama, said, “The single biggest problem in communication is the illusion that it has taken place”.

So what are their individual thoughts regarding communication? How could they be sure a client has understood them (& vice versa)? Perhaps most importantly, will they be willing to take on the commitment to communication that Digital Village does?

Dev teams are often missing one vital piece of the puzzle. The client. Now we aren’t expecting 40hrs a week, but we always try to bring clients & users into the project team. Invite clients to join meetings & the same communication channels as the rest of the team.

The last word(s)

So, a case study & an interview. We’re hardly rattling the established pillars of HR & recruitment with this one, are we? But what it all boils down to is can we answer the following questions with a reasonable degree of certainty:

  1. Is the team proficient enough to produce technically sound work?
  2. Do they care enough about their client to provide them with results that make them more successful & do it in a way that makes the client feel empowered during the process?

I’d be happy to work with anyone who can do that.

Categories
Agile Digital Transformation Insights Lean Startup Organisational Change

I Googled ‘Agile’ — and wish I hadn’t.

I Googled ‘Agile’ and discovered my worst fears. Confusion and mis-information about Agile software development, how it works, and how to make it effective as a method of digital solution delivery.

Following on from the short, rather poorly animated video, let me share a slightly more concise and coherent insight on how Agile should work and how it’s possible to make it a means of delivering exceptional outcomes. Spoiler alert: it’s probably not what you expect or want to hear, but please know I’m here to support you if you feel in the slightest bit unsure about what to do next.

The methods used to build solutions with software haven’t changed significantly for 30 years. And even though we’ve lived in the The Age of Agile for almost 20 of those years, the time it takes to deliver solutions, not to mention quality and efficacy, are still falling short of expectations.

Beyond Agile, examined why software development failed to meet the lofty aspirations of the Agile Manifesto founders. The book also explained how to avoid some of the classic mistakes of Agile software development.

A talk given by one of the creators of the Manifesto for Agile Software Development, Dave Thomas, underlines the dysfunction caused when the principles of the manifesto are misinterpreted or distorted to fit an enterprise IT agenda. He half-jokingly attributes the downfall as our tendency to turn adjectives into nouns; so instead of the title Manifesto for Agile Software Development, people turn it around a truncate it to — Agile Manifesto, thus losing its meaning and purpose.

Beyond Agile explores many of the noteworthy lightweight methodologies in use today, some of which pre-date Agile. This provides context and explains why software development often fails to meet expectations. Another founder of the Manifesto for Agile, Alistair Cockburn, puts it simply:

“The Agile Manifesto was the product of seventeen people from different schools and backgrounds. No one person is responsible for the words we came up with — it is clear that it was the product of all seventeen people. The addition or removal of any one person would have changed the outcome, something we recognised and discussed at the end of that meeting.

Whether you think ‘Agile’ saved the world or poisoned it, be sure always to recognise that it grew from a rich compost (joke intentional) of backgrounds. The next time you read a would-be history of the Agile movement, look for all those names. If you don’t see them, it is not a history; it is one person’s recounting of their journey, years after the event (as indeed, this one is).”

Cockburn’s statement gets to the heart of why Agile is such an enigma: few people bother to understand or respect it for what it is, choosing instead to follow second-hand interpretations of the manifesto or, worse still, adopt a consultant’s cheap imitation of it.

Agile often fails, not because it is inherently flawed or lacking in some respect, but how people interpret and apply the principles. The Agile Manifesto and its core principles are, in fact, quite logical and straightforward. The problem with Agile is it was released into the world and then distorted by people unwilling and unable to think about the true meaning and purpose of the method. Kent Beck, the creator of Extreme Programming and another of the creators of the Agile Manifesto, calls this the ‘staring dog problem.’

“If you try to point something out to a dog, it will look at your finger,” he explains. “If you explain an idea in terms of concrete practices — like test-driven development, pair programming, continuous integration — people will fixate on the practices and stop thinking.”

Kent is calling out that often we’re unable to make the cognitive leap between practice and application. Scrum and other so-called enablers of Agile fail precisely because they compensate for lack of intellectual integrity. They shroud important ideas like user-centricity and fast iteration in rituals and catchy names. The Agile manifesto left too much room for interpretation and not enough specific rules. It feels like we’re back where we started in the late twentieth century with powerful technology and tools but no idea how to make them relevant to the ever changing needs of our enterprise users and customers.

Beyond Agile, describes three outcomes Agile practised well delivers:

  1. Eliminates (or at least reduce) waste in software development;
  2. Creates software that people use; and
  3. Delivers projects on time and budget.

An analysis of fifty thousand software projects conducted by The Standish Group in 2015 found 29% of projects was successful (meaning they were delivered on time, on budget, and to a satisfactory standard). The remainder, 71% were either failures or failed to meet expectations. Just think about that for a moment: starting a large-scale technology project, there’s only a 1 in 3 chance of success. Not very good odds. The same report in 2018 showed the situation got worse, with only 23% of projects successful and 77% unsuccessful.

Other sources corroborate these stats. In a paper presented to the 7th International Conference on Knowledge Management in Organisations, Stanley and Uden proved that software projects typically overrun their budgets by two hundred per cent, and exceed their scheduled completion dates by fifty per cent.

But it’s the cost of project failures that’s the real issue here. It’s nothing short of tragic:

– The cost of re-worked and abandoned systems costs the US economy an estimated $75 billion per year;

– In Australia, $5.4 billion is wasted each year on IT projects that don’t deliver value or are abandoned completely;

– One project alone — the infamously abandoned National Health Service patient record system in the United Kingdom — cost taxpayers £10 billion.

To put those numbers into perspective, the United Nations estimates that a yearly investment of $267 billion would end world hunger by 2030. A meagre $175 billion per year would eliminate extreme poverty globally.

It’s been almost two decades since the Agile Manifesto was written, and even longer since Winston Royce published Managing the Development of Large Software Systems. But little has changed and no single methodology has improved software development; it’s still a hugely expensive and wasteful endeavour that rarely meets expectations. And that’s hard to accept, in any era.

It shouldn’t be beyond humans to come up with a better, more reliable way of developing software solutions. Just as garment makers and car manufacturers in past centuries industrialised their domains, so too software coders need to do the same. Digitisation begets automation.

Methods like Beyond Agile address some of the shortfalls, but it’s by no means a silver bullet. The method requires skilled people, disciplined practices, full engagement with users and problem owners.

When I Googled ‘Agile’ I was hoping for the answer to some of the more taxing questions surrounding the method. What I came away with was this: to make Agile software development successful, there are four areas that align closely to the original manifesto principles:

  1. Start by defining the challenge or problem to be fixed
  2. Define the project outcome in terms of a quantifiable measure
  3. Describe the first 6–12 features or functions the solution must have
  4. Identify the first half a dozen users you’ll engage at the outset and throughout.

Rinse and repeat.

Digital Village is a community of IT professionals dedicated to providing flexible IT project team solutions in an authentic Agile way to enterprises in Australia and New Zealand.

Categories
Agile Customer Success Digital Transformation Insights Lean Startup System Engineering

What Dev Teams Are Missing.

UX designers, check. QA designers, check. Developers, check. The list goes on… but most highly-trained dev teams are missing a vital piece of the puzzle.

Software development is an inherently technical activity but without solving a real human need a project has no purpose. So why are those with the most immediate needs, the arbiters of purpose in this instance, missing from the team?

Standard processes for software development demonstrate the issue (sometimes jovially).

@johncutlefish

Customers and end users, the foremost experts on the business and its goals, are the critical missing piece from software development.

Aren’t they included already?

Well, yes… but not enough.

Towards Customer-Centric Software Development: A Multiple-Case Study found that, even in organisations with a high level of customer focus, that customers were only present at the beginning and end of the development process.

The authors found four key challenges with this approach:

  • Indirect access to end-users led to a lack of understanding of the reasons behind customer requirements.
  • Feature prioritisation is done based on employees’ opinions and is not continuously validated with customers.
  • Testing is seen as an opportunity to identify defects but not to validate mismatches between customer needs and product offerings.
  • A lack of systematic ways to collect, analyse and incorporate customer data into the product development process.

What’s the real problem?

By omitting the customer and end-users from the delivery team you are working on hypothesis (and to some extent guess work).

Even projects undertaken with extensive and painstaking research are based on what a potential solution could look like. This hypothesis isn’t tested until the end of the development phase when complete features are presented to the users and customers.

And now for the grand reveal… The software has been built to the customer’s specifications, or has it been built to the team’s interpretation of the customer’s initial specifications? Without fully understanding the customer’s situation there is a high chance of building the wrong software.

This of course has a huge impact on budget, schedule and, worst of all, the trust between the client and team.

So how does putting the customer and users into the project team help?

Shortening feedback cycles is a central principle of Agile delivery. By embedding key stakeholders within the team, feedback cycles are reduced from weeks to days.

Developers can demonstrate early prototypes and benefit from the unique expertise and feedback that only customers and end users possess. Rather than thinking, “what would the customer want?” at key decision points they can be asked directly.

No grand reveals, no surprises. A product is developed in collaboration with the customer and ultimately the people that will be using it.

Customers and users are busy people – do they have two jobs now?

Obviously we can’t expect the customer to be turning in 40 hours a week, that would be slightly impractical (and rather unnecessary). Attending weekly team meetings and being able to respond to questions from the team is enough.

The point is to ensure the developer feels comfortable making a call to the customer or uses to clarify a requirement or gain feedback on an early version. Essentially, you remove the subjectivity and guesswork to ensure the right product is being built.

Sounds nice – does it really work?

Digital Village recently completed the first iteration of the Race Around Australia project and was rolled out for a successful pilot in NSW schools. Program manager Emily McLachlan was deeply involved in reviewing the work in progress and making critical feature decisions and prioritising application features.

Her involvement allowed the delivery team to frame technical decisions within the needs of the department, schools, teachers and students, which reduced uncertainty around the product to practically zero.

You can read about the project’s success here.

Next Steps

Convincing busy professionals to attend another meeting/ create time for the demands of a project team sounds, well, trick. In fact, the hardest part may be convincing people who feel somewhat out of their depth in a technical project to participate in delivering it.

With the right support, however, non-technical stakeholders like clients and end users can provide invaluable contributions to a project delivery team.

The first step, of course, is a conversation with project stakeholders. Luckily that conversation will be about how they can save money, reduce risk and enjoy the benefits of their new software as soon as possible. We have a suggestion…

Working closely with the customers means the team will share the customer’s disappointments and triumphs, and hopefully shifts the team’s mindset from focussing on feature delivery to customer success.