Sound of Silence

The Effects of Work Environment on Developer Productivity

Space may be the final frontier. It may be wide and open. Or even closed and confined. In the software development world we often focus on tooling and its effect on programmer productivity. This crazy distributed world is encouraging us to think less about the importance of physical workspaces.

Our work environment historically hasn’t been given much focus. Only when Peopleware by Tom DeMarco and Timothy Lister was published in 1987 were the social aspects of software engineering popularised. Today the notion of Agile workspaces is being advocated for fostering collaboration and productivity. The question we should ask ourselves is what environmental factors support agility?

What attributes of our working environment make us more or less productive?

I read Peopleware in university when examining personality composition of productive teams. Yet, the lessons regarding workspace and its effects are another vital consideration. Changes to my own desk positioning have caused me to re-investigate the insights proposed by Tom DeMarco and Timothy Lister. This week I’ll outline my musings on the office surroundings, and how it affects our productivity.

White Noise

Noise travels. Having a multitude of colleagues speaking on the phone leads to an incessant buzzing travelling around the floor. Individual conversations on the floor contribute to the swarm of bees buzzing around your head as you work. Software engineers perform very thoughtfully intensive work. Concentrating on writing code, reading code, or completing any intellectually gruelling tasks requires peace and quiet.

> Your folks are intellect workers- they need to have their brains in gear to > do their work, and noise does affect their ability to concentrate. > > Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams

Separation of collaborative and individual spaces is crucial. Don’t cram floors with developers like battery hens in cages. They need some personal space to focus on computationally intensive tasks. Yet they also need booths and collaborative spaces to encourage working together.

Programmers shouldn’t need to utilise headphones to help them complete thought intensive tasks

I’ve never been one for continually sitting in silence. Nevertheless, through disregarding the babble we are enforcing every developer to require a set of noise cancelling headphones to be productive. Introduction of noise reduction mechanisms on the floor itself is one of the latest advancements that should be adopted. It would certainly have been useful of late, where I could hear colleagues from my dark corner on the opposite side of the floor.

Let’s Get Together

Whether you work to live, or live to work, we spend the majority of our week in the office. The office needs to feel homely yet not encourage leaving at an unreasonable hour. Being human, software engineers will still want a fixed location to flock to every day. My experiences with hot desking early in my career emphasised that human beings are creatures of habit. The majority sat in the same desk everyday. Their lockers were only filled with their non-essential hoardings when visitors needed a desk. Flex desking possesses primarily fiscal benefits as you have less empty desks in the case of sickness and holidays. However it does depersonalise individual work settings.

Sitting teams away from each other is not as good for the pedometer as you may think

Proximity to your team can have a strong impact, regardless of organisational strategy. Strong teams have diverse personality sets that will gel together, but that is not the only factor affecting their productivity. Offices shouldn’t be treated as a peak-time tube train, cramming new arrivals into every free centimetre of space. It is a misnomer that colleagues will walk to your desk irrespective of where you sit. Even if they are counting the steps on whichever pedometer app or device they use. Instant messenger applications become the default communication mechanism, which can leave segregated developers feeling isolated.

Teams should be placed in collaborative facing groups rather than endless rows of desks. Areas should also by extensible to allow teams to grow. Like blocks of memory, slotting new arrivals into the first available slot rather than encouraging concurrent access is not a great impression to set for new engineers.

Where I Draw the Line

With an emphasis on co-located teams within many Agile methodologies, collaborative spaces are required to foster fraternisation. To encourage innovative solutions means your work environment must include tools to help encourage ad-hoc creative thinking. Tools must be openly available without the need to lock coders in conference rooms.

> You may be able to kick people to make them active, but not to make them > creative, inventive, and thoughtful. > > Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams

Many Agile spaces boast every wall being a whiteboard, as well as smaller versions at developers desks. Having boards only in meeting rooms can introduce challenges, especially when you have a shortage of quieter spaces for deep thought. Even windows can allow sketching of new ideas with the right pens. The added bonus of getting creative with your collaborative space is programmers can bask in natural sunlight for the few months per year that we have it.

Windows and whiteboards can be used for collaboration and design, not just menus!

The little things are important to developers. Engineers crave more monitors, better mice and keyboards. Even the specification of the coffee machine can prove to be a source of contention, as I’ve found of late.

With the exception of the pricey coffee machine, the start up paradigm of giving coders choice over their tools is something us larger organisations should consider. Having them build their own PC or laptop spec will not be scalable. There is no reason that personal budgets for mice, keyboards and monitors couldn’t be adopted to give programmers the tools they need to operative productively. Such mechanisms must be applied consistently to prevent the spread of animosity.

Common People

There are far more productivity enhancements I can recommend based on my time in the relegation zone. It is important to regularly evaluate our work environments and experiment to determine which options will work for the engineering collective. Measurement of individual productivity would be the best mechanism to determine if developer productivity is being impacted by their surroundings. Once the fix is identified, it should be adopted across the entire group to prevent feelings of resentment developing.

> When the office environment is frustrating enough, people look for a place to > hide out. They book the conference rooms or head for the library or wander > off for coffee and just don’t come back. No, they are not meeting for secret > romance or plotting political coups; they are hiding out to work. > > Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams

Peopleware outlines several strategies employed by people unhappy with their environment. Looking out for these signs can help identify workspace issues. One of the notable approaches that is easy to spot is employees diving into offices or conference rooms to get work done. This is a more drastic mechanism than the more common headphones on strategy. Another possible strategy is working remotely more regularly. This can also be an indication of developer frustration. Managers should be on the lookout for these warning signs.

Measure developer working habits both in and away from the office to determine space effectiveness

Dissatisfaction can stem not only from the work itself, but also developer surroundings. Regardless of profession, people want to go home every day feeling effective and accomplished. Be mindful of the small environmental factors appreciated by programmers. Even the cackle of colleagues echoes across a packed engineering floor.

Thanks for reading! Do also check out my follow on piece on workspace impact on non-occupying stakeholders.

This Masquerade

Can Software Craftsmanship be Nurtured?

Craftsmanship is not limited to carpenters. Even suggesting it is limited to the building of a physical construct is an ignorant statement. My inner perfectionist always attempts to guide me down the path of doing the right thing in everything I do. Naive as it sounds, this also applies to the software that I build. Craftsmanship is defined as the quality of design and work shown in something made by hand. Users do form subjective opinions on the quality of the software they use.

Building of quality software requires a degree of mastery from our engineers, with experience of using the right tools

Software is not tangible, so measurement of our level of professionalism is challenging. Nevertheless, that doesn’t mean we can just hack it together. Wiser people than me have highlighted the importance of building software the right way. This week in particular, thoughts around the Agile community and their relationship with craftsmanship have triggered considerable debate. Here I ponder how to identify software artisans, and whether mastery of these principles can be nurtured.

Let Me Be The One

There are indeed individuals already out there that take immense pride in building high quality software. All technology firms want to hire the best talent. Those who continually strive to increase their software development acumen are the talent organisations wish to attract. Is it safe to assume that our hiring process will distinguish between cowboy coders and professional programmers?

Identifying a passionate technologist doesn’t guarantee that they will build software the right way. People may say the right things in an interview, but it’s important to extract if potential engineers practice what they preach. Beware the situation of an interview turning into a game of buzzword bingo. Asking probing questions is the sole method of validating whether they have experience in applying these techniques.

Ensure that any prospective candidates understand the techniques they discuss and are not playing buzzword bingo

To measure the mastery of any potential engineer, live coding exercises in interviews should be mandatory. Our recent hiring has focused on coding exercises both before and during on-site interviews. Nevertheless, this may not be enough. You can discuss design and implementation considerations, but in a few hour interview candidates are less likely to showcase practices such as TDD. Only once they are producing code as part of your team can you truly assess their degree of professionalism.

It’s Going to Take Some Time

Once these sprightly software engineers have been integrated into the team, managers are able to critique their level of craftsmanship. The true test is when they are put under pressure to deliver. Agile methodologies such as Scrum and Kanban provide techniques to ensure a constant work rate. Limiting by time or concurrent tasks is intended to protect programmers. Regardless, I still see managers pile on the pressure to deliver user value. It suggests we are treating programmers as mindless zombies, responding to every order by frantically rapping on the keyboard.

When the going gets tough, software virtuosos will be mindful that they are accruing technical debt

I’m afraid to admit I’m also guilty of this phenomenon. To meet the deadlines imposed by managers, developers are delivering features far too fast. With such velocity, quality is compromised. I’m not just talking about conceding on test coverage. That is merely one attribute that limits the ability of our software to stand the test of time.

Insufficient discovery time will result in building of features that may not scale to the intended use case. Bad smells will also creep into the code. Any artisan engineer will tell you compromising on craftsmanship in this way is not worth the accumulation of technical debt. Like any mortgage, you will have to pay down your debt eventually. Rather than being threatened with foreclosure, the system will become difficult to maintain. Working on indebted code bases fosters developer frustration that may ultimately result in your better engineers leaving.

We’ve Only Just Begun

Not all engineers will be skilled software virtuosos from day one. I certainly wasn’t when I first walked in the door as a bright eyed graduate seven years ago. I’m still working on building my own skills. Talent should be hired not only for the skills they have, but their potential to improve and become pragmatic programmers.

Craftsmanship is fostered through culture. An established team can still be encouraged to improve their craft if nurtured. Reading is vital in our quest to improve as software engineers. Although practice makes perfect, only writing code will never make you the best developer you can be. Honing your craft requires seeking additional sources of wisdom, and contemplating the ideas projected. Books, blogs, tweets, tributes. All will provide insight. Teams should become comfortable sharing resources. It is not just a managers responsibility to assign out reading material. We’re not in school anymore kids!

With a multitude of resources out there, including but not limited to books, teams can share and grow their expertise together rather than alone

Writing code regularly is essential. Continually assigning the same tasks to the same developers time and again will encourage skill stagnation. Personal tinker time is also a great mechanism for supporting the technical development of engineers. Michael Lopp advocates keeping a Tinker List of the technologies you wish to investigate in Managing Humans. Managers and programmers alike need to experiment with new technologies. They must also scrutinise the inner workings of frameworks which they currently use. Dedicate regular time to trying out technologies and techniques. Only then can we continue to master our craft.

Thanks for reading!

Shuffle The Deck

Shaking Up Our Stand Ups

Change is inevitable. That would be my executive summary of the past three months. Rather than continually follow a plan, we need to be receptive to change and adapt accordingly. With life being uncertain it’s only logical that we need to be comfortable taking chances. Being comfortable with continuously improving the format of our Agile ceremonies to is imperative for team empowerment.

Mors certa, vita incerta

Philip K. Dick, Do Androids Dream of Electric Sheep?

So far this year I’ve lead two different projects with different goals. Yet both required a reboot of their stand-ups to improve collaboration. This week I discuss the emerging trends of stale stand-ups, and reflect on how our attempts to reinvigorate daily updates have affected team collaboration.

Glasshouse Tarot

The majority of this audience should be familiar with that age old stand-up pattern. It is the mark of Agile evangelism that is permanently branded onto our minds. For those less knowledgeable each participant outlines three key points:

What tasks they completed yesterday.
Their proposed agenda for today.
Any blockers that will prevent them fulfilling today’s goals.

The traditional stand-up format encourages discussion of past, present and future exploits by each person

Think of that scene in Live and Let Die where Solitaire predicts Mr Big’s fate using the Witches Tarot Deck. Yes, I know which deck it is as I own the same set. Colleagues on a stand-up call out the past and present activities along with future challenges in much the same way. Regardless of your beliefs in fortune telling, it is worth reflecting on how effective the readings are in any format.

Lazy Poker Blues

Part of our problem was the format had become far too predicable. The regular round robin routine meant developers switched off during stand-ups and simply waited for their turn. Their updates were succinct, yes, but key details such as blockers were often missed. Issues were often voiced after the call when the relevant SME was contacted for assistance. As a lead, tracking progress with these unknown blocker variables became impossible.

With our team being distributed, over-reliance on phone also inhibited updates. Team relationships are exceptionally challenging to nurture across regions. You don’t truly connect with someone until you look then square in the eyes. Spotting their tells of frustration or concern solely based on tone is difficult.

We may have become a society glued to our devices, but a stand-up is not the time to be checking social media

Indirectly, programmers focus on our stand-ups was far from stellar. While waiting after giving their update, I could see local engineers browsing on their phones. If their focus was on work, they would be burried in their email inboxes. This lack of attention is clearly disrespectful to your colleagues. From a team work perspective it was also leading to a communication disconnect. Gathering in rooms certainly did help improve things for a short time. Focus continued to waver.

Gambling Man

The stand-up routine is considered sacrosanct by many. In these circles it’s destined never to change. I’m more experimental myself. My regular reading one morning a few months ago revealed a Eureka! moment with a story oriented stand-up approach. If stories are the key features of focus for delivery, why are individuals the centre of attention?

After discussion in our retrospective, we collectively agreed to give this new format a whirl for one sprint. The approach was to apply our favourite three elements to the stories instead.

Focusing on stories over individuals should foster collaboration and make stand-ups more collective focused

Like any change it took time for individuals to adjust. There is a danger that you inadvertently lengthen your stand-ups if discipline is not enforced. This did happen initially. With effort, we managed to shift back to our average 10 minutes stand-up duration.

Developers reported several key benefits. Status of work, including blockers, became more transparent. Assistance was offered for blockers quickly, resulting in story subtasks moving across the board more rapidly. Nevertheless, the biggest result was the engagement between colleagues. Programmers were no longer distracted by other tasks. As my job is to keep my engineers happy and engaged, this was a massive result for me.

Play Your Cards Right

Further validation of this method came a few months later. Following an organisational restructure, this rock star team was split in two. The teams we were absorbed into were following the good ol’ standup routine.

After a couple of weeks, engineers who were part of the original experiment began raising concerns. They were seeing the same issues in their new daily stand-ups. They were recommending that the same approach be adopted in both projects. Since their proposals, other teams have embraced the new format. Feedback from these teams are finding the story first approach better facilitates collaboration. In my eyes this is a fantastic validation of the initial experiment.

Teams should use their best judgement to continuously improve all aspects of their process. stand-ups are sacred, but not off limits!

In this game of chance, the developers have won over the house. The Agile space is filled with numerous different techniques that teams can use to solve problems, regardless of which methodology you use. Some consider it obscene to tinker with the key ceremonies. Shake off any reluctance and be comfortable taking a gamble.

Thanks for reading!

Test of Time

Compromising Test Coverage Under Pressure

With life, the universe and everything, everyone has their own standards. Perceptions of quality are different between individuals. Agreeing a common definition of done across the team is an important initial step in any Agile journey.

When the going gets tough, ensuring each feature is built to these principles can be challenging. Even the most well-intentioned developer can fall foul of shortcuts. When managers pile on the pressure, programmers attempt to meet expectations by compromising on best practices.

How do we make sure our teams take the correct route under pressure, rather than a shortcut?

Unfortunately for us, this has included test coverage. This key criteria of our definition of done has been under threat. Recent adoption of minimum coverage gates prompted several discussions around temporary adjustment of these metrics as engineers felt functionality was blocked. Here I reflect on the contributing factors that force our programmers to deviate from the right path, and how to lead them down the correct route.

Begin the End

If we are compromising on test coverage when under pressure, it is safe to assume we are not writing our tests first. We advertise ourselves as practising Test Driven Development, or TDD for those in the know. When it comes to the code review stage, there are occasions where feature and project coverage doesn’t meet the minimum percentage agreed in the team definition of done.

For the past 3 years we have been aggressive with our adoption of Behaviour Driven Development, a subset of TDD. We are exceptionally fortunate that we have client representatives writing behavioural scenarios for all new features. A story is not ready for development if we haven’t received a set of scenarios. Despite being available from the outset, encouraging developers to write tests first is still proving troublesome.

Engineers can struggle to write tests first when adapting to the TDD circle of life

Ideally we would want them to follow the TDD approach of writing a failing test first and implementing the least possible amount of code required to make the test past. Writing effective tests was not given much focus in my Computer Science degree course. Speaking to students and recent graduates, it still appears to be the case that they have little experience writing unit tests as part of their studies. Furthermore, they generally have no opportunity to write integration tests. It is an arduous process to change the mindset of writing tests last. I’ll admit I still labour over following the TDD cycle.

Nevertheless, the benefits are numerous. Many are documented across the Web, however one often overlooked advantage is the scenario’s dual purpose as feature documentation. Lengthy user manuals akin to War and Peace are no longer viable for clients who want to start using our software immediately.

Out of Time

Another aspect programmers and technical leads alike find excruciatingly difficult is providing accurate estimates. Humans struggle to determine how long things will take. Regardless of whether they include the writing of integration and unit tests in these timelines. Against their better judgement, developers will provide estimates that are not concrete. Call it the programmer curse of perpetual optimism. Development will most likely take longer than anticipated as they are tormented by library conflicts, logic errors and other blockers. Not adding testing effort will only add fuel to the fire.

A common misconception is that an estimate is an exact measure of time from which we can project a delivery date. The noun estimate is defined as an approximate calculation or judgement of the value, number, quantity, or extent of something. Approximate is the key word in this definition. Despite our best intentions to include our testing effort, we often overshoot.

Estimating effort is exceptionally difficult, but cutting corners to meet deadlines results in users finding more defects

Sounding the trumpets at the grand unveiling of the latest and greatest tool may appear to be the right thing to do in this instance. Writing unit and integration tests does not prove the absence of bugs. Manual user testing will not verify that functionality is defect free either. Arguably they may find increasingly more defects in their testing cycles if this pattern continues.

Why should our customers be handed potentially substandard systems for which you don’t have time to write automated tests? Appreciation for the time of others is an important aspect of compassionate collaboration. By selfishly saving ourselves time by avoiding writing tests, you are suggesting it’s acceptable for our clients to spend more time searching for system shortcomings. A client’s place is not on a pedestal. Developers and stakeholders should work together. But we must respect each other’s time.

Crossing the Threshold

Although our Happy Developer Guide advocates minimum coverage across all of our code bases, tools are required to enforce this benchmark. Reliance on developer diligence is not enough. Over the past year we have created several new projects, initially without any mandated thresholds on test coverage.

Adding gates after the fact can foster frustration as programmers have to pick up the pieces of others not adhering to these axioms. Collective code ownership is a key quality of strong Agile teams. Each engineer should follow the Boy Scout rule, and leave the code base better than they found it.

Like a camp ground, we should leave code better than we found it to preserve its natural beauty

To balance developers differing principles, you cannot rely on the strong, proud engineers to write the additional tests required to bring your code repository up to scratch. Avoid this animosity by including these limits from the beginning to encourage compliance to your coverage commandments.

Thanks for reading!

A Fine Blue Line

Evaluating Time to Market for Grid and Chart-based Features

Building banking software exposes us to a lot of numbers. Balances, ratios, percentages, rates, they are littered throughout the systems that we create. The difference between data and knowledge lies in context. Shouting 42 from the rooftops is not very meaningful until you’ve read The Hitchhiker’s Guide to the Galaxy by Douglas Adams.

To discern knowledge, we need to unite data with context

It’s unsurprising that the majority of banking applications centre around massive grids exposing expansive arrays of digits. Showing scores of figures is the easiest option as we see our goal of presenting the right number. We forget that we should always show the correct values, regardless of representation. Discerning meaning from larger data sets is exceptionally challenging.

Not so recent events have got me contemplating about why we always settle for grids. It is regularly seen as the easy way out. Moving on from the human aspects of development, this week I focus on adoption of visualisations. I present my thoughts on our trepidation of utilising them over traditional tables.

Time After Time

It is a common misconception that graphs take significant time to develop over tabular views. Adoption of agile practices into our software development processes has granted us numerous gifts. To date, our focus on small, frequent releases has resulted in a large amount of new features being made available to our clients.

Once in the habit of producing new functionality regularly, we often impose pressure on ourselves to deliver increasingly more rapidly. This strain will influence our design decisions. However, the notion that charts are more challenging to construct is a fallacy.

Poor Excel skills aside, this tool highlights that the underlying data sets of charts are also tables

Working in banking, my clients exhibit a strong preference for Excel, and have a far better knowledge of the tool than I. It is an essential tool in their toolbox for conducting their daily responsibilities. The charting feature within Excel transforms tabular representations into a chart. The values underpinning graphs and grids are essentially tables.

By using one of the multitude of charting libraries available to us, we can transform these two-dimensional arrays into valuable visualisations using similar logic. My experiences over the last few years have shown that development time for charts and grids are on par. Our team regularly delivered chart and table based controls in a single development cycle. Furthermore, with definition of a common contract, the time to market has been further reduced. We just need to identify the use cases for which one is suitable over the other.

One is the Loneliest Number

With time no longer a factor, let us consider how to identify the best mechanism for presenting content. There is an inherent risk while building data heavy applications that we become monopolised by numerals. Accuracy is monumentally important. But to support our quest for correctness we must ensure the tools that we create promote a workflow that can allow users to achieve a quantifiable goal or benefit. Throwing a matrix of bamboozling digits together is easy for programmers, but can lead to information overload.

Endlessly searching through figures to find meaning takes its toll on people. To propose the best solution to our clients, we first need to identify the true problem. Design thinking is vital to identify the key goals of those using the system, and establish empathy with our users.

Design Thinking can be used alongside other development frameworks, including Agile, to help identify user workflow and value

The key goal of the empathise and design stages is to develop an understanding of the current challenges that our system should be striving to address. This is achieved by observing people and asking questions. What are users actually trying to achieve? What is that value actually for? What decisions and subsequent actions will be triggered from the knowledge invoked by this number? If it’s just a single integer, then show the value with labelling for clarity. If you need a few more, consider using heatmapping or highlighting techniques to show users where to look. The domain is critical to allow benefit to be discerned from the system.

Draw the Line

Once we have developed an understanding of the key system goals, that’s when the fun really begins, at least for me. Brainstorming and sketching out ideas may initially appear time consuming. However this is a misconception that can be addressed using low fidelity options such as pen and paper, or even Excel!

Ideating and prototyping with simple techniques such as sketching will prove the pen is mightier than the sword

Often we start with utilising simple visualisations such as bar and line charts. Such mechanisms are useful for identifying peaks and trending across our statistics. Once we start charting there is a danger that we only use these techniques, regardless of the observed objectives.

Researching alternatives will help us propose suitable solutions for our data sets. Seeking out innovative ideas will help you realise that information is beautiful. There are a few rules of thumb to help you on this journey. Sankey diagrams are good for showing usage flows and their composition. Directed graphs are fantastic at visualising relationships and hierarchies between key components.

As technologists, we strive to continuously improve our processes to produce valuable, scalable, maintainable software. Nevertheless, the features we build should be fostering continuous improvement to our client’s processes. Let’s propose the right control to solve the problem, rather than deceiving with a deluge of digits.

Thanks for reading!

Signs of Life

Searching for Signs of Developer Discontent

Recognition of a job well done in software engineering, or arguably any profession, is intriguing. Rock stars are rewarded for their achievements in building software with leading others in their quest to build software. One aspect that we never really prepare new managers for is the complexities of the human systems they support.

Do managers seek out the signs to address developer issues, or do take the wrong fork?

Building scalable enterprise applications is certainly not easy. Comprehending the hidden mysteries of the programmer psyche is far more challenging. Even more so when attempting to gauge their job satisfaction. Often we charge into battle at the point of no return. The signs are there long before, but we quite often don’t follow the route to the final destination. Here I ponder how to monitor themes of displeasure as an alternative to the knee-jerk reaction tactic, and consider if we are initiating the rescue mission too late.

No More Heroes

To determine if we are engaging in timely heroics, we need to first scrutinise the behaviour of dispirited developers. Having regular catch ups with your engineers is imperative in the quest to track their levels of fulfilment. This may sound obvious, but I’ve certainly seen on both sides of the line that this notion is not always apparent. In fact one junior developer recently exhibited extreme surprise that I was putting in a regular catch up at all.

Amazement aside, getting the most out of a 1–1 on either side requires skill and practice. There is a temptation to use such sessions as a general status update. Managers should be mindful that this could be a diversion strategy. People normally love talking about themselves. If they are focusing on tasks, they may be showing reluctance with discussing issues.

Single open questions are the key to breaking that cycle. We tend to ask multiple at once to extract all we need. Perhaps it’s out of impatience to identify a solution. Adoption of a more laid back style is imperative to extract issues early. Ask one question and wait. Embrace the silence. There may be a temptation when vexations are voiced to immediately react with reassurance. But getting to the route of the problem relies on listening and understanding their perspective.

A Sign of the Times

As managers, we know we need to listen. One of the key responsibilities we should focus more on is identifying and rectifying issues. So why are we still missing the signs?

Humans struggle to deal with awkward conversations. We actively avoid discussing uncomfortable matters and will sweep them under the rug. If they are out of sight, they are also out of mind. Once we find out about issues, great or small, we need to do something to address them. Actions speak louder than words.

As the signs become brighter, we shouldn’t continue to ignore the issues, even if they are difficult for us to fix

As managers we need to ask ourselves why we are in denial. There are several reasons that could be at play. Perhaps it is easier to ignore the predicaments we see, especially if you are powerless to fix them. Potentially we become disconnected with such problems, especially if we have never needed to carry out the originating task or function.

Some reasons may be less innocent. We all have aspirations and agendas. Managers, like engineers, can become engrossed in deliverables and miss the big picture. It can be challenging to dedicate time to addressing a pitfall for someone else that may contradict your own viewpoint. Participating in meaningful conversations to grasp their differing perspective is vital in our role in empowering programmers. If you project an agenda, or worse contradictory opinions over time, people will be less likely to raise concerns.

Measure for Measure

Once managers engage and begin listening, it’s important to monitor issues and their occurrences. Managers are certainly not infallible, and grievances can arise again. If you are not able to rectify a particular issue, measuring how often it arises is critical to ensure your developers don’t become frustrated.

Use your regular catch ups with disgruntled directs to identify the key themes of conflict. If they are becoming more regular points of discussion, it’s a strong hint that the issue is not being addressed. Not everyone is going to yell their issues from the rooftops. If you’re waiting for that point to sort out their problems, you are running the risk of them leaving.

You never really understand a person until you consider things from his point of view…Until you climb into his skin and walk around in it.

Atticus Finch, To Kill a Mockingbird

Continuous improvement should apply to people as well as processes. Any issues you discover are productivity blockers for the developer in question that we should be attempting to alleviate. Try alternative approaches to rectify the concerns raised. Encourage your people to raise all burdens, regardless of your own affiliations. Only then can you empathise and take a walk in their shoes.

Thanks for reading!

Broken Mirror

Tackling Retrospective Regression

Taking time to reflect is important. In this chaotic world we need to deliberate more in order to grow. Humans are generally pessimistic creatures. We tend to focus less on our achievements than our failures when recalling past events. Through 20:20 hindsight we can identify our mistakes and the exact set of steps we would enact to undo our wrongs. The Undoing Project by Michael Lewis covers this condition far better than I ever could.

Mistakes in a mirror may appear closer than achievements

Retrospectives shine a mirror on how we build software. Their aim is to provide an opportunity to dwell upon the collective successes and failures of the team, and use that hindsight to improve. The initial euphoria is great, but over time the shine begins to dull. Here I ponder some emerging bad habits that can develop over time, and how you can polish that retro mirror to return it to its shining former glory.

Blind Hope

One of the cardinal sins of agility is not having retrospectives at all. This is a symptom of novice and experienced Agile teams alike. All the reasons I’ve encountered to date are not by any means intentional or malicious. It may be tempting to start with just a stand up and build up to retrospectives. However, you’ll miss the opportunity to routinely assess progress.

Once you are having frequent retrospectives, it is paramount to learn the warning signs to preserve the most important of ceremonies. Where the regular meeting invite lies on the team calendar is vital to preserving the voice of the team. Scheduling at the exact same time as a stand up may seem like a smart solution to address context switching. Regardless, you run the risk of focusing on your stand up, and forgetting the retrospective.

Consider the humble ATM, or Cash Machine if you’re so inclined. I recall an anecdote from my university HCI class on why your card is released before the cash. The lecturer in question gave an amusing tale pertaining to treasure seekers taking their money and leaving their card in the machine. To reduce fraud, the order was altered since the key aim of the transaction is to obtain those crisp notes.

Humans are goal oriented, so make sure the end goal is not blocked by any others

Regardless of whether this fable is an urban legend or not, the moral is clear. With a double booking, you run the risk of confusing the true goal. Once the stand up is complete, you are relying on the team to remember a more infrequent ceremony. Dedicate a reoccurring entry to your retrospective, regardless of your Agile paradigm of choice. Maintaining this slot is critical to ensuring that the meeting always occurs. Not honouring that habitual entry removes your teams voice and breeds discontent. So hold it at a different time, preferably at a time where they can get comfortable with a cup of tea and contemplate recent events before the retrospective starts.

Everything Changes

Sometimes people need a change of scene. Routine can be great, but it becomes repetitive after a while. While there are many particular formats a retrospective can take to elicit feedback, over time a routine can render them less effective.

Every team has their preferences. A retrospective format can develop into a familiar security blanket. If your team is using the same questions every few weeks, it will enforce a particular frame of mind when attempting to identify improvements and celebrate successes. Consider evolving your plan to get your team thinking differently. True, some may be more effective than others. Nevertheless, failing fast works for retrospectives too!

Thinking Out Loud

Fostering diversity within teams is imperative for many reasons. Differing experiences, backgrounds, opinions and personalities help us build strong teams that will bring innovations to the software we write. Much research has been performed on software team cohesion and the personalities that are drawn to software engineering.

Be mindful of how contrasting personalities engage in retrospectives to empower team members to speak. Balancing introverts and extroverts is particularly challenging. Care must be taken to avoid louder voices being prioritised. In troublesome times this may breed discontent among quieter individuals.

Like tortoises, we should encourage quieter team members to come out of their shell during retrospectives to obtain a collective view

Colleagues with perception and feeling characteristics, as classified under the Myers-Briggs Type Indicator, make for great cohesive agents. They can prevent extroverts from dominating the session. Asking probing questions to introverts directly can help bring them out of their shell. Picking on the quiet ones may seem unfair initially , but it will make for a more balanced viewpoint. However, this does not mean that open questions should not be asked of all team members, regardless of personality, to extract more detail.

Reaction to Action

Regular reflection on our progress is vital to refine our development practices. Good retrospective facilitators will help extract possible process improvements. They are essential to thwart attempts to turn your retrospective into a rabble. Actions speak louder than words after all.

Once these activities have been identified, they can’t just be forgotten. We need to follow through with such suggestions and measure their effectiveness. Logging these ideas and assigning owners is imperative to ensuring their execution. One possible enhancement for us is assigning these items as part of our normal work. Only then will we be able to see the ripple effect of any pebbles we skim across the water.

Thanks for reading!

What the F**ture?!

Tackling Feature Toggle Aversion

We are fortunate enough to work in a cosy world of a component-based architecture. Several of my colleagues have a love of microservices, and none of those are afraid to shout it proudly from the rooftops. Our approach introduces a lot of benefits ranging from the obvious such as decoupling of key logic, to flexibility of hosting.

Developers need to be as comfortable switching features off as they are with a light switch

Multiple teams owning these components introduces some challenges. When things don’t go to plan, a single team can block itself and others if that new shiny logic is not ready. I’ve witnessed more than one instance recently where toggling the feature off would have prevented the ensuing frustration of features being blocked. Unexpected behaviour with features in production would also have benefited from a feature flipper. Here I reflect on recent issues on encouraging feature flag use, in the hope we can learn to love the off switch.

Capture the Flag

People are scared of being found out, especially when they don’t know something. It takes a lot of nerve to admit lack of familiarity in a world where knowledge is power. Even the most humble of egos doesn’t want to get caught in the trap. I have many developers not using toggles that when approached in a more comfortable environment will admit they don’t know what they actually are.

I’m not just talking about naming here. As outlined by Pete Hodgson and Martin Fowler, there are several different names in use. However, a rose by any other name still smells as sweet. The problem is that programmers believe that the implementation is fundamentally different depending on their usage of framework X or technology Y.

Be comfortable that surrendering to feature flags does not make your code any less elegant

Developers think we need to have an all singing, all dancing framework that can turn functionality on and off. I’ve seen examples of how to build such toggles on both the client and server code. I advise that under the KISS principle, the simplest approach is always best. To that end, a simple constant controlling an if statement is suitable for the majority of use cases. If this can be parameterized to be passed into the process to permit switching the logic off in production with a config change rather than deploying a new code version, all the better!

It’s Complicated

It’s not simply the case that once developers know what a feature toggle is and how they can be constructed that they will immediately be sold on using them . I’ve heard quite a few attempt to justify not writing feature toggles. Developers and leads alike regularly attest that they don’t need toggles, for differing reasons.

The first, is their effect on code complexity. Those of us from a Computer Science background will remember back to that first lecture on complexity. Perhaps several algorithms were scrawled in messy lecturer script on the blackboard, with the class tasked with determining their complexity. Those of a different discipline will have picked it up from general reading or training.

Regardless of where that spark of knowledge came from, we have answered enough exam questions and provided enough interview answers over time to be able to explicitly calculate complexity with ease. It implicitly forms our decisions on algorithm design and coding on a daily basis. For some, it is used as a justification for not adding a feature toggle. That is certainly not the case if we remember back to our complexity rules.

Algorithm elegance doesn’t justify a lack of toggles. Part of this stubbornness could boil down to a misunderstanding of the permanence of a toggle. No one is suggesting that toggling code should be permanent. Good developers will remove existing toggles once the logic is verified in production. Great engineers will add and remove them consistently to their features. Leads need to support these engineers in their introduction for new features and logic changes alike.

So Much for My Happy Ending

The perpetual optimism of developers is another challenge in the adoption of feature toggles. No one wants to think that building out the latest story will go anything but smoothly. Engineers will blindly follow the yellow brick road all the way to Oz. They will typically have at least one or more of the below mindsets:

My feature will definitely go live! I will not encounter any blockers along the way.
I’ve comfortable with the code base so it will definitely take me X days to implement this story.
This new feature will definitely work first time. My code is perfect, bug free and I’ve covered every edge case with my tests.

Each of these arguments can be used by developers as an attempt to discount building a feature toggle. Programmers are human, and optimists at that. We all want to feel the warm glow of our work being used by clients. Nevertheless, with this optimism comes the notion that we will deliver perfect features, on time, every time. Turning that feature off suggests that all the blood, sweat and tears they poured into development will be in vain.

It’s not because they’re incompetent, or that they are calendar-challenged, it’s just that estimating the time to do something we’ve never done before is something we suck at. And, by nature, we’re often optimistic animals.

Jeff Patton and Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product

We need to nurture faith that there are benefits to hitting the off button. The benefit is that we have flexibility to cover when things go wrong. It’s alright for development work to run over, to be incomplete, and that turning it off and on is a good thing. Foster some humility in your developers to get them comfortable switching their features on and off. An initial leap is satisfying for individuals, but it’s not always the right call for the collective.

Thanks for reading!

Leave a Light On

When Bored Developers Become Frustrated

Leave a Light On

When Bored Developers Become Frustrated

Coders want to spend the majority of their time coding. It may sound like a rather obvious statement. Yet it remains the case that we struggle to balance the coding to release management ratio. Developers are comfortable performing other tasks besides, but the value needs to be clear.

Identifying the signs of unhappy developers and acting on them promptly is the key to keeping the best people around

I’ve spent significant time over the past week talking to unhappy developers. Disengaged developers. Each in different stages of unhappiness. All tackling their frustrations in different ways. It is true that bored people quit, but disheartened people quit too. Here I reflect on how such discontent manifests and the signs to look out for to keep your best developers around.

Are We Human, or Are We Developer?

When reading Managing Humans by Michael Lopp a few years ago, one chapter in particular struck a chord with me. Bored People Quit. In hindsight it was mainly because I myself was bored at work. I desperately needed a change.

Recent events have got me thinking about that time again. Reflecting on prior experiences has certainly helped me establish different techniques for supporting those who reach out for help. I re-read the chapter this week to help reflect on my handling of each situation.

Hunting the Apathy Grail

Identifying the signs early is important to prevent boredom transforming into anger. As managers we should always be on the lookout for changes in behaviour. We should always ask questions to assess their engagement with their daily work. Classic traits highlighted in this chapter include changes in schedule such as last minute vacation and changes to working hours.

> The goal here is to discover boredom before they know it, and the act of a > simple question might be just the mental impetus they need to see the early > signs in themselves. > > Michael Lopp, Managing Humans

In the slightly more modern age of flexible working, consider the frequency of work from home days. It is not an exact science. Nevertheless it can also suggest your rock star is participating in initial stage interviews and coding exercises. Quite often it can be a sign of other life events. Even those we should be on the lookout for as managers to ensure we provide the necessary support to retain our top talent.

Thinking back now, I regrettably see the tipping point more clearly in at least one case. Handling these effectively will build loyalty. Get it wrong and you could cultivate resentment instead.

Foster the Frustration

What are the key activities that cause boredom and frustration to fester? Lack of toys to tinker with is definitely the most common one I have experienced in my not so recent past. Software development is not just limited to spending endless days locked in a cupboard writing code. Talented developers are always happy to own development and release management tasks if the balance is right. Admin needs to be seen as a valuable and concise set of steps, rather than a wall between them and reaching coding nirvana.

Governments and large organisations alike love to apply processes to feel in control. Paperwork is a necessary evil. In regulated environments such as mine, management often struggle to consider the volume and effect. This can lead us to enforce waterfall artefacts on top to give management security, regardless of Agile adoption. Regulated environments such as ours can still cultivate agility. Working software over comprehensive documentation is baked into the principle because it is the main item of progress for developers and clients alike. If it takes several hours just to go through the motions and get the paperwork together, we may need to rethink the balance.

Never too Late?

Boredom is frustrating, but being hounded when you don’t want to be saved is tedious. Scurrying around trying to convince someone to stay is not always the answer. You need to read the situation and determine what is your best course of action.

Managers should test the waters before pulling out all the steps. Some want to skip off into the sunset to find their happy ever job ending.

Some individuals do want to be saved. Some want to be woo’ed with you charging into battle to fight to keep them. But some quite simply just want to be left alone. For the latter, initiating a fight may be doing them a disservice. It may be more appropriate to let them go. Choosing to leave a role is a scary, exhilarating time. There are a lot of emotions at play. As a manager, the danger is that you’ll confuse them into staying and harbor resentment. Lopp is indeed right that once someone quits, they can do so again if they stay. The precedent has indeed been set by that point.

Keeping good people is hard. It is important to identify the signs early and support them with opportunities to grow. Constantly reinforce regardless of whether they are happy and frustrated that your door is always open. If they do end up growing, provide them with the support they need. When facing the unknown, people like to know that the door didn’t slam shut behind them if that rosy new role doesn’t quite pan out. Let them know that you will leave the light on.

Thanks for reading!

Like Real People Do

The Important of Failing Fast When Managing Humans

The title of Manager is one that up until recently has instilled a level of fear in me. The fact that it is regularly used interchangeably with Leader in the corporate world probably doesn’t help.

Leadership for me describes a confident, charismatic individual charging forth with their army into battle with gusto and enthusiasm. Hardly the term I would use to describe the mousy impostor sitting in my chair that bounces between phone calls and meetings like an overenthusiastic jack-in-the-box!

We need to stop fearing failure and take more risks with encouraging developers

Regardless it’s a title that has followed me around since my recent promotion and role change in January. Not so much that I have great power, but responsibility is certainly on the up. Here I reflect on the past six months, and ask why we fear failing fast when managing software developers.

Why Fail Fast?

The concept of failing fast is rooted deep within innovation theory. As much as our massively inflated egos would like to think otherwise, we are not infallible. We often don’t know if the latest wacky idea to solve our problem will actually work. By encouraging early failure, we empower teams to openly propose new ideas. Diversification of thought and workforce has already been established as vital for organisations to compete in the market. Yet if we can adopt such a nurturing environment for product development, why can the same not be said for people development?

To understand if we can fail fast, we need to consider what the ramifications of people management failures actually are. That depends on the circumstances. It ranges wildly between that individual having to work a few extra hours to being passed over for promotion or role change (or worse). However, what about the effect on the manager themselves? We are human after all!

Managers Aren’t Psychopaths… Usually

A key motivation of human behaviour is maintaining the balance between pleasure and pain. Unless you are a masochistic individual, it is more likely that your actions are an attempt to maximise the former. Good managers establish a strong rapport with their directs, without getting too sucked in. It may be easier to switch your emotions off the moment you enter that intimidating corporate tower of doom. However, by flicking that switch you lose a connection with colleagues that you can leverage to support them in completing their best work.

Managers still need to connect with their directs to get the best work from them

It is challenging not to get invested as you build such relationships. These bonds introduce unnecessary pressure on always getting it right first time. As we start to care, we realise that it’s detrimental to get it wrong. The software I write isn’t safety critical. As a wise man once said to me, no one will die if that new feature is not released next week.

Empathetic managers see breaking a person’s expectations to be more detrimental. Failing a person has a larger side-effect than a failing test. It is absolutely true that software development is easier in comparison to people development. The trick is to remain as objective as you can, rather than the opposing extreme of ceasing to feel.

Chain… Keeps Us Together

One of the hardest challenges I’ve had to conquer over the last six months is being able to let things go. Both in terms of delegating work, and admitting defeat in ongoing battles. A key benefit of delegating is to develop another person. As failing fast on a task is an amazing thing, we need to become comfortable with letting them make those mistakes. Even if sometimes they need to make the exact same one we have ourselves done before.

> It is better to lead from behind and to put others in front, especially when > you celebrate victory when nice things occur. You take the front line when > there is danger. Then people will appreciate your leadership. > > Nelson Mandela

As the chain gets longer, we have less control over the outcome. Being a control freak becomes impossible. The important next step for us as managers is to provide constructive feedback on how they can improve, rather than resulting to criticism and playground gossip.

Developers may enjoy playing with code, but we should nurture and encourage mistakes

Examples are vital to this effort, but our own experiences can be used as a parable. Be open with your own journey, and use the woeful tales of our achievements and regrets to reinforce these messages. Aside from being a useful learning point, it exposes a ray of humanity that managers need to feel comfortable showcasing. I may now be a manager by day, perhaps a leader in time. Regardless, I certainly don’t dream of electric sheep by night!

Thanks for reading!