Categories
development

When the old guard are not heroes

When I started programming, there were some key figures identified as the experts. They wrote the books that laid out how my code should look, how I should behave, and what the purpose of a software developer was. And there’s a new guard, also steeped in that mythos, publishing their hot takes and simple books.

I looked to my peers and seniors for guidance, and they looked to the agile manifesto, the gang of four and others. Those who packaged up existing ideas and best practices, set against a growing trend of Taylorism, and wrapped themselves in a punk ethos fighting the power, wielding keyboards like axes.

And there was value in what they were selling, small pieces that fed my hunger for “something better”.

But for all the bravado, the facade of Woody Guthrie and Bruce Springsteen they presented, deep down they were the establishment, tweaking the system slightly for their own benefit, re-engaging the bro culture of the “frontier spirit” of the early internet. Rules and processes are dictated by “the man” to restrict our freedom to innovate, and to work in the best way.

Companies formed and rose on the counter-culture ethic, buoyed by the vacuum left as union power fell, blinding us all that tech was the new utopia, and it brought a meritocracy that would bring equality.

And the gods saw agile, and it was good.

We moved fast and broke stuff, re-wrote the rules. The industry didn’t take time to consider why those rules existed, just that they were roadblocks.

So when women and people of colour, and anyone else who wasn’t a bro, stepped into the arena, they were vulnerable. Because there were still rules, just no process. And the rules aren’t made for them. And the gatekeepers, clear in their self-image that they weren’t racist, or sexist, and only discriminated on merit, could not comprehend that processes and written rules exist to limit privilege, because equality means nothing without equity.

They asked all of us, the squirrels, the rhinos, the fish, and the peacocks, to climb trees and collect nuts to demonstrate our worthiness to join their club, without regard for our skills or our backgrounds. They bully, they fight, they protect their own, because rules weigh us down, man.


  • People over process, so long as the people are the right people.
  • Working software, so long as it works for me. Anything else is externalities and not my problem.
  • Collaboration over contracts, we’re all on the same team, so forgive me as I forgive you.
  • Respond to change over following a plan, but is there a vision that informs what changes are acceptable?

Agile still has its place, but what would it look like if the manifesto and the guiding principles had been laid out by a more representative group? The antecedents, stretching right back through NASA, Bletchly Park and The Difference Engine, remain the same, and the key lessons are independent of those teachers, but what did we miss by not having others at the table?

  • What does process that protects people look like? Process that keeps people safe and secure to deliver the best solution?
  • What does software that works for everyone look like? Beyond documentation on accessibility and anti-discrimination.
  • What does proper, honest, compassionate collaboration look like? Within teams, between teams and across disciplines?
  • What does meaningful, people-centered change look like?

Software is too important to be left to the swamp that is this libertarian mess. The current ways are driving great developers out of tech, and users are not fairly represented. Some of the old guard recognise this, but many don’t, and they have plenty of followers who still believe the meritocracy myth.

There is no level playing field in tech.

Not everyone has spare time for technical exams outside work hours. Not everyone is comfortable pair programming. Not everyone can follow a spoken stand-up. Not everyone feels safe to bring their full self to work. Everyone is not treated the same. Not everyone can have alcohol and pizza. Not everyone has the experience of standing up to authority figures. Not everyone can be themselves without being judged or mocked by the cis straight white male gatekeepers, and their supporters.

There’s precious few unions and the biggest tech companies are all struggling with human rights, fair employment and treating their users fairly. And it’s not just them.

Unlike the 20th century, it’s not a battle between management and worker. Agile has cast management and worker in the same side, but some workers are far more equal than others.

People are not supported by the process. Software doesn’t work for everyone. Collaboration is limited because contracts don’t protect and promote safety. The plan for meritocracy to end discrimination isn’t working. How are you going to change it?

Categories
development leadership

Becoming a technical lead: Trust your team

When I first became a technical lead, one of my biggest challenges was giving up control. It wasn’t a matter of not trusting my team technically but I didn’t want to overload them, so I took on all the planning, all the customer interaction, and all the other jobs that I felt had distracted me from the job of writing code.

I was wrong.

I needed to let my team in, because they had ideas that I didn’t, they had capacity whereas I was a bottleneck. I was holding up my team.

But I needed to be sure that coding standards were followed and quality was maintained. You know who else cares about that? My team. I made it their responsibility to ensure that the code met standards, and pushed out code reviews. I put internal documents at the same level as code. Anyone can edit, but everyone can review, or veto.

I asked for honest feedback in retrospectives, and implemented changes, so they could trust that I was looking out for them, and I set them goals to improve, alongside the feature work : “can we release twice a week?” (challenge – automate the pain points); “can we halve the bugs found in testing” (challenge – better unit tests)

And the more I trusted them, with support, and understanding their limits, the better they performed. I’ve also worked with managers who don’t trust their teams. Those teams don’t work so well.

If you don’t trust your team, they’re not your team. They’re just people who work beside you. What are you doing today to foster trust?

Categories
code leadership

CodeCraft – Architecting Teams Notes and follow-up

Thanks to everyone who came to the CodeCraft guided conversation last week. I’ve added some notes to the questions below to carry on the discussion, and there’s a few topics I want to revisit in this blog, and in DDD Scotland if my talk is accepted.

The code craft team did a great job of reviewing and improving the questions so thanks to them, but I think in the very busy session itself, some of the questions were too ambiguous. For example, when I was thinking about goals, I was thinking about project goals and strategy goals rather than just “Make more money”, but I suspect that’s as much to do with the ambiguity many people have about their company strategy and culture in general.

It was also interesting to me to hear how agile is interpreted. The agile manifesto is clear that people take priority over procedures, and software over documentation, but explicitly the authors “still value the things on the right”. So it’s not about no procedures, and no documentation (please tell me you have coding standards), it’s about the right ones to support the people, the delivery of working software, etc. rather than documentation in its own right. Indeed, there are a number of explicit rules that an agile team needs in order to function. Is there a framework? What is the lifecycle of a unit of work? What language are we using? Not all of it needs to be documented, but some of it absolutely does, especially if you want to understand and improve it, and remove the rules you no longer need.

Be wary of anything that interrupts transparency, whether it’s Chinese walls, secret tasks, hidden agendas or ninja developers who work in the shadows and surprise everyone when they’re least expecting it.

And it’s never just enough to say who you are and what you do. Promote, encourage, and challenge. Be proud to be a diverse employer, to be wheelchair accessible, to have staff with more than 2 years real world experience, and welcoming to fresh faces with new ideas.

Trust. Respect. Communicate.


As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

  1. How do you keep track of your team and the company goals?
  2. How does your team manage risk to and changes to those goals?
    • Pre-mortem
    • Chaos monkey
    • Agile “threw away risk register and other important documents”
  3. What makes a great team?
    • People
    • Feel comfortable
    • Trust
    • Communication
    • Balance
    • Good Leader
    • Sustainable development
    • Transparency
    • Healthy Debate
    • Growth and change
    • Common Goals
    • Motivation tailored to each person
    • Rules
      • Raise concerns
      • Feedback should be timely and structured
      • Coding standards
      • Process rules (e.g. how do we report a story can’t be implemented, what’s the weekly schedule)
  4. What would you change about your current team?
    • Management
      • Decisions made outside the team, not taking input from the team
      • Coaching developers to talk to management
      • Wrong person promoted to lead
    • Too many rules
      • “Because we’ve always done that”
      • Needs the context of why that rule exists
    • Clear roles
    • Respect for decisions the team has made
    • No secret tasks
    • Co-located, or remote, not mixed.
    • No “them and us”
      • Manager vs developer
      • Techie vs non-techie
  5. What makes you feel unsafe in a team?
    • Lack of:
      • Support
      • Communication
      • Respect
      • Goals
    • Secret genius / hero developer who does their own thing
    • Decisions made without buy-in
    • Teams without source control
    • No tests
    • Secrets
    • Success at the expense of others
    • Developers are not “resources”
      • And managers are not “overhead”
    • Fear
    • Stagnation
  6. How well would your current team survive a conflict?
    • To survive, have Strong Opinions, Weakly Held
    • Have a “naughty step” project for someone who doesn’t follow the rules, or doesn’t respect the team
    • Avoid imbalance in workloads that lead to loading stress onto key individuals
  7. Should teams change when projects change?
    • Teams should be mixed to avoid stagnation, but not completely break them up
    • Good teams can inspire others
    • Every good team cares about the product they produce
  8. How does the culture of a team change as it grows?
    • Negatively. Easily leads to “Us vs Them” (e.g. backend vs frontend vs DBAs, developers vs testers)
    • Lines of communication fail, especially as distance increases.
    • Old vs new – “I prefered the company when it was smaller”
    • T-shaped individuals are better collaborators
    • Tribe structures can help by allowing multiple communication lines
  9. What kinds of diversity should we seek in the teams we work in?
    • Diverse teams build diverse products
  10. Should we recruit to enforce the current culture or diversify it?
    • Put accessibility positively on ad when true (wheelchair accessible, BSL-friendly)
    • Do you know the current culture?
    • What is “culture fit”?
    • Does anyone know your company values? (not just the 5 Apprentice team names on the posters around the office)
    • Get job adverts reviewed by as diverse a team as possible
    • Diversify where the jobs are advertised
    • Not every candidate has 20 hours for a coding exercise, or wants to give up 2 holidays to pair with you
    • Coding review should be blind
  11. What one thing can a leader do to make a team great?
    • Trust
    • Delegate authority and empower the team
    • Protect the team
    • “Reading the room” understand what’s not being said so you can investigate
    • Push everyone to improve (including yourself)
    • Empathy
    • Happy people
    • Communicate
  12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

Categories
code leadership

CodeCraft – Architecting Teams

Thanks to everyone who came to the CodeCraft guided conversation yesterday. If you want to reconsider any of the questions yourself, you’ll find them below.


As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

  1. How do you keep track of your team and the company goals?
  2. How does your team manage risk to and changes to those goals?
  3. What makes a great team?
  4. What would you change about your current team?
  5. What makes you feel unsafe in a team?
  6. How well would your current team survive a conflict?
  7. Should teams change when projects change?
  8. How does the culture of a team change as it grows?
  9. What kinds of diversity should we seek in the teams we work in?
  10. Should we recruit to enforce the current culture or diversify it?
  11. What one thing can a leader do to make a team great?
  12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

Categories
leadership Uncategorized

As a team lead …

As a team lead you need to know your team. You need to understand people. You don’t need to second guess them, you don’t need to micromanage them, but know what motivates them. Know what they need to perform at their best.

What tools do they covet? What routines matter? Do they need precision? Do they value gym time? Do they aspire to learn?

Understand their 6 month and their 5 year plan and help them achieve it. Make sure they know the team 6 month and 5 year plan and where they fit into it, and where that fits in the company plan.

Value them, and ensure they feel valued. Listen. Give them the grace to accept that which they cannot change but be sure they know you’d change it if you could.

Change what you can. Make their lives easier. Help them aspire to your job, even if they may fear the conflicts you protect them from. Keep your head whilst those about you are losing theirs.

Be the best team you can be. Discover the greatness in everyone. Play to strengths to see them through weaknesses. Move people. Change their roles. Find your gardeners and your innovators and Train them to replace you, because for certain times they will need to. Do not become vain or bitter for always there will be greater or lesser persons than yourself.

Let go. Trust them. Trust yourself. Let them do their job so you can do yours.

But lead, don’t follow. Have strong opinions, weakly held when a better way presents itself.

Let data guide you but not be your master. Don’t trust your gut.

Don’t be a stranger and make a full commitment to your team.

And make sure everyone knows the standards.

Categories
development ux

User Experience : A quick introduction for developers

The following is an internal summary I wrote for a team that no longer exists, summarising a number of references from UXScotland, various book and blog posts. It extends the thoughts from my Pecha Kucha talk. For more details, please refer to the links throughout and the references at the bottom. The context here is consulting and long-term B2B projects, but some of these discussions are more widely relevant.

User Experience : Project considerations

User experience is about making sure we are solving the right problems in the right way. It is the intersection of design, users, and context. Context here is a combination of one or more of the device in use, the user’s location, any social cues such as nearby friends, and anything else that may be available from sensors or historical information.

vennux

In many cases, the requirements we have are assumptions (e.g. what users want is Facebook integration). Where the benefits of a requirement are unclear, we should treat it as an assumption to be tested. Embrace data, and analyse it.

At the requirements stage, we need to make sure we are solving the right problem (pretotyping : “building the right *it*”), and that our chosen design helps the user to solve the problem without frustration (i.e. prototyping the design, rather than the implementation, with wireframes/sketches).

In user testing, particularly in an agile development, we can refine those ideas by seeing how well the implementation solves the problem, by testing with users. We can also test deployed code by analysing heat maps and http logs to see what users are doing to inform further tests and the assumptions that feed into further design cycles.

In a Lean/Agile project, we need to be explicit about our assumptions about the user and test them at every stage of the development to ensure that we always meet user needs.

cycleofux

How does UX fit in our process?

Stakeholders

A system that supports user’s need effectively will need to understand that the user is a Stakeholder in the process. Whilst the users themselves may not be directly involved in the generation or review of design artefacts, there should be a user representative, either a super-user on the customer side, or a 3rd party researcher who has determined user needs, and has authority to verify any proposed solution and high-level requirements against those needs.

Functional Requirements

Personas / Typical Users

A persona is an abstraction of a system user. In a simple system, there may be only one type of user, but more sophisticated systems will typically have users and administrators, and may have multiple classes of each. A persona is defined to encapsulate the types of tasks a specific user may wish to perform, and any limitations that may be imposed (for example, administrators may be able to install specific browsers or client software, but members of the public using the system must be supported across multiple browsers at multiple screen sizes).

User Journeys

Each persona will have one or more tasks they wish to perform in the system. A User Journey describes the tasks as a series of steps that a specific persona will follow in order to achieve that task.

Consider the tasks that a user wants to perform. See also BDD – design from user in.

E.g.

User wants to process a case:

  • User logs in to the system
  • User selects case from their task list
  • User reviews latest document
  • User finds agent for case, and calls to discuss
  • User adds comments to case
  • User saves case and returns to their task list

This process may identify a new use case (“Display task list”), and specific actions that need to be defined within a use case (“Display latest document” and “Display agent contact details”)

The User Journeys provide the context between the Stakeholders (and User Types therein) and the Use Cases. Each User Journey will link to one or more Use Cases, but some Use Cases may not have an associated User Journey (nightly payment processing, for example).

User feedback

If the solution is replacing or improving an existing system, the best source of information on the current system are the users. The requirements capture process should take into account both the tasks that the users perform and gather feedback on any areas of frustration. The prioritization exercise should consider these improvements as well as new functionality.

Testing

As well as testing the Use Cases for functional acceptance, the FAT/UAT process should also test that the final system supports the User Journeys defined up front.

On-going support

Where projects have regular support meetings, the input of users has been valuable in identifying problems areas and possible changes. When on-going service delivery contracts are defined, SDMs should consider whether ongoing user feedback is appropriate as part of the planning and scoping of releases within that framework.

Questions to ask

  • Have the requirements been tested on users? If not, why not? (Are these the right requirements?)
  • Will users be given the opportunity to provide feedback on these through the development? (And if so, how, when and where?)
  • What user outcomes are we trying to achieve with the release? These may not be requirements that we put a cost on, but an expectation that we can measure against to show improvement – we would need to communicate this appropriately.
    • E.g. minimise clicks to access the 5 main functions
    • E.g. reduce time-to-complete for function x, y and z by 10%
    • E.g. Align existing UI with iOS and Android norms
    • E.g. Increase usage of function z by 5%
    • E.g. 99% AAA compliance
  • Who represents users on the project team?
    • How many user types do we need?
    • Can normal users and administrators share UX, or are their goals divergent? – different apps, different ASP Areas, different branding, …
  • What platforms and form factors need to be supported/tested?
    • Does each platform need a native UX? If native app, probably yes, if web app, maybe.
    • If mobile, do we need to adapt to context : location/orientation/communication with nearby devices/…
    • If social, do we need to adapt to context : can I approve my own work?/who’s online/recommendations/who’s nearby/…
  • Do we, as developers, have any input to the UI design? If not, why not?
  • Have the designs been tested on users? If not, why not? (Does the UI fit user expectations?)
  • Do we have appropriate guidelines for the appropriate platform, and are they listed in the requirements and estimates?

Potentially useful resources

 

Categories
development programming

Working exactly to spec

Is there a problem?

  • The work was completed to spec.
  • Any additional work was likely to break the time and cost estimates.
  • The work meets the current standards. To bring the remaining paintwork up to standard would require removing and re-implementing the solution, further risking budgets and blocking higher priority work.
  • The only available colours do not provide the legacy appearance required to match the existing lines.
  • The blue lines were not part of the original specification and therefore no knowledge is available on their purpose and whether they should be extended or removed.
  • The disjointed yellow line on the right-hand side would require straightening, which would cause confusion to existing users. There are multiple consistent configurations and the workers have no means to evaluate which of these minimises confusion.
  • The user who raised the bug report is unaware of the timetable detailing the repainting plan and the agreed extent of the lines.
  • The user who raised the bug report is unaware of future proposed fixes that will require additional upheaval. Any attempt to fix other line issues now will result in unnecessary rework.
  • The existing pattern does not cover the required scope (see the far side), and any additional work would lead to scope creep to correct this error.
Categories
development

The Father Dougal trap

Every day we work with a codebase we get smarter, we learn more, we have more context, we refactor, we compromise and we understand.

Every day we work with a codebase, our estimates improve.

But some days we get asked to estimate “everything on the backlog”, with a large dose of yesterdays weather, and a divination ceremony that uses numbers and maybe spreadsheets to make it look like engineering.

And the tasks we tackle the following day or the next sprint, or the sprint thereafter are mostly going to match the estimates, except for the knotty ones that don’t. And the ones further away will match less because by then we’ll know more. And we know we’ll no more, and we chose, or are advised, not to do them yet.

Those are the indistinct shapes in the fog. The ones that look bigger than what you’re doing now but definitely a lot smaller than those big problems we’ve tackled in the past.

Or are you fooling yourself? Do they only look small because they’re far away?

When you get close, will you find that even your best tools aren’t up to tackling this monster, and you’ll need to invent some new ones? And that will take time, and rework.

How far ahead are you estimating, how soon will you get there, and how confident are you that size isn’t an illusion?

Categories
development leadership

You have permission to change

Agile is a method of managing change by embracing it. It’s not a process, but there are lots of processes that help people deal with their particular change or their particular pain.

We talk about agile a lot as a method of developing code, and how the code needs to be flexible, reviewed, refactored, tested and changed to meet new requirements.

We talk a lot less about the processes around them. Yes, Continuous Integration and deployment are recommended, as are short sprints, and retrospectives should be about making all those better. But there’s too often a disconnect between the people and the processes they create. The processes may get reviewed, but often go without refactoring, testing or changing, so they slowly decay into legacy processes, and procedural debt, that are no longer fit for purpose.

So people work around them and suddenly there’s manual steps in production because a requirement to deal with secure data properly in production didn’t lead to the right refactoring of the CI/CD process.

So what’s your cycle for refactoring, testing, changing and reviewing your processes? Do they live in your code, and subject to the same cycle? Are they accessible and editable by all? Who needs to review them before they change? How do you know they’re failing the test?

Categories
development

Sugar coated icebergs

Prototypes are great. They let the user see and feel what the final product will look like, either in printed or in online form.

They suck when the customer wants it next week because “it’s just a bit of wiring up to get it working”

And they can be dangerous. Ship that button without properly tested, or incomplete, code behind it and your software could crash and sink without trace.

If you want to always be finished, you need everything that the user can interact with to meet your quality standards. No unguarded exceptions, no raw data, no untested code. And if that means leaving that button out until it’s ready, do it. Or put in a bulletproof, well tested placeholder, like an email subscription to find your beta testers.

The user doesn’t know or care about all the mass under the surface that they can’t see, so don’t expose them to it. Keep the interface clean, simple and error free. Build up behind the scenes, behind feature toggles, and off production until you’re sure it’s safe.

The one thing worse than a missing feature is a horribly broken one. A user missing a feature may come back when the feature is ready. A user who’s experienced a broken feature won’t come back until they trust it.

Don’t lose your users’ trust.