This article is written by wearing the traditional hat to appreciate where we came from. Water Fall or Phased approach to Software Development is the traditional approach in Software Engineering that has been proven for years to control and coordinate Software Development activities for a Scope fixed Software Product. Even though, presently we live in the Agile world, phased approach still makes sense when we look at activities occurring in each  iteration or sprint. While going through this article together, we will see how we can relate the universal facts that is still true for any Software Development process and even the commonly used Agile based models. Below is a typical phased Software Development Life Cycle –

The phased life cycle model is also called Water Fall Chart since in theory each phase involves well defined input information processed by which cascades from one phase to another in smooth progression, But in reality, as we know, most of these phases overlap. Lets see each phase in brief –

1) Analysis

Analysis phase involves identifying the problem, formulating the requirements, preparing a software project plan based on the size and nature of the project, finding alternate solution strategies and/or business case, conducting feasibility studies, selecting the most optimal solution. If we relate this to the general Agile based Software Development Process/Methodologies, this will involve creating/evolving Software Product vision/road map, Epic planning, Feature Planning, Back log grooming, release planning, sprint planning, creating/review of wire frames, velocity planning.

Planning generally involves creating a formal Requirements Definition involves the formulation of a specification that describes the processing environment, required software functions, performance constraints on software like size, speed, machine/server configuration etc, exception handling, implementation priorities and acceptance criteria. In the Agile world, this would translate as breaking down Software Product specs from Epics to Features to Back log work items for a sprint, work item acceptance criteria, wire-frame models, product backlog. In the traditional phased approach, developing solution strategy involves working on the alternate solutions, business case and feasibility study. Whereas in Agile world this translate to a sprint where R & D is performed to create a scaled down working model enough to show a demo to the user.

Something that we normally wont perform in an Agile based Software teams or most of the traditional water fall teams is the Planning of Software Development Process itself. The reason is that the Software Development Process is normally standardized and set up for the whole organization based on the nature of Software Product or Software that the organization builds or maintains and based on its culture. In cases where choosing an optimal Software Development Process is relevant, the project team works together to identify a suited development model (eg: water fall, Agile, Scrum, Lean, Hybrid etc), forming organization structure of project team, plan configuration management, QA etc that makes sense for that particular development model.

The outcome of planning activity during Analysis phase is usually the System Definition in case of phased model or the Sprint backlog in case of Agile based models and the Project Plan (phased model) or the Current prioritized Sprint work items with acceptance criteria, daily burn down charts and release plan for Agile models.

2) Design

System Design involves creating the blueprints (high/intermediate/detailed) for the targeted Software System based on the analysis models or design sprint work items. In a phased Software Development Life Cycle model, there would a specific time slot set exclusively for design activity which develops the logical system design required for Software implementation in terms of Architectural and Detailed System Designs. Where as in case of Agile based models,  there could be multiple design activities undergone in a single time box or sprint based on the work item that is being analyzed and implemented. In general terms, irrespective of the models used, the goal of system design is to create scalable system architecture and blueprint fitting the overall technology road map and architecture and that could implemented into reliable and highly available Software.

Architectural Design models or an Architectural sprint work item will depict software components, decomposition and decoupling them into processing modules, class diagrams, activity diagrams, data models, information architecture diagrams etc. Detailed Design models or a detailed design sprint work item will depict methods to implement the high level blueprints and wire-frames created in the high level architectural design into a detailed blueprint a step above a working POC (proof of concept). Sufficient Design reviews are conducted (including user/customer as needed) to ensure that design satisfies the requirements / acceptance criteria and can create bug free Software.

3) Implementation

In Software Engineering world, implementation phase generally involves Coding, Debugging, Documentation and Unit Testing. A phased model will have a specific time-slot allocated in the project plan where as in Agile based models, this will be mostly done as part of a specific Sprint work item which analyzes, design and builds a particular function/feature or a micro-service. Coding involves translation of conceptual design into physical design eg: Model, Views and Controllers of an MVC based  Software System. Debugging involves identifying errors which has occurred during design activity such as improper & in-efficient interfaces between routines, processing error in algorithms & data structures/Models, errors due to in-efficient exception handling & error which might crop up due to in-efficient mapping of requirements/user story/acceptance criteria into appropriate System Design and Unit Testing routines/interfaces. The Developer is expected to build in necessary unit testing frameworks and exception handling mechanisms to ensure that sufficient verification is done to make the Software bug free and confirming to the user story.

4) System Testing

System Testing involves the final testing of the Software function/feature/product for getting acceptance from the customer. Again, in a phased model, there will be a specific QA phase allotted in the project plan where the Software will be deployed on a System integration environment and gotten ready for customer review. Only difference in case of Agile models is that testing happens during the same sprint and as part of the same User story that is being analyzed, designed and implemented. As in the phased approach, the Software will need to be gotten ready in an integration environment for the current release branch. Agile world involves much more detailed and automated approach to get the daily unit tested to be integrated continuously to the testing environment overnight so QA team member can test it the next day. Once the Software is integration tested by the QA, it is then released to a staging environment for the customer to review and gain user acceptance. Once user sign off the UAT (User Acceptance Test), Software/Feature is released to production as per the release plan (Agile Model) or the project plan (phased model)

5) Maintenance

Maintenance phase involves enhancing or modifying the Software System, adapting it to new processing environments and technology changes & correction of Software bugs that was not caught curing System Testing. Most organizations will have a production support model which handles the production bugs and applies fixes/patches to the production branch and merges the same to the current release or re-routes the changes to the development team based on the effort and scope. This might get spun up as a separate enhancement project in case of a phase model or end up as a architectural or normal sprint back log item for prioritization.

HomeSoftware DevelopmentProgrammingSoftware Development Team Structures

Software Development Team Structures

August 1, 2020

In this article we will start by reflecting upon some traditional software development team structures. This will help us appreciate where we came from. Some of these structures still exist in some of the traditional software development teams. Due to the intermingling nature of a Software Development Manager and a Software Project Manager, when you read through this, where ever you see Project Manager it implies a Project Manager who pre-dominantly uses his Software Project Management tool set such as PMBOK or similar project management methodologies for a living OR a Software Development Manager who is a seasoned developer with managerial and project management skills. I am planning to write another article which will shed light into the lives of these two patterns of managers who are the back bones of many mission critical and state of the art Software Products. This will help aspiring students and practitioners!

1. Project Format – In a project format, the programmers themselves do all the tasks like product definition, system design, implementation, testing, review, system documentation etc. Some of them may retain for further maintenance work of the same project while other move on to new projects.
2. Functional Format – In functional format of project organization, different teams performs various tasks as follows –

3. Matrix Format – The major difference between matrix format and functional format is that while functional involves only the software project manager and only one software project manager being worked on within a functional team, matrix format has more than one software project managers dealing with parts of various projects and there are teams for each of the sub-projects. ie. everyone has at least two bosses!

Advantages of matrix format are as follows –

• Special expertise can be brought to a specific function
• Project staffing is eased since project personnel can be brought in as needed for a project
• Work load is balance so that individuals returning to their functional organization are assigned to other projects or may spend time training

4. Agile Teams – As Software Development advanced throughout the decades, we saw various different approaches to the conceptualize-design-build-test-deploy-maintain life cycle – such as – Waterfall model,  Iterative Models, Spiral models, RAD (Rapid Application Development) models, Extreme Programming models, Lean Models. The basic framework of Software Engineering to develop and maintain Software – The Software Development Process – went through so many approaches to achieve a focused goal namely creating the most valuable Software for the customer with least defects and at the right time and at the same time being flexible enough to account for constant fluxes. Early years of year 2000 saw Software Practitioners coming together to layout a common theme which has laid out the foundation of the many Agile Software development teams.

An Agile Software Development team is one where the team organizes itself , is fully autonomous and is empowered fully to create, maintain and flourish its focused Software Product or feature. At the basic level (as shown in above diagram), an Agile team (usually called Scrum Team since most companies use Scrum as the de-facto Agile team process model) consists of 3-4 developers, 1-2 Software Testers, a servant leader (usually called the Scrum Master) and a product owner. There could be multiple Agile teams working with close collaboration who runs and maintains various distinct Software Features or Products within the organizations. Developers [design, build and unit test], Testers [perform QA activities with increased usage of automated testing tools], Scrum Master leads the [Sprint rituals such back-log grooming, prioritization, Sprint planning, User Story creation, Sprint reviews and Sprint retrospectives], Product Owner [owns the feature and maintains the product road-map and deals with the business counterparts and ensures that the feature is in synch with the overall Software Product vision]. The overall Agile culture of the organization ensures that they have 2-4 week sprints, they have set release plans, scrum of scrums and that each agile team is self organizing and collaborating to the extend that they harmoniously work towards developing most valuable Software for the targeted customer base.

In the recent decade, some companies organize their Agile teams as Tribes, Sqauds, Guilds and Chapters as shown above diagram. Tribes is a group of Agile teams who maintains various features of a similar Theme of a Software Product. A Tribe may contain one or more Squads where each Squad represent a distinct Agile teams responsible for a distinct feature. A Chapter is a group of similar skilled team members across squads within a Tribe who meet and collaborate periodically towards betterment of their skills, sharing ideas and practices. A Guild is another special interest group who meet and collaborate towards sharing of ideas and standardization as needed.

Looking at the Agile team structures, one might think where is the role of Software Project Manager or a Software Development Manager or a Line manager. These roles are usually played by a senior member usually a Tribe lead or the person who leads a Chapter or a Guild. In some organizations, the Software development manager plays dual role of Scrum Master. In some cases they lead multiple Agile teams or a Tribe, multiple Tribes or Chapters.

Other related articles that you might be interested in –

1. Factors Affecting Software Cost

2. Programming Team Structures

3. Software Cost Estimation

4. Factors Affecting Software Quality and Developer Productivity

5. Managerial Issues of Software Engineering

6. Software Development Team Structures

7. Software Engineering

8. Software Engineering then and now

9. Project size driving Project risk

10. Quality considerations for software projects