Software Process Improvement by Changing Roles in Small

Software Process Improvement by Changing Roles in Small Size Organizations David Cyphert CS 2310 Seminar Fall 2017

Overview • Agile methodology has become more popular in small size software organizations. • History and description of some early agile methods • Agile and CMMI: How can we integrate these two methods? • Changing process roles without affecting their own agility in small organizations. • A brief overview of case studies demonstrating the effectiveness of these process changes.

Agile Software Development • Manifesto for Agile Software Development (2001) • Earlier methods collectively referred to as agile methods: • Rapid application development (1991) • Unified process/dynamic systems development method (DSDM) (1994) • Scrum (1995) • Extreme programming (XP) (1996) • Agile methods focus on the challenges of unpredictability of the real world

Values of the Agile Manifesto 1. Individuals and Interactions Over Processes and Tools • It’s the people who respond to business needs and drive the development process. • Tools/processes drive development = the team is less responsive to change and less likely to meet customer needs. • Example: Communication between individuals. • Happens when needed vs. using processes. Time for meetings needs scheduled and specific meeting content is required.

Values of the Agile Manifesto (cont. ) 2. Working Software Over Comprehensive Documentation • Historically, enormous amounts of time were spent on documenting the product. • Technical specifications, technical requirements, interface design documents, test plans • Agile does not eliminate documentation • Documenting requirements as user stories, which are sufficient for a software developer to begin the task of building a new function. • Example: "As a <role>, I want <capability> so that <receive benefit>"

Values of the Agile Manifesto (cont. ) 3. Customer Collaboration Over Contract Negotiation • Negotiation is the period when the customer and the product manager work out the details of a delivery. • Example: Waterfall model: Customers negotiate the requirements for the product, often in great detail, prior to any work starting. Not during the process. • Agile: Customers who are engaged and collaborates throughout the development process, making it easier for development to meet their needs of the customer.

Values of the Agile Manifesto (cont. ) 4. Responding to Change Over Following a Plan • Traditional approach: Change seen as an expense, so it was avoided. • Develop detailed, elaborate plans. Usually a large number of dependencies in delivering what was promised. • Agile: the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration.

Characteristics of Agile Methods • Defined in 12 principles: 1. Satisfy customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. 3. Deliver working software frequently. 4. Collaboration between business stakeholders and developers

Characteristics of Agile Methods (cont. ) 5. Support, trust, and motivate the people involved 6. Frequent face-to-face team conversations. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development.

Characteristics of Agile Methods (cont. ) 9. Attention to technical detail and design enhances agility 10. Simplicity - Develop just enough to get the job done for right now 11. Self-organizing teams encourage great architectures, requirements, and designs 12. Regular reflections on how to become more effective

Capability Maturity Model Integration (CMMI) • CMMI is a process improvement approach, focused on organizational improvement. • CMMI provides a way to assess the state of an organization’s ability to build software in a repeatable, predictable way. • To reach a certain level, an organization has to fulfil all process areas of that level as well as those of lower levels.

Integrating Agile in CMMI • Agile is a iterative software development methodology, focused on the product quality. • Many organizations demand CMMI compliance of projects where agile methods are employed. • How can we effectively combine the best of both without losing agility? (Specifically, XP and SCRUM)

Coverage of CMMI • The 22 process areas in CMMI can be divided into 4 main categories 1. Project Management Process Area 2. Support Process Area 3. Engineering Process Area 4. Process Management Process Area

Conflicting (-) Not Addressed (0) Partially Supported (+) Supported (++) Largely Supported (+++)

Traditional Software Organization Structure

Process Manager • To get closer to achieving this organizational structure, we can assign a role called a Process Manager • Carries out process management activities professionally. • Measuring and analyzing current processes and identify their advantage and weakness. • Planning and implementing process improvement programs. • Selecting outcomes for analysis, analyzing causes, and recording causal analysis data. • Guiding decision-and-analysis

Scrum Development Team We can restructure the development team into a Scrum Team

Scrum Master • The Scrum Master is responsible for: • Ensuring impediments are addressed. • Monitoring progress. • Facilitating planning, reviews, and retrospectives. • Encouraging continual improvement. • Helping stakeholders and teams communicate. • Helps product owner understand create the product

Product Owner • The Product Owner is responsible for: • Managing the return of investment (ROI) for the product. • Establishing a shared vision for the product among the developers and customers. • Knowing what to build and in what order. • Creating release plans and establishing delivery dates. • Supporting sprint planning and reviews • Representing the customers within the company.

Development Team • Delivers a set of features from the product backlog every sprint • Self-organizing and self-managing; they determine how much work they can commit to at the start of each sprint.

In other words… • The scrum team can't: • Help the organization to manage organizational-level processes through measuring and reporting the status of project. • Help the organization to verify objectively, practically how organizational level processes affect project teams. • Offer evidences for validity and effectiveness of organizational-level processes.

How do we address this? • Add the role of Process Management Supporter to the organization. • Responsible for performing quantitative measurement that is needed to manage and improve organizational-level processes. • Should an existing team member (Scrum master or architect) take on responsibilities of a Process Management Supporter?

New Structure

Case Study • Selected 4 small size software organizations and applied their program for process improvement. • 28 -43 developers • 4 -5 management personnel • 5 -10 agile projects • Combination of informal software development methods and ISO 9001

Case Study (cont. ) • Suggested that these organizations to adopt their proposal • Observed over a period of 2 years • A Process Manager and Process Management Supporters were appointed in each organization • The Process Manager analyzed current processes of their own organization and did categorize them into the ones newly established and the ones complemented with our guides

Conclusions • Presented an efficient organizational structure and roles for reaching higher level of CMMI in small size software organizations consisting of Scrum teams. • Roles of Process Manager and Process Management Supporters responsible for implementing the organizational-level processes were specified. • The case studies show that small software organizations can reach CMMI level 3 without hiring new process improvement specialists and damaging their agility.

Questions?

References RYANG, G. , & MUN, I. (2017). Software Process Improvement by Changing Roles in Small Size Organizations. International Journal of Software Engineering, 10(2), 3 -20. Retrieved October 10, 2017, from: http: //ijse. org. eg/papers/software-process-improvement-by-changing-roles-in- small-size-organizations/ Hneif, M. , & Ow, S. (2009). REVIEW OF AGILE METHODOLOGIES IN SOFTWARE DEVELOPMENT. International Journal of Research and Reviews in Applied Sciences, 1(1). Retrieved October 10, 2017, from: http: //www. arpapress. com/Volumes/Vol 1/IJRRAS_1_01. pdf