At Shinetech Software, we work following the Agile philosophy and several workflows derived from Agile. Based on Agile practices, primarily Scrum, we separate our work into development sprints. A development sprint is a process broken down into several distinctive parts. How long a development sprint lasts depends mainly on the agreement between the development team and the customer, but in Shinetech, they usually last between five and ten days – 1 or 2 weeks. The team and the customer also agree on the scope – how much work we can practically finish in a set amount of time.
The development sprint in segments
As with the design sprint, so does the development sprint have its segments with a week-by-week work breakdown. In a team, project managers are usually the ones who break down work and goals. However, Shinetech developers, because they deeply understand how this process works, can independently discuss the objectives, break down work into smaller segments, and set up actionable goals.
Next, we have a day-by-day work breakdown. Here, we usually follow a specific direction – we start the week by meeting with the team and the customer to evaluate the previous week’s work, discuss this week’s goals, and align our efforts. This is the sprint planning meeting; we use it to prioritize the tasks and determine the most crucial task that requires our focus. Suppose the software we are developing has numerous critical parts, and we need to actively collaborate with a customer’s in-house team. In that case, we can also implement daily standup meetings to check our course and divert it if necessary.
Collaboration first
The development sprint, apart from being a process that facilitates our work, also helps us to collaborate and brainstorm to solve complex issues and problems. Besides, it pushes us to innovate and not contemplate too much over details but focus on the big picture instead.
Our free trial offer is based on a one-week development sprint. The customer works with one developer for a week during the free trial. Free trial sprints are practices that have all the fundamentals of a regular Agile sprint simplified to present core abilities and get development work done.
The team getting ready to start the sprint
Day-by-day questions during the first development sprint
Day 1 – project start
When we start a project, we first have a kickoff meeting where we confirm the details with the customer and discuss what we will work on during the week. It is beneficial that before starting, we have already discussed the ideas, goals, and requirements during exploratory calls so that we can break down the work into manageable parts.
The questions that usually pop up during the kickoff meeting and Day 1 are:
- What questions do we need answered during this development sprint?
- What is the end goal? What do you see this project accomplish in the long term?
- How and where does this project fit in the customer’s business? How is it relevant for them?
- What are the potential causes that can make this project fail? How can the project go wrong? What are some industry pitfalls that we need to pay attention to?
- What are the assumptions we need to test and research?
- Do we have predefined requirements the customer needs implemented by the end of the sprint?
The questions are primarily about goals, industry positioning, and business logic that helps Shinetech developers understand your needs better and gain the necessary awareness of potential pitfalls. Of course, the developers will ask more questions about the project once they understand the customer’s idea.
Day 2 – internal discussions
Day 2 is exciting in the development sprint. During Day 1, we already established a common ground upon which we will develop the software our customer needs. However, not all questions have been answered, and now that the development team has had a day to dive into the development work, Day 2 in the sprint is essential for two reasons, because we can:
- confirm with everybody whether the technology we are planning to use can actually achieve what the customer wanted
- consider how the customer can grow and maintain their infrastructure based on the confirmed technology
For these reasons, we arrange internal discussions to analyze what to do next. We understand the trust that customers gave us and the responsibility we bear for adapting the software to suit their business needs, so during Day 2, we mainly talk about:
- Can the technology we agreed on achieve the customer’s goal?
- What should the customer consider when using this specific technology?
- What are the tech limitations we need to point out and pay attention to?
- Does this technology complement the customer’s business?
Answering these questions allows us to put the customer’s project and business in perspective and to observe it from a technological viewpoint. These discussions usually take place in the morning before we begin to work. If we find something critical, we notify the customer and ask to schedule a meeting immediately on Day 2 or the next day. If we don’t find anything critical, we proceed to develop.
Day 3 – mid-week check-up
On Day 3, we have a quick check-up on our progress. Since this is the project’s first development sprint, it is essential to ask the following questions:
- How much progress are we making?
- Do we have all the important information? If not, when can we get it?
- Have we uncovered some problems with the technology that might harm the customer in the future? Compatibility issues, end-of-life support, or known bugs are some of the things we discuss here.
- If needed, can we provide more help to the customer later in the form of maintenance and support?
These questions promote communication about issues that the developers and the customer might encounter in the future, so being aware of them at the beginning can help us resolve them in later stages.
Day 4 – evaluate the sprint
During Day 4, we usually reflect on the previous days and think about what we have achieved so far. The team has been working since Day 1, so it is important for us to discuss how the development sprint is progressing. We observe the overall team morale, the quality of the software they have been developing, and the sprint achievements. We discuss the following:
- Has the sprint goal been too optimistic or too small?
- Can we reiterate the process in the next sprint?
- What can we improve in terms of our workflow to be more effective?
These reflections will also help us prepare for the learnings for the following day.
Day 5 – demo and lessons learned
Day 5 is crucial in a sprint because we get to demonstrate what we have done so far. This weekly demonstration is especially important in the first development sprint. We can present and discuss our work for the week, ask for more information and clarification, and introduce what we will be working on next.
Some of the questions that usually appear during the Day 5 demo and lessons learned are:
- What were the lessons we learned?
- Did we achieve the goal?
- Did the development team suffer any crunch time? If yes, how can we prevent it for the upcoming work?
- Could the dev team have done more?
- Is the customer content with the work we produced?
The Day 5 conversations are also essential to understanding the customer’s expectations and realigning our efforts for the following sprint.
Conclusion
Shinetech development sprints are easy to modify and adapt to the customer’s needs. They present great situations where our developers can learn a lot about the customer, and the customer can see our expertise at work. The sprint has a form and functions based on the goals and milestones, with demo sessions at the end. The feasibility of every sprint is adapted according to the learnings from the previous period, expertise, and experience. We transfer what we practice during the free trial into our regular work with customers, and we get to see if collaboration suits the team and the customer.