Not just a Coder anymore
Whole world is embracing Agile methodologies to improve quality, bring transparency and speed up the process. Agile Manifesto emphasises the importance of self-organising teams. It focusses on teams that are cross-functional and include team members with all the capacities and competencies required to accomplish the project work.
The Scrum framework acknowledges three specific roles i.e., Product Owner (PO), Scrum Master (SM) and Development Team (Dev.), with distinct responsibilities. Software engineers spend only half of their day or even less than that on coding related activities. Another half of the day is spent on collaborative activities. Contributions of a software engineering team can be classified into three broad areas: Project, Product and Process.
Let’s look at contributions to the project by Scrum team, grouped by roles.
When you’re in a growing team, which does not have a dedicated Scrum master or a Product owner, things start to get interesting. As you end up managing more than 80 percent tasks of all the roles combined, you begin to appreciate the importance of the Scrum Model.
Let’s see how Dev. teams can handle different processes when they don’t have dedicated SM or PO, but still want follow agile methodology.
- Define & Prioritize tasks: No big planning is conducted up-front. A general road map of product is set-up in the beginning. Research is done by managers / business analysts and product requirements are handed over to the Dev. team. As the project progresses, more work is continuously planned and handed over to the Dev. team. It is very important for Dev. team to not accept each and every task thrown at them and start working on it immediately. A better idea is to put everything in backlog and only start working on a task when all the pre-requisites of that task are done and it has a clear Definition of Done.
- Estimation of Tasks: An initial estimate of delivery is given by Dev. team. In case of improper estimation, deadline dates keep extending. Initial estimation is quite accurate in many cases, but as the implementation phase starts, requirements change, more corner cases arise, more research is carried out and a lot of rework happens. Estimation of a task should always include the testing, debugging, feedback and some buffer time for rework.
- Coordination: Dev. team might need to coordinate with Business Analysts, Marketing Team and Design team to discuss their requirements related to product. As the requirements keep increasing, more refinement of backlog is required. Certain things can hamper the productivity due to bad coordination, for example:
- Developing code without Design artifacts
- Writing a DB schema before having actual data format
- Creating a backend API before knowing how frontend will process it
- Impediment Removal: As the project gains momentum, impediments start to increase.
- Lack of Devices (laptop/mobile/servers)
- Lack of knowledge (new library/framework)
- Unclear tasks definition.
- Working on multiple tasks in parallel.
It is important that impediments are removed continuously so that productivity of team can be maintained. As impediments pile up, it can impact the velocity of the team and create more frustration in developers.
Daily Standup Meeting and Retrospective Meetings are the best way to identify and track impediments in the process.
- Balance between Product / Engineering: It’s an undeniable fact that developers are inclined to spend time on refactoring code, improving architecture, decreasing build times and increasing performance of applications. These are some activities which gives developers immense satisfaction and pleasure. However it’s important to strike balance between the product and engineering aspect of the project. Delivery of features should not be delayed due to engineering hurdles. Initial research on project structure, frameworks, 3rd party libraries, cloud infrastructure setup, caching mechanisms, messaging queues, databases, git workflow, CI/CD tools etc. should be done thoroughly so that you don’t need to handle too many non-functional requirements in the later phase of the project.
One important thing I have realised after working with multiple organisations is that Scrum is not a magic wand which can fix all the productivity issues and deliver the best business growth in shortest time. Team orientation, team maturity and coordination, as well as division of work, are vital factors that can make or break any project’s success. In high performance teams, the tasks demand that members work together as a unit to reach the goal. Every organisation has to come up with their own ways of becoming more mature and productive.
If you want to become a better software engineer, coding is not the only skill you need. Collaboration plays a central role in the daily activities of software engineers, with estimates as high as 45% of work time. With the rise of remote working conditions, being able to communicate clearly is going to be a significant weapon in your arsenal.
#agile #collaboration #communication #scrum