A team growing with Agile Scrum
QueryPie Development #3: Development Process Introduction
한국어: https://medium.com/p/cfaa4b71c263/
There are no silver bullets in the world. Nevertheless, humans are vulnerable to all kinds of desires and are always looking for a silver bullet.
When the Agile Manifesto was announced in 2001, Agile was a candidate for being a silver bullet in the software development industry. Seventeen years later, Agile is no longer the silver bullet we’ve been looking for. But it has become a practical and great tool to grow your team and drive your business to success.
I started my career as a web developer in 2004. Since 2011, I have been a senior developer working as the lead in many development teams. After I became a team leader, I was constantly concerned about how I could achieve all the goals in my development projects: goals such as scheduling, conformity, quality, and team growth.
As a result of that concern, I found Agile.
So this Developer’s Log will outline my experience with Agile Development.
Agile: Continued improvement through compromise
Ideally, a software development approach would be to develop the completed software on a timely basis formed on complete planning and forecasting. This is known as plan driven development, and the software is developed according to a process called the Waterfall model. In order for this to succeed, all of the ideal conditions must be met. But in reality, it’s hard to predict what’s going to happen in the future and it’s inevitable that unexpected changes will occur. Furthermore, the software development process is fluid, open and unpredictable.
So, what is Agile?
Agile is a compromise. Agile assumes real-world conditions instead of perfect and ideal ones. It accommodates constant change and leverages limited resources to improve the project. This way the developing team can consider the best compromise and implement it together.
There are many kinds of Agile development processes. Scrum, Kanban, and Extreme Programming (XP) are just a few. Each has different features and a different scope, but can be used in combination with each other.
A new Team Leader’s trial and error with the first Agile Scrum
In 2011, I became a team leader of my own group of developers and began thinking about how a team was supposed to work. Studying software development methodologies sparked an interest in Agile. I was most impressed when I read the book Scrum and XP from the Trenches.
The iteration Scrum uses is ideal and appealing. The team manages a task as a backlog, re-planning and solving it based on a short iterative development cycle called Sprint, and creating continuous development and improvement.
However, I couldn’t immediately introduce Scrum’s methodology to my team because of the nature of my department at the time. We were in the middle of correcting many issues and had to keep developing software so there was no space for a new method. When I began to lightly incorporate Scrum into our workflow, it unsurprisingly failed. I found out the difficult way that to work with Scrum, the team and the customer need to be prepared… which is not an easy task.
So my team went back to the way we worked before Scrum.
Our old method looked something like this:
- receive the request on phone or email
- write the request on a post-it note
- put the post-it note on the wall
- operator grabs post-it note and takes it back to his desk
- operator resolves the request
- resolved request is moved to the team’s common diary
I’m sure you won’t be surprised to hear that my team’s monitors were constantly full of post-it notes!
Kanban was simple and easy, but it fell 2% short of excellence
In 2013 I changed jobs and got another chance to consider the workflow of my team. Around that time, the book Kanban and Scrum: making the most of both was published. I learned a lot about Kanban by studying this book.
Kanban’s method is a little bit simpler. It requires creating a few separate columns, labeling them accordingly (i.e. To Do, Doing, Done), and adding tasks on cards/post-it notes to the columns. These tasks then move from column to column depending on their status. It’s a pretty easy method to use, and its a great way to visualize the work process.
This method might seem like an obvious one, but Kanban adds a few rules to the process. Some of Kanban’s basic rules are splitting projects into smaller tasks, prioritizing them, and limiting the number of simultaneous operations. If you’re curious about the Kanban method, please refer to the Kanban and Scrum book for more information.
Managing a team’s tasks using the Kanban method is very straightforward. Anyone can understand the process and follow it to maximize productivity, and the benefits it provided for my team were great.
But I felt very guilty about the failure of my first Scrum. I wanted to work in a more organized fashion with the Scrum method.
A return to Agile Scrum with a new start-up:
In 2015 when I joined a start-up, I was in a situation where I had to lead a completely new development organization. I realized this was the perfect time to reintroduce Agile Scrum into my workflow.
When the idea of the first product was decided, the development work was split up in the best possible segments and compiled in detail to fill the backlog. We set our Sprint for a 2-week cycle. I wasn’t confident about spending a month planning for that period. A cycle a week felt too short. The 2-week cycle included a 1-week break and if the progress was too slow, we used the weekend to make up for it.
The first few months, without the aid of any software tools, we used a whiteboard and post-its for Sprints. Trello and Jira were popular at the time but the Scrum culture was still new and unfamiliar to everyone at my company, including me. So we couldn’t afford the time to learn a new method, which is why we relied solely on our whiteboard and post-its.
Scrum’s Velocity: Continuous Performance improvement
The most important concept in Scrum is concentration. This approach starts with a reasonable assumption that there is only a limited amount of time for one person to actually focus on a single task. So it’s best to set fixed hours of work for one day and manage the percentage of work done on that day. For this very purpose, we call the segmented work unit a Story and assign a point value in the story card called a story point.
⭐️ Story points are used to measure the overall effort needed to develop a piece of work. If a developer concentrates 100% for one hour on a task, that is one point. When scoring Story points, we need to be careful not to overestimate or underestimate. Finding the exact scoring for the size of the task is essential. Based on the story points we set for the specific Sprint, we can calculate the velocity after factoring in the time needed for one Sprint.
Velocity = Story points / Actual time taken:
For example, if 10 developers work on story points for 10 days, eight hours a day, where the stories are ranked at 528 points then the velocity would be: 528 points / (10 people x 10 days x 8 hours ) = 66%
Velocity is calculated by summing up all personnel participating in the Scrum. Calculating velocity by individuals may unnecessarily bring team members to compete against each other, which in the long run can be harmful.
Interestingly, the velocity objectives for the following Sprint are calculated based on the average of the velocity achieved in the previous couple of Sprints. Each Sprint always sets a slightly higher target than the average of the prior result, creating a constantly updated and challenging goal. So once a team achieves their goal, there is a high sense of achievement. If they fail, then the option to set an easier goal because of the lowered average value for the next Sprint. This focus management allows the Scrum team to continually improve the accuracy and performance of their plan.
Scrum-based Sprint Progression:
The Scrum team shares a common challenging goal, proceeds with the project, and holds a short meeting every day. This is called Daily Scrum Meeting, or Daily Stand-up Meeting because standing is recommended to keep meetings as short as possible. In these sessions, the Scrum members share their progress and maintain the level of pressure of succeeding in the team.
After each sprint, time for reflection and planning is needed. Improving team ties by comparing goals and performances, calculating concentration levels, and handing out praises as well as consolation through reflection is so important. You should never blame anyone. This is a team effort.
At the planning meeting for the next Sprint, based on progress and experience, you can update the contents of the story cards in the backlog and fine-tune story values. Then set the concentration target for the next Sprint, agree on the scope and schedule of the Sprint and start again (see the books above for more details on how to do this).
I’ve gained a lot of experience running my own Scrum team for two years. Scrum focused my team on the task, and naturally led to higher performance and accurate scheduling. But most important of all, the members of the team became very confident and able to build a deep bond with each other. We grew rapidly as a team.
We tried out several tools to manage our process, and in the end decided on the platform Jira. I personally think Jira is the most powerful and convenient tool for both Kanban and Scrum methods.
The Scrum-type project board in Jira provides backlog management features and a Scrum board with a variety of reports. Measurement tools such as Sprint reports, Burn down charts, Concentration charts, and Version reports helped us manage our performance.
Festa, the event platform developed through successful Scrum:
In December of 2017, I joined the development team of a South Korean event sales platform called Festa. At the time, Festa was preparing for its first product launch after completing proof of concept (POC). The product itself was a convenient website where users could purchase tickets for an event through an easy payment procedure.
Because it was a new team, we needed to talk about our workflow and process. I suggested Scrum. After the proposal was accepted, we decided on the first Minimum Viable Product (MVP) and set up a backlog.
The focus was on the product launch schedule. The release date of the product was already determined, so I had to complete the project on a fixed schedule. The period given to me was a little more than a month.
Could the newly-formed Festa team finish and release the product on time?
Since our deadline was about a month, we decided on a 1-week Sprint cycle. By faithfully managing the backlog while repeating the Sprint cycle, we were able to very accurately predict the time it would take to prepare for our product’s launch.
Using a special feature in Jira, we assigned version numbers to story cards and implemented version reports. With this feature, we continuously identified the expected release date and aggressively adjusted the development scope to achieve our goals.
The Festa team consistently performed well with Scrum and was able to successfully release the product at the target date. If you look at the above version report, you can see that our story score increased with a fixed slope. This is evidence that the team has always developed the product in a timely manner with a steady performance.
New Scrum Challenge: QueryPie Development in CHEQUER
In 2018 I began working for CHEQUER, a new start-up in South Korea that develops a powerful IDE tool called SQLGate. At first, I merely focused on finding a place for myself in the new environment, and once I was comfortable with my new position I began focusing on producing results. After some adjustment, I began thinking about how to better the performance of my team again. That’s when I suggested Scrum to my team.
What do you think is the most important factor when introducing an Agile Scrum process? I believe it’s the reputation for people who are involved in the adoption of the process. Trust is the basis for acceptance and a willingness to try something new. After being a vital member of CHEQUER for more than half a year, I successfully gained the trust of my management and team members. Thanks to everyone’s efforts, we created a reliable Scrum team.
CHEQUER is a flourishing start-up company that is quickly securing active and talented crew members through the efforts of highly dedicated executives. I was inspired by their enthusiasm to succeed and their willingness to take on new challenges. So it’s my greatest pleasure to create a Scrum process that will boost the company’s productivity and auspiciously grow our business.
📌 CHEQUER’s current Scrum challenge is QueryPie, which you can learn more about in this article.
I’ve already had a lot of experience managing Scrums through Jira, so I’ve been able to lead my team in executing my plan for our first Sprint. Our initial concentration goal was set to 64% based on experience (70% is the ideal goal in my mind). The number of crew members was four, and the first Sprint was only eight days. Based on these factors the goal to achieve would be: 4 people x 8 days x 8 hours a day x 64% Concentration = 164 Story points.
In the above image, you can see how I organized the backlog and set the target for Version 1.0.0. The target date was March 1st. But when I saw the version report a few days after starting the Sprint, the expected completion date was predicted to be March 5. It took me a few seconds to realize I hadn’t factored in the weekend. Ooops! Saturday and Sunday are important rest days!
In this report, I added that on March 2nd and 3rd we won’t be working. The estimated completion date has been increased by the number of weekends, changing the final day to March 11. But at this rate we would be 10 days behind the target date, so we needed to adjust. With only a few days of Sprints, talented crew members of CHEQUER quickly adapted to the Scrum method and were able to fine-tune story cards and story scores that were initially set incorrectly.
The first Sprint challenge ended in 8 days. Our Sprint report shows that our crew did very well in the end. Due to their hard work, the expected completion date has been comfortably adjusted to February 22. The difference between the optimistic and pessimistic completion date estimates on the graph has also narrowed. I expect we’ll get a version report with very high accuracy once we’ve finished two more Sprints.
It was only an 8 day short sprint, but the CHEQUER crew learned how to work systematically and efficiently. By succeeding in the first Sprint, we gained confidence and strengthened the bond between each other. We grew together throughout the Scrum method, and we’re going to grow even further through the Sprints that will follow.
Agile Scrum Journey Wrap-up:
A lot of feedback came out of the Agile Scrum process. Some thought that it would be good to track the crew’s progress. But others believed it would cause unnecessary competition and negative stigma, so we should approach it carefully.
Working in a team shouldn’t involve competition. We must build a bond and move on steadily toward a common goal. If any crew members are struggling, we should help them improve the velocity of the Scrum process and grow together.
I hope my long story will help someone out there. Give Scrum a chance, and give strength and leadership to your team. If you keep working together, know that success will be right around the corner.
