Behind the scenes at Bundledocs – what goes into software updates?
Our CTO James Hogan recently took the time to share what goes on in Bundledocs when it comes to creating updates to our solution for our customers.
What are the initial steps when developing an update for customers?
When it comes to implementing software updates to our solution the process begins when we receive insight from our customers or information on upcoming updates from judiciaries. We always think of the customers’ needs first and work forward from there. Crucially, we try to develop products that satisfy, and customer involvement is essential for us to be consistent. We aim to deliver new features to our product after every three-week development period. This three-week release cadence allows us to react to the changing needs of our customers and the changing regulations they work against.
Our software engineering team follow the Agile Scrum process and over time we have found that a three-week sprint period works well for us. On the first day of each sprint, we look forward and plan, on the last we review the work we’ve completed and share what we’ve learned. Separately, we discuss the way in which we worked in a more general sense at our sprint retrospectives. This is where we discuss and refine our development process. Each day, our development team meets to give a summary of what they’re working on. Collaboration plays a major role in what we do. The main objective of our stand-up is for each team member to offer and seek advice on how and what we’re all building on that day.
How do you identify and address updates?
Work items for the development team arrive at weekly refinement meetings. These refinement meetings allow the development team meet with stakeholders to gather requirements and set priorities. It’s the development team’s responsibility to estimate the complexity and deliverability of requirements by analysing each requirement from a technical perspective. During a refinement meeting, we may agree to design a prototype for, or investigate further, some requirement that needs clarification. At the following refinement meeting we may present our designs or findings to the stakeholders. Once we are agreed on the design and requirements of an item it’s ready for planning. During planning, the whole development team gets involved in setting a path towards building out the requirements successfully. This always includes a serious discussion around confidentiality, integrity, availability, scalability, security, and performance.
How do you and the team delegate tasks?
As technology moves quickly so does our product, and development team members will always hold varying degrees of experience with our product areas. To identify product area leaders within the team we maintain a skills matrix for each development team member that defines both product areas and a self-assessed measure of confidence in each product area. The skills matrix helps us identify our product area leaders and those in need of experience in a product area.
During refinement, we record a complexity level estimate against each work item. During planning, we might allocate a task with a low complexity estimate to a developer in need of experience in a product area. Equally, we might allocate a task with a high complexity estimate to a more experienced team member. This process encourages skills growth and knowledge sharing within the team.
How do you manage the updating process?
We maintain a process improvement guide as part of the last meeting in our sprint, our sprint retrospective. This is a living document that sets out the development team’s own process. During the retrospective, we discuss the team’s capacity and the timebox we allocate to each meeting we hold.
Currently, we timebox 5.5 hours to plan the work of each sprint. Sometimes work items have an obvious path to conclusion while others require a deeper discussion, and so the planning duration for individual work items is variable. We find our process provides a great opportunity for everyone to discuss technologies, pitch approaches, and gain exposure to areas of the product they may not otherwise have been exposed. Knowledge building and sharing is a key component of our process.
To find out more about or latest updates join our mailing list here.