Outsource Software

Want to learn about Daily Scrums with distributed development teams? Frankly, you will be better off contacting supergloo rather than reading this article. Here is another example of article outsourcing.

It is part II in examples of original article outsourcing:

————————

Daily scrums in offshore software development

The concept of Agile software development has given another dimension to software engineering, and this has helped the process of development to promote irritations through-out the life-cycle of a project.

Editor’s note: You won’t catch me claiming to be the world’s greatest Agile coach, but I believe the word should be “iterations” not “irritations”

Most of the methods in Agile development looks for minimizing the time required for the software to be developed and implemented. To achieve the success in any software development process, daily scrum has become an essential part of the entire system, providing a simple rule in achieving success in the different aspects of project development, such as, planning, requirements analysis, design, coding, testing, and documentation.

In an Agile software development, there are processes designed to add energy focus, clarity, and transparency to the development process of the project. This process is termed as scrum. It is a set of simple rules that organizes the software team to increase the speed of software development, organize the objectives of project development, create a performance driven culture, uphold the values of the stakeholders, maintain stable and consistent communication at all levels, and enhance the development process of each individual, there-by improving the quality of life.

Daily scrum governs the very characteristic of a software development process. It is a “skeleton process” that defines a set of rules which are practiced by the software team, in which each has a predefined role to play. Within the scrum, there is one scrum master, who plays a role similar to that of a project manager. The scrum master is responsible to maintain the processes. The product manager owns the project, and looks after stakeholder values and represents the software development team.

The product backlog consists of a set of highly prioritized set of requirements of work to be done. A sprint is a period, of may be of 20 to 30 days as decided by the scrum team, and during each sprint the team makes ready an increment of shippable software. It is from this product backlog that the set of features go into sprint, and the features to include are decided by the sprint team during the sprint planning meeting. The scrum leader at this meeting puts forward his suggestions regarding which features he wants to be included in the sprint, and the team determines how much of these features they can commit to be included in the next sprint.

During the sprint, meetings are held each day and this is known as the daily scrum. The daily scrum has specific guidelines to follow. These include -

• The meeting should start precisely at pre-determined time, and there are punishments for tardiness.
• Meetings are all limited to 15 minutes without any regard to the team size.
• All the members attending the meeting should stand.
• The meetings should be held at the same place and at the same time everyday.

During the meeting, there are three questions that each team member should answer, and these are:

• What have you done since yesterday?
• What are you planning to do by tomorrow?
• Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)

A brief sprint retrospective is held after each sprint meeting. In this meeting the team members are required to reflect on their activities about the last sprint. This ensures the very purpose of this retrospective meeting in keeping the continuous improvement process alive. This meeting is time-boxed for 4 hours.

Daily scrum enables a self-motivated team to be organized. This encourages the co-location of all team members, improves communication amongst the team members, and places a disciplined software development process into action. Principally the scrum understands that the customers can change their thoughts on what they want and need, and that the changes cannot be successfully implemented in a traditional predictive manner. In this matter the scrum takes an emperical [sic] approach to this problem. In accepting that the problem cannot be well understood and properly defined, the scrum team focuses on the ability to deliver quickly, and respond to the upcoming requirements.

—

huh?

Development of software is always a team effort and is best accomplished with the teams working close to each other. The discussions that take place amongst the teams in real time, moves the project forward to its implementation. However, the practice of relying on Agile offshore development has brought about a powerful marriage between the repeated rapid processes, and multiple offshore engineering teams, the combination of which is marked with improvement of market response, its trends, and customer requirements. In here, there are suggestions as to how you can manage this collaborative process across the length and breadth of 8,000 miles that separates the Scrum teams of the multiple shores.

Agile methodologies such as XP, Scrum and DSDM have been adapted by the extended teams of successful global organizations, thus improving their customer needs and time to market. In the process, the organizations gain faster experience of transfer, training, transition planning, goal setting, governance, including the method of reviews which are necessary to achieve results. Deployment of Agile development methodologies in multi offshore environment can be challenging, and research has shown that with the required modifications, the adaptation of the development process in multi-locations and time zones, offshore engineering has been able to deliver quality and productivity compared to the established Agile teams in the US, and that too in just three months. This achievement includes reduced calendar time in incorporating new features, feedback from the early stage of development, along with the ability to make critical course corrections.

Agile methodologies are a new process adapted in today’s software development processes and practices, which introduce the changes in requirements by delivering the software in small releases. This has kept high the customers’ confidence, who can now relate their business requirement changes much faster. Agile methodologies have introduced a new set of software development processes and practices, which provide requirements change through delivery of the software in multiple modular releases. This increases the confidence of the client and enables them to relate any of their requirements of business changes much faster. The global economic situation has changed software development strategies, and the larger IT organizations are changing over to offshore development at a much faster rate.

In an offshore development process it is not necessary for the offshore and onshore developers to be in constant touch and communicate regarding the progress of the development of the project, and its specific feature or function. To give you an example, it is a waste of time for the onshore and offshore developers to check the same codes in the same section of the code repository, and eventually affect the work by checking each other’s code. With the offshore team having competent self-sufficient business analysts, programmers, QA staff, and technical writers the work can be conducted indecently by them without the necessity of much communication between the offshore on onshore developers.

The important thing in any team work is the interpersonal relationships within that team. With the Scrum teams distributed throughout the US, and the offshore locations, there are few interpersonal working understandings between the teams with few or none live contacts between them. This can invariably affect the software development progress in the quality of its production, and there could be questionable deliverables. To solve this situation, basic team building exercises need to be taken up. In doing this, the offshore Scrum team could be sent to the US for few weeks, where they can observe the dynamics and other typical working characteristics of the US teams situated at different places, and this could help in building the much wanted working relationship between the Scrum teams. In practice, it is found that a US based engineer visiting India every two months, and inter-acting with the offshore team in India. There-after, a tram of Indian engineers is lead to visit the US every six months to interact with the team members in the US. This brings about an understanding between the two teams, in working relationship and from a cultural and morale-building perspective as well.

Lean manufacturing management technique was also borrowed by US automobile manufacturers from their Japanese competitors. Lean manufacturing is characterized by emphasis being placed on product quality in the first place. The approach became integrated in various stages of the production process and also relies on suppliers and subcontract to produce the greatest proportion of value added.

Editor’s Note Lean Manufacturing Management process has been adopted for software development. Lean software development will be covered in future articles.

Finally, speed of processing and delivery are emphasized. At the same time, central feature of lean manufacturing remains on the supplier structure that significantly reduces the number of companies a manufacturer deals with directly. Consequently, lean manufacturing is characterized by close relationships as well as frequent interactions with suppliers. Thus, in 1970th there was a process of reorganization of the supply chain in United States. In Japan auto assembly and production parts are located in several core industrial regions such Tokyo and Yokohama. At the same time, concentration of suppliers in United States is not as intensive as in Japan.

Thus, implementation of the new management technique is closely related to size of the country. In United States, there are two types of suppliers – captive and independent. When lean manufacturing management was implemented in the United States by the Big Three automobile manufacturing companies, captive suppliers were concentrated in the Midwest. Even today, as a consequence of implementation of the new technique, geographical representation of suppliers remains similar to the one that was introduced in 1970th. While Ford historically operated with a centralized model of production in Detroit and Dearborn, now company’s parts are clustered in Michigan and Ohio.

On the other hand, General Motors used to have multiple centres in Michigan, but soon after implementation of the new management technique, the company moved the operation process to the Midwest by purchasing independent supplier companies. Thus, before World War II, captive suppliers of automobile manufacturers have been largely clustered in the Great Lakes Region. However, after the new strategy was implemented, unskilled production process was moved to the south.

Experience gathered during large-scale implementation of Agile concepts in software development projects teaches us that the currently popular Agile software development methods (like Scrum) do not scale to program, product and organization level without change. The fundamentals for changes to these methods are found in Lean principles, or: the future of Agile methods is found in its origins. This paper describes a planning framework that has been used successfully in large-scale Agile projects and investigates the impact of introducing this framework on three core Lean principles : Muri, Mura and Muda.

Planning in Large Scale Agile Projects

In Agile methods, loading a team with work is done through iteration planning. Due to the shortness of the iteration (typically one to six weeks) a plan reduces in importance and planning gains in importance. For small projects, it may be sufficient to plan only a single iteration at a time. The experienced disadvantage of iteration planning when applied to projects that run for more then a few iterations or with multiple teams is that the view of the longer term implications of iteration activities can be lost. In other words: the view of “the whole” is lost. A solution is to add planning levels to incorporate the current view of “the whole”.

In plan-driven and waterfall methodologies, this problem is overcome through a large upfront design, aiming to predict accurately how much work is involved in each project task. This leads to a large investment early in the project, when it is by no means certain that the designed functionality is actually the functionality desired by the product owner. An approach with multiple levels of planning has to avoid the reintroduction of the big design up front.

Planning activities for large-scale development efforts should rely on five levels:

• Product Vision
• Product Roadmap
• Release Plan
• Sprint Plan
• Daily Commitment

The certainty of undertaking activities addressed in each of the five levels increases, and therefore the amount of detail addressed (money invested), the number of people involved and the frequency can increase without running the risk of spending money on features that may not be built or may be built differently. Each of the five levels of planning addresses the fundamental planning principles: priorities, estimates and commitments.

Product Visioning - Level 1 The broadest picture that one can paint of the future is a vision of a product owner. In this vision she explains how an organization or product should look. She indicates what parts of the system need to change (priority) and what efforts can be used to achieve this goal (estimates and commitments).

Product Visioning - How To Possible structures for a visioning exercise are to create an elevator statement or a product vision box . The principle of both exercises is to create a statement that describes the future in terms of desired product features, target customers and key differentiators from previous or competitive products.

Geoffrey Moore uses the following structure in his elevator statement: “For (target customer) who (statement of the need) the (product name) is a (product category) that (product key benefit, compelling reason to buy). Unlike (primary competitive alternative), our product (final statement of primary differentiation).” The product vision describes a desired state that is 12 months or more in the future. Further planning (design) activities will detail the vision, and may divert from the vision because the future will bring us a changed perspective on the market, the product and the required efforts to make the vision reality.

Product Roadmap - Level 2 The era of large-scale projects that deliver results in years is behind us. Customers demand more frequent changes and typical time-to-market timeframes are measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps, into thinking of a road towards the final product. Just like a journey is planned upfront and shared with the fellow travelers, a product roadmap is created and communicated to fellow delivery people.

The goals for doing so are for the product owner to:
• Communicate the whole
• Determine and communicate when releases are needed
• Determine what functionality is sufficient for each release
• Focus on business value derived from the releases

The delivery team on the other hand will:
• See the whole
• Learn about the steps to realize the vision
• Learn the business priorities
• Provide technical input to the roadmap
• Provide estimates for the projected features

Product Roadmap - How To The creation of the roadmap is largely driven by the product owner (or product owner team). This stage of the program has limited influence of technology constraints. In a meeting or series of meetings, the roadmap will be drawn by the product owner. This can be quite literally, through a graphical representation of the releases, or more formally in a written document outlining the dates, contents and objectives of the foreseen releases.

Product Backlogs In anticipation of the next planning stage (release planning) a list of desired features needs to be built - the product backlog. In its simplest form, such a backlog is a table (spreadsheet) of product requirements, briefly described so a delivery team can provide estimates for the realization of each feature. Most importantly, the list has to be prioritized. The success of an Agile development project depends on the early delivery of the highest priority features. Since the success of a project is measured in business terms, the prioritization of the feature list is the responsibility of the business, i.e. the product owner. Interaction with the delivery teams is required. Without a discussion of the features it will be hard for the delivery team to produce estimates that have an acceptable inaccuracy. Characteristics of a product backlog include:

• One product backlog for all teams (see the whole)
• Large to very large features (up to 20 ‘person days’ to deliver a feature)
• Feature priority based on business priorities (discovered through market research)
• Technology features (sometimes called non-functional features, work required to make the product work in a desired way, e.g. the implementation of a certain DBMS in order to warrant a certain system performance) are limited to those that have a direct impact on the success of the product in the market.