Managing Software Development
For quite some time, the traditional approach to project management has been a principal cause of the failure of many projects. However, owing to the globalization of markets and an increasing organizational and production complexity, there has been a need for more adaptive and participatory measures when it comes to project development.
Agile software development alludes to a cluster of software development approaches that have a foundation based on iterative development. In this approach, requirements and elucidations evolve through a joint association amid self-organizing cross-functional parties. Agile processes have a general promotion of a disciplined project management process that fosters recurrent scrutiny and adaptation, a philosophy of leadership that enhances teamwork, personal-organization and culpability, an assemblage of engineering quality practices that are directed to facilitate quick delivery of great-quality systems, and a business approach that brings into line development with customer needs and company goals.
SCRUM is a well-liked iterative and incremental process for software development and in team organizations (Ken Schwaber 2007). Scrum has its terminologies and hence can not be considered to be a technique for managing projects. The Scrum approach has the following features that make it an intelligent approach in development processes:
Projects present a platform to facilitate the implementation of visions and goals. Scrum affords the framework for frequent feedback and exposure to ascertain maximization of the output quality. Scrum fosters excellence through the definition and elaboration of requirements in time to build knowledge of product features relevant. The aspect of daily testing and product owner feedback during the development process aid in addressing issues while they are still fresh.
Less Marketing Time
In comparison to the traditional methods, SCRUM has been proven to confer value to end clients at a rate 30-40 percent faster than the conventional approaches. This statistic is as a result of the early initiation of the development process due to the presence of a dedicated product owner in the team who continually makes clear the requirements. Low priority requirements are separated from those of higher precedence and thus enabling high priority requirements for first handling.
High Returns On Investment
Owing to the decreased marketing time, scrum projects begin to garner profit early and thus over time, accumulation of revenue is going to be high. Income and other intended benefits start to stream in soon as the projects are released into the markets even though some of the low priority requirements might not be in place. Increased returns may also be attributed to few cost effects owing to automation and upfront testing.
Great Customer Satisfaction
Scrum teams have a high commitment towards the production of products and services that gratify the clients. That is achieved through collaborative efforts with customers as partners and keeping them engaged throughout the project’s development steps. Customer satisfaction also results from the fast delivery of end products to the customers.
Excellent results find realization when the scrum teams take responsibility for the products and more importantly the project. Good project performance and property of quality are honed by having the product owner, the development team and the scrum master working near congruent desires for excellence. Concurrently, the conducting of sprint reviews where the product owner gets to outline their prioritization and the development team obtains to liaise directly with the stakeholders.
Less Marketing Time
More Pertinent Metrics
The metrics used by the scrum teams to estimate the time and cost implications, gauge project performance, and come up with project resolutions are many times more appropriate and more precise than metrics in place when it comes to traditional projects. In the scrum, the relevance of the parameters finds the source from the timeliness of the budgets, using relative estimates to make projections of an individual development team, and updates of the burn-down chart daily.
Increased Project Control
There are numerous opportunities to scrum teams to control project performance and work corrections as desired arising from: adjustment of priorities throughout the project at each sprint interval instead of significant markers, embracing change, daily scrum coordination and regular updates to sprint backlogs.
Scrum creates a great sense of transparency, and this has the quick effect of preventing anyone from hiding behind or directing to the mistakes that others supposedly make. By making the work limited to a particular time frame, the responsibilities within the group and the transparency in line with what is delivered eliminate the potential for common disagreements or apologies.
Scrum Leads To Conflicts
The combination of transparency coupled with the short fixed-duration sprints will more often than not uncover pre-existing conflicts or between the teams dealing with development, the owners of the business and the management. The continuum of possible confrontations that could appear in the adoption of scrum is expansive. It all begins with the managers who are tuned to transparency in development but do not want to relay their visions clearly or who may think that the outlay rules do not apply to them just others.
A significant number of people consider that agile means do not require proper and a lot of planning, that documentation is unnecessary and that there should be prompt response whenever the customer change their mind. The reality, however, is much, on the contrary, the iteration date is not to be compromised on, and the critical rules outplayed at the start of the development process are to be followed strictly.
When handling traditional projects, the client approaches the developers with the requirements and response is given with a timeline and a budget. Upon agreement, responsibility is taken for the delivering that project. Scrum recognizes the ambiguity that is intrinsic in the delivery of projects and requests the client to participate in that responsibility. Some clients are unwilling to take that risk as it may be company policy or due to the fear of failure.
Extreme Programming (XP) refers to a software engineering methodology, a prominent method amongst several agile software developments approaches. Similar to the other agile approaches, XP differs from the traditional techniques primarily in the placing of higher precedence on adaptability than on predictability. It prescribes a set of daily practices for both the managers and developers: these workouts are meant to bear and motivate specific values. The five values that XP upholds consist of communication, simplicity, feedback, courage, and respect.
Communication
Software development is by nature a team sport that dramatically relies on communication for the transfer knowledge to be realized from team member to everyone else on the crew. XP focuses on the importance of the proper kind of communiqué – one on one discussions with the aid of whiteboards or any other drawing mechanism of choice.
High Returns On Investment
Simplicity
Simplicity points to the simplest thing that will work. Its purpose is to circumvent the occurrences of waste and engage in only essential elements such as to keep the schema of the system simple in a bid to foster easier maintenance, support, and revision. Simplicity will also include addressing only the requirements that one has a clarity concerning and does not necessarily involve prediction of future wants and needs.
Feedback
Owing to the constant input regarding their previous exertions, teams can isolate areas for enhancement and review their practices. Feedback will also support a simple design. The team develops something, gathers feedback on the design and operation, and then fine-tune the invention going forward.
Courage
Kent Beck defined courage as “effective action in the face of fear” (Extreme Programming Explained P. 20). This definition portrays a bias for action based on several other principles in an attempt to make positive any adverse effects to the developers. You need the courage to raise organizational issues that reduce your team’s effectiveness. There is a need for courage to stop doing something that does not work and venture out to try something else. Courage is also needed to accept and then take action on any feedback that is given, even in the difficulty of acceptance.
Respect
Members of the team need to have mutual respect for each other for there to be proper communication with each other, and specific provision and acceptance of feedback that honors the relationship, and to work collectively to recognize simple designs and elucidations.
Conclusion
It is needless to say that proper planning and smart decision making helps one to get past these shortcomings with the Scrum methodology. For instance, in teams with many members, every member has to have well-defined roles and duties with specific targets, to eliminate compromise on quality and no defense for letdowns. This will thus help to keep the team to focus on the project goals.
References
Fitzgerald, K.-J. Stol. (2015) Continuous Software Engineering: a Roadmap and Agenda.
Consolvo S, McDonald DW, Toscos T, Chen MY, Froehlich J, Harrison B, et al. (2008, 1797 1806) Activity sensing in the wild: a field trial of ubifit garden. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems.
Conboy. (2009) Agility from first principles: reconstructing the concept of coordination in information systems development Inf Syst Res, 20 pp. 329-354.
Strand, K. KarlsenAgile. (2014) Contracting and ExecutionPROMIS.
Lianping Chen. (2017) Continuous Delivery: Overcoming Adoption Challenges Journal of Systems and Software, Volume 128, pp. 72-86.
PMI. (2013) A Guide to the Project Management Body of Knowledge (5th edition), Project Management Institue.
Biffl, A. Aurum, B. Boehm, H. Erdogmus, P. Grünbacher. (2006) Value-Based Software Engineering Springer Science & Business Media.
Schuh G., Dölle C., Kantelberg J., Menges A. .(2018) Identification of Agile Mechanisms of Action As Basis for Agile Product Development Procedia CIRP, Volume 70.
Balijepally, R. Mahapatra, S. Nerur, K.H. Price. (Mar 2009) Are two heads better than one for software development? The productivity paradox of pair programming MISQ. pp. 91-118.
Xiaofeng Wang, Kieran Conboy, Oisin Cawley. (2012) “Leagile” software development: An experience report analysis of the application of lean approaches in agile software development Journal of Systems and Software, Volume 85, Issue 6, pp. 1287-1299.
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
