Agile, Craftsmanship

Long live Code Reviews! Code Reviews are dead!

Let me introduce you to Malcolm. He’s my imaginary developer-friend currently working at Mega Enterprise Inc Ltd Corp. He’s been butting heads with the lead developer, Jack,  for a while now. They don’t seem to be seeing eye to eye on a feature that Malcolm implemented. You see, Jack doesn’t like how Malcolm writes his code. Formatting is wrong and he uses way too long variable names, and he doesn’t write a single comment and…(list goes on)! Jack hates reviewing Malcolms code. Malcolm usually gets his code back from Jack, with a long list of TODOs. So Malcolm goes off to re-do most of his work just to give it back to Jack…When Jack’s finally happy with the code; It adheres to his preferred coding style and uses the correct enterprise patterns that have been decided upon. He allows it through the magic gates to master. Continue Reading

Agile

Accepting that every team member is doing the best job they can

Many software development teams have a process including retrospective meetings. An opportunity for the team to look back at a period of time and assess how it has functioned. It’s often connected to the Scrum, but you don’t need to be adhering to any process / approach to see the value of having retrospective meetings. The goal of the retrospective is learning. What worked? What didn’t work? How can we improve something that’s broken? Should we continue with something that’s working?

Another aspect of the retrospective is that it’s meant to be a safe place for team members to speak their minds. The idea being that given a safe place, a team can figure out its own problems and possibly even solutions.

To create that safe place there needs to be trust. Enough trust so that team members can be candid with each other about issues that arise while working together. Enough trust that allows the team members to be vulnerable, and know that they won’t be judged. Where blame isn’t handed out, but rather bonds created and learnings are formed.

But how do we create a space in the busy life of a software development team, where deadlines and bugs are commonplace and there’s often a pressure to deliver something that will create value? Continue Reading

Valuable Resources

My colleague, Tomas Ekeli, and I held a presentation at NDC Oslo 2016 (read about my impressions from the conference) about “Making Komplett Big by going small“. It’s a tale of how the development team have played their part in making Komplett a leading Scandinavian / European e-commerce provider. What we’re doing to keep up, and our plans for the future.

If you’re ready to get your feet wet, then go ahead and watch the talk. I’ve added more background information about the talk underneath if you aren’t convinced yet.

The talk

Continue Reading

Agile

Presenting software to non-technical users – 8 ways to make your product demo shine

We’re sometimes placed in situations where we need to present our software to stakeholders, business owners or end users. These users may or may not be technical, but they will most likely be the other side of the user interface you are creating. They are the reason you create software and are genuinely interested in the end result. In recent years, with Agile and Scrum, these presentations tend to take place more often and you’re in the limelight presenting the latest and greatest. Many years of honing our skills as software developers have all but prepared us for this challenge, and we may end up getting a response from the attendees along the lines of this:

Photo credit: markhillary via VisualHunt.com / CC BY
No, we’re not impressing anyone –  Photo credit: markhillary via VisualHunt.com / CC BY

Too much uptight focus on technical details, digging deep into issues that nobody cares about, discussing the framework, library or platform chosen to solve a particular problem leaves you attendees bored, confused and sometimes feeling dumb since they haven’t got the faintest idea what you’re talking about. This leads to frustration, arguments, cold-fronts or just a general feeling of “meh”, where developers, stakeholders and users just don’t get the value out of this important meeting arena they could.

So what’s a developer to do? Here are some tips and thoughts for preparing for, presenting and participating in more technical presentations.

Continue Reading