Author: s1020153

Over the course of the software development lifecycle, a project could be exposed to risk to different extends. Top risks might not allow for delivering the system of need. These could be absence of clear requirements, lack of qualified personnel. In order to minimise the effect of these dangers, it is essential for these risks to be identified. However, as these concepts could turn up quite vague, the process of mitigating risks could be challenging. Cockburn’s risk catalog outlines potential problems and suggests solutions. In this article, I will describe a project I worked on as a part of the team, and I will discuss how we applied risk reduction patterns in order to mitigate our project risk. Additionally, I will explain what other issues arose over the course of the software development. This proves how challenging the process of identifying and diminishing risks could be.

The project I will reference is the famous System Design Project all informatics students in the University of Edinburgh get to do. Eight students are put together in a group and asked to design a lego robot and to develop the software which enables to robot to play football.

A fundamental problem at the beginning of the project was the team’s lack of knowledge about the issue. Many did not have experience with larger scale software systems, and nobody had any experience with robotics and software-hardware integration. Therefore, when the first task came up, the robot had to execute a kick command, the team was thrown into confusion. There was substantial lack of knowledge and we were unable to put together a sound plan beyond deciding who is building the robot and who should be responsible for the software for the task. Therefore, in order to proceed, the team had to gather  knowledge. However, the process of “clearing the fog” continued for substantial amount of time and was quite hectic; there was no working code within the next few days. Even though we immediately tried to tackle the problem, we did not manage to find the right balance and were still fighting the risk of non-delivery.

Further on, as we were still not completely confident about how to design and integrate the systems, we built up a prototype – a simple robot which could receive commands and execute a movement of the motor. This clarified the direction of the project, and even though it was a simple solution, it helped us discover how the system works and integrates. It was the first deliverable result produced. Therefore, creating a prototype was crucial for dealing with the risk of not possessing enough knowledge on the matter, and helped us kick off. We succeeded applying this pattern because we managed to apply the accumulated knowledge and produce a solid base for the system.

One of the most serious issues our team experienced was dealing with ownership. In the early stage of development, two groups of people were working on the code for achieving the upcoming first milestone by implementing their own ideas without consulting the entire team. While there were significant conflicts in the team in regards to who is responsible for these functionalities, important areas did not get significant attention. This was the vision system, and developing this modulel accurately and reliably was essential for the success of the project. Once it was established that significant ownership problem existed in the team, we decided to manage the conflicts by setting up border lines regards people’s responsibilities. However, this overcorrected the problem. Every aspect of the project was assigned to groups of people, which were micromanaged, i.e. members of these little groups were to assign details to each other. All of these decisions happened after extensive discussions about people’s skills, interests and preferences. Therefore, conflict management took substantial amount of team’s time and effort instead of this focusing on the software development itself, and did not assure 100% delivery. The approach switched from being a little hectic to being extremely structured and led to overcorrection.

Ownership by component was later adopted. We managed to establish clearly people’s responsibilities for particular functions, and we did not have any friction between function and component owners. However, between those who worked on the strategy module, it remained unclear who is responsible for integrating the developed strategies together. Conflict resolution was not needed anymore, but the integration job remained a gray spot until quite late in the development process.

At a much later stage when the project was coming to its end, the final goal was close and clear – the robot had to enter a football competition. A week before the final, we did not have a working code for the match, but the team was still distracted with numerous task. People focused on improving details of the vision system, getting rid of unused code and refactoring, writing reports. All of these problems kept the team from keeping up towards achieving the primary goal – performing well in a game situation. However, it was the team leader who kept on working on the game strategy. He managed to put the foundations of the code used at the final, and thanks to his progress at that time the team managed to prepare adequately in time for the game. Ensuring someone was working towards achieving the primary goal while team members deal with secondary tasks was crucial for fighting the risk of not delivering the system of need.

There is very fine balance between dealing with risk appropriately and over correcting an existing problem. In order not to introduce additional aggravation of the development process, this balance has to determined as early and accurately as possible. The scenario described proves that this is not a trivial task, especially for inexperienced teams.

References:

http://alistair.cockburn.us/Project+risk+reduction+patterns

The author of the article argues that valuing the notions on the left hand side more than those on the right hand side is infeasible in large scale software projects, and the traditional development methodologies are more appropriate in such scenarios.  I believe that in the context of large scale software projects, both notions are equally important, and sometimes the left notion could contribute towards the successful delivery of the software even more than the right one.

Working Software over Comprehensive Documentation

This agile value from the Agile Manifesto claims that delivering working software should be a priority over delivering well written documentation; however, the term “working software” has to be clarified. The agile methodology encourages delivering small pieces of working software at set intervals which might be infeasible for large scale projects. The author of the article places the focus on the importance of the documentation, so I will try to explain how the two notions balance and evaluate the importance of each of them.

The agile methodology does not encourage creating extensive detailed documentation over the development process; it is a waste of effort as it is prone to change because of the dynamics of the process. However, this does not infer that no documentation should be prepared. The author claims documentation by informal means might be “swallowed up or forgotten”, and maintenance of a project might be aggravated. I disagree, I believe that documentation done extensively with a lot of effort invested could be as helpful to developers as a shorter concise and informal version that touches upon key points. Furthermore, if I had to weight the left-hand side and right-hand side notions, I would extensive documentation is worthless if working software is not delivered appropriately. In the case of the school sign off system failure, having working software which has passed unit, system and integration tests is more important than having documentation to facilitate potential investigations – they could be done with much less.Therefore, I disagree with the author’s claim that the left notion, working software, is not as important as the right one, comprehensive documentation. While documentation is essential for the record or for future maintenance particularly in the case of large-scale projects, I believe that delivering working software should be of highest priority in all circumstances.

Individuals and Interactions over Processes and Tools

The processes and tools are created in order to facilitate the work of people as they are those who create or need the software. The author claims when “allowing the individual personalities of developers to encroach upon the project, standards can begin to slip.” I believe that if a professional was to contribute expertise, he could potentially be beneficial for the project. The author claims that sometimes innovations is not necessary and code reuse is encouraged; I think this applies not only in large scale projects. However, if encouraged when necessary, innovation could bring flavour to the project and distinguish it. Of course consistency must be ensured by coordinating innovative steps with the management. I agree that using established methodologies is safe practice; however, deviating from the processes if necessary would not be detrimental for the project if appropriately scheduled. In the end of the day it is the individuals who decide on given processes and tools for certain projects, so their input is supreme for the success of the project.

Customer Collaboration over Contract Negotiation

The author claims that it is essential to have a contract in place outlining as much specificatications of the system as possible before the software development begins. He does not claim that there must not be any communication between the customer and the developers, but a contract would protect the developers from unexpected and challenging change. I believe that planning in the context of large scale projects should be done extensively to the best of customers’ and developers’ knowledge, and a contract capturing these agreements should be put in place. However, having a contract might bring a false sense of security to the development team who might implement uncertainties wrong rather than reaching out to the customer. Additionally, large scale projects take plenty of time to complete, and a change in the requirements over the time is likely. I understand that an iterative delivery approach is extremely challenging in the context of large scale projects. “Humphrey’s Law” claims that do not know when they would want unless they see it working. I believe that an effort in that direction will contribute towards success, as many issues might be resolved. Furthermore, I believe that if the risk is mitigated, an attempt for capturing customers’ needs not listed in the contract should be made. Excellent software within budget is achieved through collaboration and compromise of both developers and clients.

Responding to Change over Following a Plan

Having a plan to follow certainly brings numerous benefits to the table. The author claims that making changes is costly and following a plan allows the project to stay consistent and within budget, and facilitates progress measurement. Also, he claims that in terms of large scale projects, if a change was to be accommodated, the communications could become “bogged-down,” and deviations from the plan might become disastrous. However, I believe that the communication challenge could be appropriately handled by the management. Additionally, industry data shows that 60% of the software requirements change over the development process. Clients might thoroughly create a plan, but sometimes they might not be able to predict some changes, and certainly bringing change to a large scale project is incomparable to altering a small one. If a large project was delivered on time and within budget, it would be worthless if it did not satisfy customers’ needs. I believe that even though responding to change and revisiting the plan might introduce additional expenses, taking actions would be better than delivering software which does not solve the problem and will eventually end up on the shelf.

Conclusion

Implementing large scale systems is different from implementing smaller projects,  but the software development process faces similar challenges, challenges which the agile methodologies helped overcome. Adopting an agile methodology in a large scale project might be questionable; however, some of its practices represent “good practice” in software development. They might be as beneficial as traditional methodologies, and taking them into consideration could bring flavor to the development life cycle.

References:

Sutherland, Jeff. “Agile Principles and Values.” http://msdn.microsoft.com/en-us/library/dd997578.aspx

 

Introduction

Successfully choosing a methodology that would fit well a team with a certain level of expertise and a given software project could be challenging. Picking the inappropriate practices for a given situation could aggravate the development process and result in the team not being able to capture customers’ requirements accurately, or to deliver a quality product within time and budget. In this article, I will discuss the “Extreme Programming” agile methodology which some advocate for its high speed software development and some of its good practices. I will revise its paradigms and attempt to fit them to the methodologies I experienced as a part of a team over an internship programme. I will explain which of them worked very well by accelerating the software development process and by benefiting me as a new team member. I will also discuss which practices present challenges for a team in the context of a larger organisation and attempt to explain how they can be altered to fit this particular scenario. Through these examples I will illustrate the importance for choosing the right practices for the success of the software project.

Extreme Programming

XP is an agile methodology suitable for dynamic and fast-paced environments of teams with fewer than 10 members which produce software prone to quick requirements’ changes. The activities of the XP life cycle are well defined through four fundamental values:

• constant communication with clients and fellow team members

• constant feedback thanks to customer communication and extensive testing

• simple design which aims to solve the current problem rather than focus on potential future problems

• being proactive when dealing with problems [2]

While some of these XP practices could be identified as good practice in software development, others are difficult to implement for certain team projects due to various circumstances. Some expert suggest that even though practices could be closely interleaved with each other, adopting them consecutively would be a more smooth process which helps developers keep their focus and deliver software. [2] Therefore, striking the right balance is essential when choosing the appropriate methodology, and plenty of factors could influence this decision. I will give examples of such circumstances, those which influenced my team over my internship.

The Case Study – My Team

The team I joined over my internship for a period of 10 weeks was a 8-people team, part of a bigger unit within a software house. Over that period, it was functioning as a core team, meaning that it was developing and maintaining strategic system which developers from other teams would use as platforms to build their applications on. Communication with other teams and clear documentation in order to facilitate others’ work were essential in that context; however, software development was done independently and autonomously. Team members did not have rigid roles which can potentially aggravate the agility of the process. The manager was extremely technical with plenty of experience, so he provided advanced technical advice when needed and he served as a mediator between the team and the organization. The structure of the team could greatly influence the application of agile methodologies; however, it faced the challenges of functioning as part of a larger organisation. [3] Thus, while some XP practices were religiously followed within my team, other were thoroughly reconsidered for that different  context,

The XP Practices

Agile development is difficult to adopt for larger teams; however, 8-people could easily accommodate the methodology. [1] However, as the team was global (2 people were based in NYC), location did play a role. For example, as a newcomer, I could ask questions and work in close collaboration with my teammates sitting beside me. However, when I had issues with the colleagues in NYC, I had to put down my thoughts in an email or wait until it is an appropriate time to call. I could understand how locations plays a role and aggravate decision making, design discussions, or problem solving. This could potentially increase the need for creating valid documentation or adhering to common coding standards.

 Practices thoroughly followed by my team were the ideas of extensive testing and continuous integration. Test-driven development and automated regression testing were encouraged; suitable test suites allow testing when any changes of the system are implemented; furthermore, as many other people were working with my team’s code, prepared test suites greatly facilitated their work in case they decided to adopt it for their needs. Furthermore, releases were performed every two weeks, in order to ensure that any bugs are fixed, requirements implemented or issues addressed, and feedback collected. Pair programming was encouraged when necessary, work stations were being provided.

XP puts emphasis on always implementing solutions to the immediate problem first.[2] The precept “You Aren’t Going to Need It” advocates that the architecture must be as simple as possible and not adhering to future changes. [1] However, as a core team, my team had a dual role of implementing requirements expressed from other teams but still preserving ownership of their projects, improving the architecture and keeping it strategic so that changes could be easily accommodated. Also, delivering solutions is highly prioritised compared to keeping the documentation of the design extensive and up-to-date. This job is considered a waste of effort as the system might change rapidly. However, having accurate documentation was essential for my team as many other teams based their code on the work of the ‘core’.  Additionally, the company encouraged internal mobility, which meant that it was likely for a new member to join (such as myself). Thus I believe that more emphasis should be put on proper documentation, at least at certain times. Sometimes change in human resource is inevitable, and even though practices such as collective ownership helps everyone to be up to speed, documentation can certainly help. I conclude that the necessity of documentation is brought by the nature of the work of the team, but can also be related to the challenge the team faces by being part of a larger company.

When it comes to interaction with the customers, my team had great experience. As customers were also employees of the firm, they were dedicated to the problem, as collaborative as possible, and knowledgeable about the software development process. The “Customer Involvement in XP” workshop reached the conclusion that such customers would best fit the agile methodology [1]. However, geographical location greatly influenced the work process.

The Challenge

My team deviated from the XP paradigm by establishing a sense of “institutionalization.” It was inevitable; being a part of larger body can always be a challenge when adopting agile practices. Even though the team was autonomous itself, sometimes it was necessary to take into consideration the company’s ‘good practice.’ However, as some practices represented challenge for the agile process, some cultural concepts that the organisation encourages, such as teamwork and extensive communication, could bring good vibe in an agile atmosphere. Therefore, when implementing XP within a unit of a company, it is important to deeply evaluate the context of the environment. Using certain methodologies could introduce challenges but also certainly refresh the development process.

Conclusion

By using some of the XP practices, my team could greatly improve its dynamics and delivery. However, other aspects of the XP paradigm could not be extended to all aspects due to understandable challenges. Therefore, in order to bring in the right methodology, it is important to consider how it will benefit the team, or what problems it might raise. Over the course of my internship, I witnessed how my team took advantage of good XP practices while keeping itself in the loop of the corporation.

References

[1]Boehm, B., “Get ready for agile methods, with care,” Computer , vol.35, no.1, pp.64,69, Jan 2002

 

[2]Paulk, M.C., “Extreme programming from a CMM perspective,” Software, IEEE , vol.18, no.6, pp.19,26, Nov/Dec 2001

[3] Boehm, B.; Turner, R., “Management challenges to implementing agile processes in traditional development organizations,” Software, IEEE , vol.22, no.5, pp.30,39, Sept.-Oct. 2005