Agile, Software Teams and Zenhub | Technical Insights

Our experience of intentionally avoiding Agile and then adopting a pragmatic approach to Agile development with the help of Zenhub.

Agile, Software Teams and Zenhub

At Thinkgrid Labs, our philosophy is to keep things “simple”. This applies to our approach to the software development process, tooling, code, design, and system architecture. And when the need arises for complexity, we then explore what is the minimal amount of complexity to add to achieve targets. The alternate approach to this is to embark on adopting complex processes, tooling, code and architecture “thinking” or “hoping” a future need, a.k.a. “YAGNI”, which stands for “you ain’t gonna need it”. We shy away from “YAGNI stuff” unless there is high confidence in its need. In most cases, this approach works out well (based on our experience), yet, it failed for us in our software development process and caused us to pivot to Agile. This article hopes to outline why a too overly-simple software development approach can take more mental space from engineering and also lead to moving delivery deadlines.

When Thinkgrid Labs started out, we (on purpose) decided to take a very simple approach to the software development process. It was to be an experiment to find what is the most minimal process that would lead to maximal productivity. The team was familiar with Agile but chose not to use this methodology staying in line with our keep it “simple” approach. The approach we took was not a waterfall process, nor was it Agile. Rather it was a very fluid process. Meaning, that as work arose (or was discovered that needed to happen) we tried to complete it as soon as we can without much planning around it. It was a little Waterfall-ish and a little Agile-ish and consequently narrow-sighted. The problem with this was that a lot of mental space of the team was taken on a daily basis, just for planning out what work items to handle during the day. The upfront planning that happens in waterfall or in the grooming and planning ceremonies that happen in Agile happened on a daily basis. This affected creative engineering mental space. How so? The “when” and “who” to work on a ticket had more emphasis and talk time than “how” to work on a ticket, which was flawed. This led to poor acceptance criteria definitions for tickets. This fluid process also brought uncertainty about when we would hit our deadlines, since the view in focus was only two to three days out and not a few weeks or months ahead as is typical in waterfall or Agile methodologies.

When and Who to work on a ticket had more emphasis and talk time than How to work on a ticket, which was flawed.

A few months into the process, the team realized the shortcomings and decided to pivot to Agile. We also went on a hunt to find a tool that would facilitate it well. Depending on who you talk to, some will say that the Agile Scrum approach to software development is a simple process and some will say that it‘s complex. Our opinion is that even with all its five ceremonies (Grooming, Planning, Standups, Retrospectives, Demo) it‘s a lightweight process that allows for healthy team disciplines. However, tooling is an integral part of the process and can make your overall process simple or complex. There was a prior experience in the team working with Jira and the opinion was that it was a heavy/complex tool. Another big downside of Jira was that it stood distinct, outside Github. Engineers would spend most of their time on a day-to-day basis on Github. We wanted a tool that would integrate well with Github and facilitate an easy Agile process. We stumbled upon Zenhub and loved that it lived as a layer over Github. It was responsive and quite lightweight. It also allowed to easily add estimates, epics, and sprint info onto Github issues. Overall, Zenhub introduced minimal friction to our process. Below is a screenshot of our board at the moment.

In our daily standups, we open this board and go around the room answering the questions on what is currently being worked on and how it‘s going. This keeps the team aware of progress and also reveals opportunities to leverage in terms of code and design. During our sprint grooming meetings that we hold once a week, we go through items that are in the “To Be Groomed” pipeline. We then give as much definition/acceptance criteria needed for an engineer to consider building and consider it as done. We also collaborate on estimating its complexity (based on Fibonacci values, typically from 1 to 21). Anyone on the team is welcome to add tickets to this pipeline anytime during the sprint. Once a ticket is groomed properly and estimated, it gets moved to the “Sprint Backlog” pipeline. And during sprint planning, we state a goal for the sprint, double-check on priority order and then assign the first few tickets to engineers. As the sprint progresses and tickets are completed, engineers self assigns tickets that are left unassigned and tackle them. During sprint demo, we review interesting parts of code or UI and during sprint retro, we reflect on what went well and what did not go well and create action items so that we can further improve working as a team.

Adopting Agile Scrum and adding these ceremonies to our process had a lot of benefits. Primarily, there was a decoupling of the “who” and “when” conversations of a ticket (which happened at sprint planning) and the “how” conversations (which happened at spring grooming). And as a result, our definition of tickets and acceptance criteria had a high quality. It was evident because we started having fewer “realignment” and “rearchitecture” conversations. A healthy discipline that organically happened, was that engineers would self-set daily targets loosely to complete (in terms of complexity). Our predicted delivery dates became exponentially more accurate. Also, the graphs in Zenhub gave us a good visual indicator of our consistency in productivity and if we were successful in our planning. All to say, go ahead and adopt Agile and pick a great tool like Zenhub to facilitate it. (By the way, this is not a Zenhub sponsored post!)