Quality and certainty rely on a process
January 8, 2020  

Supplied by entelect2013 Administrator from entelect2013
Any engineering discipline requires a reliable process to produce solutions or products that bring value to an organisation. The chosen process should help teams to deliver a quality solution or product within a predictable timeline and at a sustainable pace. In software, this process is called the Software Development Life Cycle (SDLC) which has process elements including requirements gathering, design, implementation, testing, deployment and maintenance. Various nuances of these process elements exist and are applied differently depending on the environment the team find themselves in.

 

 

Any engineering discipline requires a reliable process to produce solutions or products that bring value to an organisation. The chosen process should help teams to deliver a quality solution or product within a predictable timeline and at a sustainable pace. In software, this process is called the Software Development Life Cycle (SDLC) which has process elements including requirements gathering, design, implementation, testing, deployment and maintenance. Various nuances of these process elements exist and are applied differently depending on the environment the team find themselves in.

 

01. Agile means being adaptable


Software teams struggle when the principles and values of the chosen process are rooted in traditional manufacturing and engineering disciplines. The software engineering profession is fundamentally different in several ways which causes traditional processes to fail.

 

Traditional planning is centred around predictable tasks or activities with known manufacturing times while software projects usually start with an end goal and the tasks or activities are discovered and figured out along the way. 

 

Progress is not linear to time because in problem solving, people generally start to work faster as soon as the problem is solved. In traditional manufacturing, the throughput rate is usually consistent and linear to time.

 

In the following sections we will look at some key considerations for implementing a successful software development process. Whether your organisation calls it Agile, Waterfall or any hybrid SDLC in between those two extremes, we advocate to focus on getting four key considerations right for the development process. They are called considerations because this gives organisations the freedom to make it work in their context instead of feeling like they are failing because they do not follow the Agile or Waterfall textbook.

 

02. Software Development Lifecycles


The first consideration is demystifying the noise around the SDLC and whether teams are following an Agile approach. The reality is that Agile is not a process, but rather a set of values and principles that a team lives and applies daily. This gives the team the freedom to follow any process or methodology they like while pursuing continuous improvement in iterative cycles.

 

The Agile manifesto proposes the following values for an adaptive team and development lifecycle:


•    Individuals and interactions over processes and tools


•    Working software over comprehensive documentation


•    Customer collaboration over contract negotiation


•    Responding to change over following a plan

 

That is, while there is value in the items on the right, we value the items on the left more.

 

If we evaluate the manifesto from a process point of view, it is clear that whatever methodology you choose, make sure you have regular interactions with all stakeholders in the project. The process should make time in everyone’s calendars to talk and discuss the project. The goal is to have effective conversations about the project on a regular basis and we have found that co-location and face-to-face discussions is the preferred approach. The best alternative to co-location and face-to-face discussions is to have video conferencing combined with an instant messaging platform geared towards group discussions. When working with a distributed team, the most effective approach is when everyone is remote. A co-located group with a minority of individuals remoting in tends to treat the remote members as second-class citizens.

 

The process must enable the delivery of working software instead of creating documents which do not solve business problems. Documentation must have an audience and only describe concepts which do not often change, e.g. project vision and purpose, logical system architecture, and business rules and key decisions made during the project that have a significant impact. Specifying features in detail will often not be accurate and maintaining the documentation becomes cumbersome and adds little value.

 

Economic factors will play a role in customer collaboration, and so contract negotiation cannot be ignored. Projects do not have unlimited budgets and need to be delivered within the economic constraints of the business. The principle here is that if customers are part of the development process, then the solution or project will evolve and change with the team. The scope negotiated at the start of the project should not be enforced to the letter if the final delivered solution still solves the business problem, which is typically not the same as originally envisaged at inception. Being clear on the project vision and purpose at the start of the journey will aid the team to make decisions as the project evolves and test their decisions against this vision and purpose.

 

 

 

Regular planning sessions enable the team to respond to change rather than creating a plan up front and sticking to it no matter what. Different levels of planning from a high-level flight plan, to a sprint plan broken down into tasks all contribute to keeping the team focussed on what must happen next while keeping an eye on the overall project progress. Scope creep or changes in direction need to be embraced but must be done in a responsible way. Changes in planning should be done between iterations to keep the team focussed during the iteration. Having a high-level flight plan coupled with a detailed sprint plan helps the team to determine the impact of scope changes to the overall project scope.  The stakeholders must be involved in the planning sessions to make decisions if plans need to be adjusted.

 

3. Cross-functional teams


Other considerations for software development processes include skills and capability, prioritisation, and participation and transparency.


Any process is only as good as the people who execute it, and making sure that a team of individuals have the right skill combinations for the problem space, is how we build self-organising teams. This requires people to have analysis, development, testing, data and project management skills within the team. It does not mean that one person is responsible for each of these disciplines but rather the team needs these skills spread across individuals.

 

Large organisations tend to employ people to fulfil a specific responsibility in the SDLC, e.g. only do analysis, development, testing or project management. This approach will inevitably lead to silos and bottle necks within the organisation, coupled with a large management overhead.

 

The size of a team is also a factor which is considered. Having two teams of 5 is usually more effective than having one team of 10. Quality practices like pull requests, code reviews and interpersonal communication are all affected by the size of a team. A truly self-organising team requires a high level of awareness within the team and this becomes challenging in a large team.

 

Prioritisation and clarity, or a shared understanding of what needs to be built, is the cornerstone of effective software teams. A self-organising team is about trusting the team to figure out how to solve a problem. It is not about letting the team figure out business priority and what needs to be solved. The process for delivering good software ensures that a shared understanding is created between the business stakeholders and development team, which is why a good project vision is key. Techniques like joint application design (JAD) sessions, event storming and user journeys/storyboards are all powerful ways to create a shared understanding.

 

To effectively prioritise, the team and decision makers need to gain insight into the value vs effort, as well as dependencies to deliver. Clear and concise acceptance criteria for tasks or user stories will enable the team to estimate with a higher level of confidence and point out any dependencies which need to be resolved before development can start.

 

Creating a backlog of user stories or features with clear acceptance criteria and associated effort estimations, enables decision-makers to weigh up different options. This allows them to decide on what the team needs to work on for the next period. This can only happen if the decision-makers are available for the relevant ceremonies conducted in the team for project planning and discussions. Context, continuity and authority to make decisions in the business make for successful projects. When decision making is deferred to a group of people who are not involved in the project on a regular basis, it usually results in rework, missed deadlines and demotivated teams.  

 

4. Take aways


The final consideration for a good process is participation and transparency from all stakeholders. People enjoy ownership of delivery if they are part of the planning and decision-making process. Making commitments on behalf of the delivery team leaves them feeling like resources and demotivated. A process that enables open feedback with regular demos and a safe environment which values the ideas from all stakeholders lead to a more refined solution. End users will have a better experience using the solution and focus will be given to high value features.

 

 

Read the full From Here to There publication

 


Home | About Us | Offerings | Track Record | Giving Back | News | Careers | Contact Us
PAIA Manual | Privacy Policy | As per statute: www.sacoronavirus.co.za |
© Copyright by Entelect. All Rights Reserved.