Skip to main content

Author: Lev Barbalat

Scrum sundae

Written by Lev Barbalat on . Posted in Articles. 4 Comments on Scrum sundae

Around a year ago we decided to adopt Scrum as our methodology for development management.

We were agile even before this process, by knowing to adjust our work plan according to business needs or customer demands often, however, we missed the ability to manage development teams efficiently. After certain consultation, we decided to adopt Scrum as a methodology. The process was gradual. Firstly, only one team moved to use scrum, then after doing a retrospective and understanding the pros and cons, we added an additional team and then moved all teams to scrum. When we started, the decision was taken to adopt “vanilla scrum” as the most correct way. However, the reality differs from “sterile” environment that is usually described by the book or Agile coach. In this article, I would like to share my thoughts on “scrum flavors” i.e. cases when the standard scrum is not enough and variation to the procedures should take place. Application of correct flavor will assist you to create a winning combination for your needs

Scrum is not applicable to the initial phase of the project such as discovery

When starting the project and requirements are still gathered, it may be counterproductive to enforce scrum methodology on the team members. In case that you would like to develop something that will fit existing ecosystem, the requirements are still are not finalized, the technology for the project may need validation and due diligence, it makes sense to approach such objectives as a traditional project. Once things are clarified you may build the backlog and apply scrum methodology.

Let’s take as an example e-commerce platform for small businesses, that allows to the online merchant offer e-commerce site for selling goods, back office for managing orders, shipping, payments, and inventory. The business stakeholders raised the requirement to redesign the platform by adopting a new user model, introduce new functionality and scale out the platform to support online merchant who has multiple brands, warehouses, and shipping facilities. Let’s say that you have even the development team ready for the task. There is a very high chance that during the regular sprint preparation that takes week or two there will not be enough time to understand the solution and define implications on the systems that are impacted and needs modification. In order to use time and resources in an efficient manner, it’s worth to assign sprint or two for discovery and design phase during which the architecture of the system will be defined, user stories will be written, and new technology will be explored. During this period product owner will have enough time to prepare the backlog. The development team may still implement scrum procedures, but most tasks will be research of the new technology or existing state of the system, the definition of the architecture and building infrastructure components

Scrum is hardly applicable when new technology is expected to be introduced

As part of the new project, it may be a good idea to add the new technology of stack of the company such as queue platform, new database engine or framework for certain programming language. Usually, the new project serves as legitimation for such technology upgrade. Such a procedure usually requires effort from multiple teams:

Advertisement
[widget id=”custom_html-68″]

Developers to write the working code using the new technology, DevOps team to deploy the solution to environments that are being used and updating CI/CD procedures, IT team to add the technology to maintenance cycle, NOC for monitoring purposes. Scrum process usually does not cover the activities mentioned above as its major focus to deliver the software that answers business needs.

You may wish to add team members from departments that are responsible to services such as DevOps or IT to scrum procedures such as sprint planning and daily scrum in order to get their commitment to the tasks, however, it’s neither not natural for the scrum process, nor for that team members. During the introduction of the technology, multiple impediments may arise and according to scrum it’s product owner responsibility to solve them, however, the introduction of such technology is rarely agenda of the product owner who wants to deliver functionality to his stakeholder. Introduction of a project manager who will be responsible for this activity and it will be his primary objective may deliver better results

An additional aspect that is worth considering is the timeframe that is required for technology introduction, it usually longer than one or two week period that sprint takes and it doesn’t necessarily make sense to connect technology introduction process with scrum delivery. It’s usually preferable to set up new technology before adding tasks related to the implementation of business delivery as a part of the scrum process

Scrum should handle dependencies on different services that are provided by additional providers in the organization or outside it

For large companies that have more than one scrum team coordination between scrum teams is required. Usually, this process is called SOS (scrum of scrums). It allows synchronization of the scrum teams. In practice when a certain project requires the collaboration of a few teams, planning and monitoring activities that are common for them is required. It’s worth to define dependencies between teams and order of the execution in order to minimize the possible effect on the lack of delivery of one team to another. If we take an example e-commerce solution described above the infrastructure team that handles user management infrastructure will need to deliver their part prior than application team which develops back office and uses infrastructure to implement business logic

In case that dependency exists that is related to an external provider that you don’t have the ability to influence the situation becomes even more complicated, scrum considers such dependency as an impediment and need to manage it is outside of the standard scrum framework

Conclusion

Implementation of the scrum in the organization may have its benefits such as agile approach, better customer satisfaction, transparency for management and team members. However, it’s important to take into consideration that scrum is not a solution for all processes and it doesn’t cover all additional activities that exist during the development of the projects such as planning and design of the project or introduction of the new technologies. It’s also crucial to understand that complex projects that have multiple teams involved will still need a dedicated project manager that will perform activities such as building Gannt, reviewing dependencies, maintaining collaboration between different teams

I would like to wish you to enjoy the correct proportion of each scrum flavor that will form perfect “scrum sundae”

Scrum Flavored Project Management

Written by Lev Barbalat on . Posted in Articles. 3 Comments on Scrum Flavored Project Management

We had a very important project a year ago. Our sales team onboarded the biggest customer in its industry, and we needed to deliver customization of our product to address customer requirements.

We had three months to do quite a big piece of work; additional complication was the fact that our development teams are located in two different offices, and their collaboration was required for successful project delivery. To deliver fast, we decided to adopt parts of scrum that seemed reasonable to us and to drop what we didn’t want to do.

There were few reasons why we didn’t implement full scrum process. Firstly, we had a lot of team members who were familiar with the agile approach. However, we never practiced it. The full implementation of scrum is the risky and time-consuming process and to add it to an already important project was not a very constructive idea. The second reason was the fact that implementing all “scrum ceremonies” requires significant commitment from the team members. We thought it would be easier to get commitment from the management of the project and only then to extend to the whole team.

So, we decided to perform definitions that appear below to achieve projects goals.

Sprints definition

We took the features that should be developed in the scope of the project and divided them to the “sprints”. We divided sprints based on functionality that should be delivered and timeframes that should be achieved. Such approaches gave us following benefits:

  • The sprint plan is clear to everybody on the team
  • The sprint is defined based on the estimation of development manager
  • The scope of the sprint could not be modified by the team. The exception to this rule was only project manager with development manager could add something (on very rare occasions).

From sprint to sprint we got better T estimations, we understood that sprints should be equal length, so we may consistently define what scope is.

Advertisement
[widget id=”custom_html-68″]

Roles

We did not distinguish between scrum master and product owner. Basically, our approach was that was that project manager did both roles. Not the optimal approach as it applies a lot of pressure and has conflict of interests, however, it allows very efficient decisions. It may be used in the beginning, but I don’t recommend it as long-term approach

Ceremonies

Scrum usually speaks about four ceremonies. Sprint planning, Daily Scrum, Sprint Review and Sprint retrospective. For each of them, there is defined purpose and the way to conduct such ceremony. In a nutshell, they enhance communication between the team, scrum master, and product owner. However, when you are trying to introduce all four ceremonies, you may deal with skepticism and lack of the understanding of your colleagues. The gradual introduction of the ceremonies may make transition smother

“Sprint planning” was done by the project manager and development manager. We didn’t measure the capacity of the team or assigned availability of resources. The development manager provided high-level estimations and together with project manager they built the plan for upcoming sprints. The important approach here was to leave approximately 50% of sprint for unexpected issues and bug fixing. It’s a very high effort allocation in the beginning, however as the project progresses you may adjust the effort estimation left for unexpected

“Daily Scrum.” This was the most important ceremony for us. If you need to select only one out four – make sure that you do it. The meeting allowed us to synchronize everybody, identify gaps in workplan or understand and monitor the advancement of the project on the daily base. It helped us to establish communication and commitment of the team members. Everybody has seen the full picture and was part of it

“Sprint review” and “Sprint retrospective.” We unified these ceremonies to one. We updated the team on what was delivered, what remained to be done on the next sprint and how should we improve the process. From my experience, this meeting opened the stage to all team members to express their thoughts and allowed managers to see what happened and how the project development may be improved

Tools

One of the key factors to the success of the project was collaboration and transparency. We used an online tool for managing user stories. In our project Atlassian Jira was used. However, any relevant tool may be utilized. Please consider the following attributes of the tool before selecting one

  1. An online resource that is single and always updated “source of truth.” It’s critically important that the resource is shared, be online and that multiple versions of truth will not exist. We felt improvement when we dropped multiple excel files that lost their actuality few days after creation
  2. Authorization. It is important to know who may update the list and make sure that new tasks do not suddenly appear in the sprint (because one of the team members decided that it will be cool to add it)/
  3. Rules of the use of the tool. It may seem obvious, however even if everybody knows to use the tool, the rules of usage should be understood and agreed upon by team members. It’s better to keep them simple and clear to avoid unnecessary confusion. The purpose of the tool is to serve team members and not vice versa

Conclusion

We successfully delivered the project, and agile approach was the key factor. Application of the “agile flavor” to project management gave the project team and company management understanding how the agile processes works, the benefits and the risks. By doing relatively small changes in our procedures, we achieved better visibility and collaboration during the project. The lack of definition of the Scrum roles helped us save time on proper explanation of the process, definition of the new responsibility and prevented the confusion by team members. In general, such experience proved the advantage of Scrum usage for development and caused migration of the whole company to such approach after this project.