Skip to contentSkip to footer

Blog Article

Two Weeks In The Life Of A Developer At Mindera

The yellow Minder icon against a black background on the homepage of the website for software engineering company Mindera.

Mindera - Global Software Engineering Company

2022 Jun 8 - 1min. Read

Share

Copy Page Url

A MacBook Air on a wooden table, with an iPhone, writing pad, and pen to its left, and a cup of coffee to its right.

Two Weeks In The Life Of A Developer At Mindera.

At Mindera, we work in two-week sprints. It gives us the agility to change direction very quickly and allows us to have regular interaction between the team and stakeholders. It helps us to deliver on our commitments.

We wanted to explain what two weeks in the life of a developer is like at Mindera and we sought the expert input of PJ Evans, one our senior developers.

This blog post brings PJ’s thoughts together, covering:

  • Planning
  • Stand-up
  • Reviewing the board
  • Establishing velocity
  • Forming, storming, and performing
  • Picking up tickets
  • Working on tickets
  • Unit tests
  • Acceptance criteria
  • Reviewing the code
  • Ceremonies

Discover how all of these things work in practice for a developer at Mindera.

Planning sprints at Mindera

Before the sprint starts, we do some planning. The team looks through the backlog. We assess the work we need to do that’s been sliced-up into tiny little pieces.

We also all get together and agree what we’re going to do in the next sprint. This is keeping in mind pre-existing meetings, how many people we have off, how fast everyone is able to work, etc... From that, we work out velocity, which is the story points that will be completed in a sprint.

This means we’ve agreed in advance what we’re going to do and what the workflow looks like for the next two weeks. We then start our sprint.

The days often start with a quick stand-up

There are a couple of reasons for starting the day with a stand-up. Firstly, it’s a good chance to communicate with people and to do a bit of team building. Secondly, it’s an opportunity for people to call out any problems they have.

If there are problems then our delivery manager (who keeps us all on the straight and narrow) can take those issues on and work with us to sort them out.

We check the board

Once we’ve finished the stand-up, we’ll then take a look at the board. The board is made up of columns and the simplest arrangement is ‘to do’, ‘in progress’, ‘done’. Typically, we have about five because we’ve got to have QA (quality assurance), user-acceptance testing, and things like that.

The idea is that you start the two-week sprint with a bunch of tickets on the left hand side in ‘to do’ and that in two weeks time you have them all on the right hand side in ‘done’. That’s a perfect sprint. It very rarely happens but I’ve seen it!

We establish our velocity

What you get from the board is your velocity. What that means is how many tickets can you get through. Because each ticket has a point assigned to it — a size, if you like.

Some tickets are bigger than others. You can sort of say “I reckon I’ll get through this amount of workload in two weeks.” Sometimes you get it right, sometimes you get it wrong, but you learn as you go along what your ideal velocity is. It’s called forming, storming, and performing.

Forming, storming, and performing

You form, which is where you all come together and try and learn how to work together. Then you storm for a bit, which is where you experience conflicts. Then you perform, which is where everyone knows where everyone is, how to get along, and how to deliver velocity.

Picking up tickets

You might have a ticket in play or at the start of the sprint you pick up a ticket. In some groups you’ll have people who specialise. For example, the React person, the database person, and the Node backend person, and they’ll pick up tickets based on their specialisms.

We try to discourage that. Even if people are specialists, we try to be as full stack as possible. The primary reason for that is to benefit the engineer. It helps if they take on a ticket that’s not exactly in their comfort zone.

The rule is you can pick up any ticket you want. If it’s something you’re not really au fait with then you collaborate with someone with expertise in the things the ticket covers.

For example, I’m more of a backend person, so I struggle with some of the more complex React stuff. What I’ll do is find the React specialist and say “Can we pair on this?” Pairing is one of our strengths at Mindera and we encourage it. In pre-COVID times you would sit down together at the same screen and run through what you’re going to do.

Working on the tickets

A large part of the day will be working on tickets and pairing up with people (where appropriate) to do so. A ticket is much more than just a unit of work.

Let’s say you have a ticket to put a unit input box on a screen — please insert your name. What you’ve got to consider are what we call the ‘non-functional requirements’ of that ticket.

So, does it need to be logged somewhere that the user has inserted their name? How will we know if it’s broken? What are the unit tests for it? Etc…

Unit tests

A unit test is a very, very specific test that just tests one piece of functionality — it doesn’t test anything else, it just isolates and tests that one thing.

Developers are responsible for our unit tests. We then have a QA facility within the crew, who will build the integration tests that actually bring these things together.

Acceptance criteria

We make sure all these things are ticked off and we call that the acceptance criteria in the ticket. That’s a statement of fact that if all these facts are true then it’s done.

Returning to the previous example of the unit input box on a screen, the user must be able to enter their name (they must not be able to leave it blank), the button must work, and it must show an error message if they have left it blank. The ticket must do everything required of it to meet the acceptance criteria.

We review the code

The idea is that if that ticket is done then the piece of functionality it delivers can go out to production. However, before we do that, the code needs to be reviewed.

We’re all working on our separate copy of the codebase — we call that our branch. We have this because if you had ten developers all working on the same code then it would be chaos, you’d always be overwriting it. So, we use Git version control to make sure we don’t crash into each other.

When your branch is complete you do a pull request. This is you saying, “I’ve finished my bit and would now like to be brought into the main code base.” Another developer in the team then reviews it. In a project you usually have two people who will review it and you actually set it so that you are not allowed to push that code into what we call ‘main’ from your branch unless two people have said it’s OK.

Code review is a really important part of the development process and it’s what I spend most of my time doing. It’s looking through the code and asking yourself “Does it make sense?”

If a developer has created the code in a way you haven’t expected then find out why. Because it’s something that might not have been obvious to you but then you decide that it was the right approach.

There’s a comment system, so you can say things like:

  • “Why don’t you do it like this?”
  • “I don’t think that’s named right.”
  • “This isn’t in keeping with our ways of working.”

But hopefully you’ll look at it and think “This is wonderful” and you’ll approve it.

When the two approvals go in then the code goes into ‘main’ and the ticket is handed over to a QA.

The devs do the QA section in some groups. In others the QA engineer does it. It depends on how they want to work. Basically, it’s a final go-through, on a fresh copy of the code, to see if the acceptance criteria have been met by this approved code.

If it has then it goes off to production and is moved to done. If it hasn’t then we deal with the issues that are causing it to fail the acceptance criteria.

Ceremonies

When it comes to the end of the sprint we have what are called ceremonies — a day of meetings.

Firstly, we have the most important one — the review/demos.

Review/demos

This is a really important part of the agile way of working. The idea is that you bring in the stakeholders involved in the piece of work you’ve done and basically make it open to anyone who is interested in what you’re doing as a project

People come into the call and we demonstrate what we’ve been doing for the past two weeks. The reason this is important is that if we have the stakeholders there (the people who are paying for this and want it in their systems) then they can turn around and say:

  • “We can’t do that because of X”
  • “That’s not what I meant”
  • “That’s brilliant. I absolutely love it. More of that, please.”

This is what makes agile work. Because if they do that then we say “OK, it'll only have cost us two weeks. We can now change.” We can now go back and look at the backlog, look at all the tickets, and say we need to change this, this, and this to give the stakeholder what they need.

Rather than the old waterfall projects, where you do six months of work, show it to the stakeholders at the end and they say “Oh, no. It’s all wrong.” It’s working with the stakeholders to make sure everything is covered off.

It’s impossible for a developer to know everything about how a business works. There might be some other internal dependencies you have no idea about and then suddenly you’re looking at it and the stakeholders say “You can’t do that because of this EU law.” And you’re like, “Well, I’m not a lawyer, so I didn’t know that.”

But it now means that we can put another ticket in the backlog to change it and put it in the next sprint. Then we go to two weeks later and they say “That’s perfect!”

It’s also showing the stakeholders that we are getting on with it and we are adding value.

Secondly, we have retro.

Retro

This is where we all get together with a coffee and we talk about how the sprint went — what the last two weeks were like. We’ll ask:

  • What went well?
  • Are there things we can improve on (which there always are)?
  • What are the actions to make the improvements happen?

It’s where the delivery manager really comes into their own because you have to create a very safe space. You have to try to avoid any kind of conflict between developers, so a bit of psychology comes into running a good retro.

You’ll have good ones and you’ll have bad ones.

You’ll have two weeks when everything’s gone wrong and you’ve gotta sit there and pick through it.

In-between that, you have regular meetings called refinements.

Refinements

The tickets in the backlog are structured, you have what are called ‘epics’. An epic is something like “I want a search engine on my shopping site.” It’s a huge job and that doesn’t tell you enough.

So, what you do is break that down into user stories. They have a format like “As a customer, I want to enter a search term into a box, so that I can see the search results.”

You’ll break the epic down by asking “How is a search engine going to work?”

The user stories break down into tasks, which are the actual pieces of development that would deliver that story.

We always do it from the user’s point of view. We talk about what the user journey is and we work out what we need to develop from that journey. It means that UX is coming in right at the beginning.

But writing those tickets takes time and expertise. What you tend to do is you stub them out. We have story writing sessions where maybe a tech leader will sit down with a product owner and we’ll bash out a load of tickets.

As we’re going through the process, we’ll sit with the entire team and do refinement. This is where you go through the ticket meticulously and say:

  • Do we understand what the dependencies are?
  • Do we understand what this ticket has to do?
  • Do we understand the acceptance criteria?

Once it’s refined, that ticket can then be pointed. We assess how much work we think this is and whether it’s too big.

The rule is that a ticket shouldn’t be longer than a sprint for one person to do. So, if it is bigger than that then there must be some way we can slice it up and separate it into two or more tickets

They can be boring meetings but they need to be done!

Finally, planning

Right, what are we doing in the next two weeks? We look at the refined tickets, our predicted velocity and work out how many tickets we can complete in a sprint. Now the new sprint starts and the whole process repeats itself.

Mindera has a big focus on personal development

Mindera has a great belief in personal development. For instance, in our ways of working.

When a team forms we often have a few sessions about how we’re going to work together. We’re given quite a lot of autonomy in general by the clients on how we’re going to work and which particular practices we’re going to use — there’s a thousand different questions to be answered!

One of the things we do in our way of working is to leave an afternoon a week open to every Minder to do whatever they want, so long as it offers some value to the business.

For example, Mindera has a Udemy license for everyone in the company, so if you want to spend Friday doing a course then you can. You may also decide to spend it working on a side project, looking at a programming language or framework, or something else.

The key is that there’s time put aside for you to do that.

Now and again we like to break things up with hack days. This is where you generally spend one day (sometimes two) where you all get in a room together, with an absolutely clean slate, and you build something.

They can take two forms:

  • Fixed agenda — focused on a specific goal
  • No fixed agenda — purely a team-building exercise

These are fun events and a great way to get to know your colleagues.

Rounding up

There you have it, the things that happen during two weeks in the life of a developer at Mindera. We hope you’ve found this blog post helpful. If you have then please do share it on your social media channels, so your peers can benefit from it.

Share

Copy Page Url

The yellow Minder icon against a black background on the homepage of the website for software engineering company Mindera.

About Mindera

Global Software Engineering Company

Mindera is a global software engineering company. We're humans, techies, and have fun working together.

Let's take this to your inbox.

Don’t miss a thing. Get all the latest Mindera updates, news, and events.