Doing agile right in project management

Softray Solutions
7 min readNov 24, 2020

Written by Selma Ganic, Project Manager at Softray Solutions

Selma Ganic, Softray’s Project Manager, provides a thorough insight into the process of turning your idea into a digital reality. After covering the most important processes within the Discovery Phase, Selma is guiding you through a detailed Implementation Phase and reveals the Softray’s dedication to details.

Well planned is half done

Projects, especially software development projects, can be a challenge from start to finish. But if the Discovery Phase has been conducted correctly, the risks of failure are minimized since all the shortages are predictable and manageable within the regular project flow.

Our previous article covered the Discovery Phase processes, let us now guide you through the process of turning your idea into digital reality, once the project requirements and costs were discussed and signed the project begins.

We are doing agile right

Softray Solutions utilizes agile methodology. Agile is a process by which a team can manage a project by breaking it up into several stages and includes constant collaboration between stakeholders and Softray teams. The two methods Kanban and Scrum are the most frequently used, depending on project characteristics.

For a project where tasks are flexible and changing and/or the project length is short (up to three months) Kanban is preferred due to the more flexible story scopes and less time spent on planning.

As for a project that has a more determined scope and lasts a longer period, the Scrum methodology with two-week sprints is preferred. Scrum offers the fixed shorter periods (sprints) with a defined set of functionalities. The result is a better project timeline overview. Meanwhile, Kanban focuses on incremental development, eliminating the needs for meetings.

No matter the method, due to the agile methodology used, the project scope is divided into epics. Epics represent a module in the system. Epics are further divided into features. Features are broken down into user stories. The three definition levels offer the possibility to track project progress on three different levels based on preference and need.

Epics and Features are usually defined with the project scope, however, if the need arises new ones can be added, removed, or changed. User stories however are a lot more adaptive and subject to change up the point when it is either selected for development in Kanban or in sprints. Sometimes it is also possible to adapt it during that period too, however it is not advisable as precious time can be lost. As an alternative, development can be suspended, the story removed from the sprint/work and another one selected instead.

The development process begins with sprint 0 (on Kanban that part is simply called Project Setup task). During that time, the coding environment is set up and prepared. The necessary frameworks and tools are defined and connected. Once it is ready, the code is committed to a code repository. Softray usually uses Bitbucket and Azure DevOps. We usually recommend using Azure DevOps as Azure has a wide coverage of functionality for task management and workflow. The tools can either be in your ownership or in ours, based on your preference.

Also, at this point, we make agreements with you on the required environments. We usually recommend at least two environments, a development one that serves as a development playground and a QA environment as a stable environment for testing and access. As the project progresses to a third environment, the staging environment should also be set up to be used as a User Acceptance Testing Environment and finally, the production environment where the product will live.

While the development preparation is underway, the project backlog is also being prepared by the project manager. The project backlog includes all stories for the project. The items from the backlog are assigned to development or sprint based on priority order. The priority order is defined based on the required order from the development standpoint and product owner input. You can either assign a product owner from your own team, or you can also have a product owner from the Softray Solutions team.

Once the development repository, environments and backlog are ready, a sprint planning meeting is set. The sprint planning meeting is a recurring meeting before every development cycle. Scrum includes the planning meeting every two weeks, about two days before the beginning of the next sprint.

During the planning meeting, stories are selected for development and a developer from the team is assigned. Firstly, the description and acceptance criteria are clarified to all participants in order to make sure all team members understand the big picture. Once confirmed, the developers are playing “story points” poker. The story point is loosely connected to a day and signifies how long, and complex will it be to implement the story. The story points are assigned as Fibonacci numbers: 1,2,3,5,8,13. It seldom happens that a story value is 8 or 13 points. If the poker play indicates that amount of complexity, the project manager will work with the developers and break down the story if possible. That is being done for two reasons: the first one is to avoid complexity and get simplified tasks, the second one makes sure a story can fit into a sprint. If it turns out that it cannot be broken down, that story gets higher priority to minimize the risks and impact of that task. The estimate is compared to the original estimate and discussed to identify the difference between the initial understanding and the current one. After the meeting, each of the developers breaks down the story into individual tasks with a time estimate which is then added up to a story estimate.

The planned story points for the sprint/week are planned in accordance with holidays, annual leaves, and capacity of each team member. If there are non-working days, a developer, by pure math, can cover 10 story points. However, most successful practices imply that the optimum would be to plan 7 or 8 maximum, in order to make sure all developers have free time for unexpected issues that might arise.

For Kanban, the meetings are not part of the process. Instead, the developer receives the next task as soon as they finish the previous one. When they finalize it, they assign the story points and tasks for the story on the same principle as they do for Scrum. If needed, they also perform the breakdown of multiple stories with the project manager.

On the last day of the sprint, a sprint retrospective takes place where all team members vocalize anything that went wrong during the sprint, such as risks identified or changes, they want to implement. During the next sprint, all risks are considered, and changes implemented in order to make sure the team contributes to higher performance. Once the sprint retrospective is done, the planning session continues for the upcoming sprint/period.

The progress is tracked through the mentioned tools, JIRA, or Azure. The team has regular meetings every day, which are called the stand-ups, where each team member states what they have been working on during the previous day, what they intend to do, and they place issues if there are any. The progress report can be delivered to you in any preferred way and as often as needed. The usual process includes a one-week progress report either by email or call, but again, any of this can be arranged and agreed upon directly with your project manager, per your preferences.

We continuously deliver

Here in Softray, we strongly believe that continuous delivery is the best approach. By implying that, everyone is made sure that the project is on the right track. So, after two to three sprints, the project manager arranges a demo session to present you with everything that has been done. That demo session then takes place every two weeks, one week after the next sprint starts and the previous sprint has been tested. The end of the delivery is taking place once all features are delivered to the production or staging environment. After that, maintenance and support can be agreed upon.

We are with you for the long run

Each project has different needs and is featured by the client’s unique approach. This article’s purpose was to provide you with in-depth knowledge of Softray’s processes during the Implementation Phase. However, do not be discouraged if any part of the described processes is not reliable to you. We are agile, adaptive, and can always make modifications suitable to your needs. The same applies to the team structure, developers, QA, and Project Managers.

We know work doesn’t stop with the first live deployment, but on the contrary, it’s just the beginning of the story. Therefore, you can rely on us after the project was delivered. We can bring many changes to the initial project, implement customer feedback, or develop new features, functionalities and apps.

Softray Solutions is an enterprise software development company with extensive business expertise in effective project implementations. If you think we can help you in turning your idea into digital reality, contact us. We have the right team for your project implementation.

If you enjoyed reading this, click on the clap button so others can find this post.

--

--