Definition for agility
At Nearshored.com we consider that the agile software development projects is built on ability to transform and alter direction, but we also identify that true agility is actually extremely diffucult to obtain.
Why is it difficult to achieve agility?
Agility is very abstract subject and its easy for one to assume that agile project management model would solve most of the challenges experienced, when operating with traditional waterfall model.
But actually agile in this context only provides framework for the dev process and it does not sort out common operative challenges. When teams switch to agile project frameworks, e.g. to Scrum, there are new challenges, such as:
- Team is unable to adopt new model, due to inability to let go of previous routines
- Agile team consists from developers, testers, domain specialists and UX and there are no predefined ways in how to work in such a matrix, team needs to evolve best practices in working as a unit
- If working with sprints, team focus is usually solely in the content implemented during the sprint and “big picture” fades easily to the background, creating image that there is no rush and suddenly when the release approaches, team is panicking due to insufficient amount of time left to complete increments for the next release
- If in-house dev team is combining with third party, e.g external consultants, it can be difficult to achieve proper visibility and collaboration model with agile framework due to various reasons
- Optimal level of specification
- Optimal length of the sprint
- Definition for story point as a unit and how it should be measured
- Imbalance between development and testing resources within the team
- QA process challenges, such as how to test all scenarios properly
- Keeping hold of feature freeze & code freeze
- Define tools that you use for follow-up (e.g physical boards vs. virtual boards)
- Etc etc
Scrum as a project management Framework
Certain fundamental elements applies when implenting project management with Scrum:
- Backlog contains tickets containing incremental descriptions, commonly consisting from stories and bugs
- Additional ticket types, such as tasks or epics, can be used to support to add precision and transparency into the process
- Each Scrum team have dedicated backlog, which is controlled and prioritized by the product owner
- Sprint content is defined by the team and common approach is that team votes for story points, describing size of the increment, in the sprint planning
- Story points are used to measure size and complexity of the increment
- Votes are used to indicate potential differences between team member approaches, they should raise discussion among team members, if there are major differences between estimation of each member
- Story points should not be used for trying to estimate time, as most likely you are going to fail
- In a wider scale Scrum teams should aim to understand their average capacity based on overall story points completed in each sprint
- Sustainability and stability are mandatory elements, so sprint duration, team headcount should not be altered too frequently in order to learn approximate capacity
- Sprint review is used to evaluate actual outcome of the sprint and in order for the team to learn and improve, each sprint should be analyzed and
- Advantages of understanding the capacity usually materialize when proceeding towards the release
- Teams whom are able to understand their capacity are more likely to finalize content to be released on time and this gives more time for the QA to ensure that the release will be intact -> ultimately leads to high quality releases with less bugs
If you are interested of hearing more about the agile project management strategies, please contact Nearshored.com.
+358 44 360 6090