Changes to our Agile Process

At Thinknear, we have used the Agile methodology since the inception of the company. But a few months ago we made some changes to our process to help improve out team. Some were changes to the parameters of the methodology and some were changes to follow the Agile methodology more strictly. Some of the changes also coincided with our engineering team splitting into two teams, which should give you a sense of our size (~14 engineers now). As your team grows it is vital to adapt your processes. Things that worked with 3 engineers, fall apart at 10 engineers. Things that work at 10 engineers I am sure fall part when you get to 25 engineers. I believe engineers who are adaptable and problem-solvers (not just code problems) should be sought after in startups. It can be overwhelming to engineers who are used to the big company pace.

I wanted to share some of the changes we implemented at Thinknear, and discuss the impact of them.

One Week Iterations

We moved to one week iterations from 2 week iterations. I would recommend this to any group that faces a lot of change or uncertainty (e.g. early startup). It allows your team to evaluate what they are doing much quicker. It is a bit ironic that our engineering org is maturing yet we decided to shorten our sprints.

But I would argue there are a lot of other benefits as well. When you have a week of work, you work even harder to break down your stories into smaller pieces. You only have a week of work, so if you have stories that take you 3-4 days, it feels like you get nothing done. Smaller stories are great for many reasons; they make us feel more productive, they make us more thoughtful in our planning and our estimates are more accurate.

Another benefit is that if some unexpected work comes up that can wait a few days, we don’t have to bother re-arranging the current sprint and working it out with the PM/PO. Because the next sprint is “not that far away”, it gives stakeholders comfort when some of their work cannot be prioritized for the current sprint. This reduces the amount of negotiating that needs to be done.

Drawbacks. It can feel like you have 2x the meetings. This is something we are improving on. Be sure to change the cadence of activities that don’t need to be done weekly (e.g. backlog grooming). The goal is to make the meetings more productive and ideally shorter. If we finish some pre-planning meeting early, we will try to do a high-level and quick pass at what might be in the pipeline two sprints from then. It helps cut-down on future meeting time.

Team Based Sprints

We used to assign stories to each team member before the sprint started. We now prioritize all the work and let team members pick off the work in the order that they are prioritized. If two stories have a strong dependency, the same person will usually take both to improve productivity.

This approach gives the chance for engineers to have some choice in what they work on in each sprint. Many claim the benefit in a team based approach is that team members are more willing to help each other. This was never a problem in our case, so I can’t speak to that. But I do believe it is important to incentivize the right behaviour in a team. Thus, if an engineer has a choice to do their “own” work or help a co-worker with their work, they should be free to help the co-worker in hopes of increasing the velocity of the team in general.

Having engineers select work promotes learning of the systems, since we don’t preselect “the expert” for the story/component/system. I think the biggest positive is the pressure to not let your teammates down since everyone is expected to pull their own share.

I can’t think of any drawbacks of this approach. You might sacrifice some velocity by not having the most knowledgeable (at the time) work on the ticket, but the gain to sharing of knowledge outweighs this drawback IMHO.

Story points vs Time estimates

We decided to move to story points in the estimating of stories. We use the Fibonacci sequence with a maximum story point size of 5. If it is larger, we will break up the story into multiple stories. This change has allowed us to estimate quicker. Measuring relative size is easier for us, instead of thinking of all the components that need to be built for a story and how long each will take. We instead think about questions like:

  • what are the unknowns?
  • have we done this before?
  • how many pieces is this touching?
  • will we need to do any refactoring?

We ask these questions because they usually uncover the hidden complexities.

Everyone will try to relate story points to actual work productivity. It is an urge that you need to fight because you will lose the benefits of using story points. Also at the start of our process, we didn’t know our velocity so we didn’t know what we could accomplish in a sprint. This takes a few weeks to get used to. This approach won’t work well if a team’s membership is highly variable from sprint to sprint, since you need to establish a baseline for work.

Sprint Retrospectives

I am a big believer in retrospectives as long as the focus is on improving (future) instead of blaming (past). If you are a team that is moving fast and constantly dealing with change, retrospectives are a perfect chance to take a breather and reflect.

We started to do sprint retrospectives at the beginning of each sprint planning meeting. This process has helped our improve team communication in various ways. These meetings gives team members a opportunity to bring up anything they liked or disliked during the previous sprint. We record all ideas and form action items for them. The team should agree on the process of dealing with the action items as well.

Some common things we bring up:

  • Did someone do an awesome job at something?
  • Was a particular task unnecessarily painful to do? How can we make it easier? It is worth it to do so?
  • Did we mess up something up? How can we prevent it from happening again?

The list goes on…

Sort of ironically (because people view retros as a finger pointing exercise), I have seen the biggest increase in praise for other team members’ work in these meetings. I don’t think there is enough of positive feedback in engineering organizations in general and this has been a welcome surprise.

It has been all positives on our side. You need to encourage everyone to participate in bringing their ideas to the table. The goal is to have productive discussions. Sometimes people vent through this channel, which isn’t necessarily a bad thing, but you want to keep the goal in mind of improving the team.

An engineering team is like a garden that needs constant maintenance. Retrospectives give us a process around dealing with the changing environment.

Research vs Design vs Implementation

For more complicated stories we have started to create research stories before we start implementation. This approach has allowed us to be more thoughtful in building components. In the old system, research, design and implementation often would be in the same story. This allowed us to move quicker when we were a smaller team. It worked well when our system was simpler. This started to break in our more complex system because the design became a larger chunk of the work and engineers would be prone to rushing through it. It also made it harder to scope these stories because of the hidden complexities that would come out once an engineer would dive into the task.

Separate research and design stories set aside some time for the engineer to properly plan the work. In a startup this might slow you down, but in more complex systems it leads to higher quality work. The engineer doesn’t need to rush through the work. Allocating the time also allows us to document the decisions made and knowledge gained, whereas in the old system it might have been skipped. This is extremely helpful as a future reference. You should aim to still have deliverables for these stories, such as presenting to the team or documentation.

This approach might not work in a very small startup as you need to move quicker. Regardless I always recommend having at least 2 engineers look at a design before implementation starts. The 2nd pair of eyes has saved countless hours implementing subpar solutions.

Those are the bigger changes we have made to our process over the last few months. So far they have been all positive changes. Our process will continue to evolve as we mature. The key is to have everyone on the team thinking about how things could be done better.


Every Software Engineer Needs Rules To Code By

As software engineers, we make lots of decisions on a daily basis.  It is definitely a skill that you can develop and improve upon.  From my experience, you get much more practice at this skill in a startup.  You get to build a lot of new software with not much guidance.  Many times you need to pick the technology/library/etc before you even start developing a solution.  I feel my decision making has improved tremendously in the year that I have worked for a start-up.  There are many ways you can improve your decision making ability.  One helpful mechanism for decision making, is having a set of rules that you live (design/code/test/implement) by.

Every software engineer should have a set of rules they live by.  Most developers have 0 rules when they finish university and start their first job.  The main reason for this is that we “gather” new rules through experience of screwing things up.  And I am referring to those bugs or time wasters that really cost you or your company time and money.  In school, you usually aren’t working on large pieces of software or mission critical features.  You also don’t own code for a substantial period of time usually.  So you don’t carry the burden of bad code or see the result of bad decisions.

The typical scenario goes something like:

  1. Create and release some feature
  2. Something very bad happens. (e.g. bug costing thousands/millions, spend 3 days debugging a problem, spend 3 extra days refactoring, etc)
  3. You fix it.
  4. You think to yourself, how do I not let this happen again.

There are a ton of other ways it happens, but from personal experience this is the most common scenario.  So people amass rules depending on the experiences they have had.  Very rarely do we learn from someone else’s mistakes.  One of my favourite quotes:

“Smart people learn from their own mistakes.  Smarter people learn from other peoples mistake.”

I think these rules are important to have because they help prevent mistakes and make decisions easier.  The less questions you have to ask yourself, the less decision fatigue you will experience.  Leave your decision making power to the more difficult decisions.

Without further adieu, some rules off the top of my head.

  1. No code change should go untested.  No matter how small or trivial.  I don’t mean unit test every single line of code, but see it work.  Too many times I decided not test something because it was too small or trivial.  Then subsequently it broke in testing or production and I looked really dumb for not performing a basic test.  I have seen this happen to other engineers as well.  It usually is painfully obvious that no testing was done.
  2. Don’t try to predict the future.  I have spent too much time thinking of what might come next when developing certain features.  I have been burned implementing extra features (feature creep) and then throwing it all away anyway because the system was going to be used in the way I foresaw.  This is especially true for marketing oriented organizations as they tend to change their mind a lot.
  3. When you can’t decide, just pick a route and go from there.  I used to spend a lot of time comparing 2 different approaches to a problem.  Often there wasn’t an obvious winner and I would spend too much time splitting hairs.  Now, when I realize that I am doing this, I pick a solution and go from there.
  4. Have more than one solution.  I read somewhere that having only one idea is dangerous.  Too many times I have implemented a feature only to have a co-worker suggest a different (more logical) approach which had me scrap half my code.  Now I try to think of these before I start designing.
  5. Behave as if things will go wrong.  I know this is on the “glass half-empty” side, but this sort of thinking has helped me.  How many times have you finished writing a piece of code and went to run/test it and it worked first try?  You will start to ask yourself valuable questions such as; how can this break? If it breaks, how will I know?  how will I debug it?

These are a few that I have learned and wanted to share.  I am still early in my career and I am sure this list will grow!