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.

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.