Daily Scrum

Once the Sprint has started, the Team engages in another of the key Scrum practices: The  Daily Scrum. This is a short (15 minutes or less) stand-up meeting that happens every workday at an appointed time, and everyone on the Scrum Team attends; in order to keep it brief, everyone stands (hence “stand-up meeting”). It’s the team’s opportunity to report to itself on progress and obstacles. One by one, each member of the team reports three (and only three) things to the other members of the team: What they were able to get done since the last meeting; what they’re hoping to get done by the next meeting; and any blocks or impediments that are in their way. The ScrumMaster makes note of the blocks, and then helps team members to resolve them after the meeting. There’s no discussion during the Daily Scrum, just the reporting of the three key pieces of information; if discussion is required, it takes place right after the meeting. The Product Owner, Managers, and other stakeholders can attend the meeting, but they should refrain from asking questions or opening discussion until after the meeting concludes – everyone should be clear that the team is reporting to each other, not to the Product Owner, Managers or ScrumMaster. Some teams find it useful to have the Product  Owners join and give a brief daily report of their own activities to the team, though this is at the team’s discretion.
After the meeting, the team members update the amount of time remaining to complete each of the tasks that they’ve signed up for on the Sprint Backlog .Following this update, the ScrumMaster adds up the hours remaining for the team as a whole, and plots it on the
Sprint Burndown Chart. This graph shows, each day, how much work (measured in hours or days) remains until the team’s commitment is completed. Ideally, this should be a downward sloping graph that is on a trajectory to hit zero on the last day of the Sprint. And while sometimes it looks like that, often it doesn’t. The important thing is that it show the team their actual progress towards their goal – and not in terms of how much time has been spent so far (an irrelevant fact, as far as Scrum is concerned), but in terms of how much work remains – what separates the team from their goal. If the curve is not tracking towards completion at the end of the Sprint, then the team needs to either pick up the pace, or simplify and pare down what it’s doing. While this chart this can be maintained electronically using Excel, many teams find it’s much more effective to do it on paper taped to a wall in their workspace, with updates in pen; this low-tech solution is fast, simple, and often more visible than an electronic one.

Sprint Retrospective

Following the Sprint Review, the team gets together for the Sprint Retrospective. This is a practice that some teams skip, and that’s unfortunate, because it’s the main mechanism for taking the visibility that Scrum provides into areas of potential improvement, and turning it into results. It’s an opportunity for the team to discuss what’s working and what’s not working, and agree on changes to try. The Scrum Team, the Product Owner, and the ScrumMaster will all attend, and a neutral outsider will facilitate the meeting; a good approach is for
ScrumMasters to facilitate each others’ retrospectives, which enables cross-pollination among teams.
A simple way to structure the Sprint Retrospective is to draw two columns on a whiteboard, labeled “What’s Working Well” and “What Could Work Better” – and then go around the room, with each person adding one or more items to either list. As items are repeated, checkmarks are added next to them, so the common items become clear. Then the team looks for underlying causes, and agrees on a small number of changes to try in the upcoming Sprint, along with a commitment to review the results at the next Sprint Retrospective.
A very useful practice at the end of the Retrospective is for the team to label each of the items in each column with either a “C” if it is caused by Scrum (in other words, without Scrum it would not be happening), or an “E” if it is exposed by Scrum (in other words, it would be happening with or without Scrum, but Scrum makes it known to the team), or a “U” if it’s unrelated to Scrum (like the weather). The team may find a lot of C’s on the “What’s Working” side of the board, and a lot of E’s on the “What’s Not Working”; this is good news, even if the
“What’s Not Working” list is a long one, because the first step to solving underlying issues is making them visible, and Scrum is a powerful catalyst for that.

SCRUM Methodology

The system development process is complicated and complex. Therefore maximum flexibility and appropriate control is required. Evolution favors those that operate with maximum exposure to environmental change and have optimised for flexible adaptation to change. Evolution deselects those who have insulated themselves from environmental change and have minimized chaos and complexity in their environment.
An approach is needed that enables development teams to operate adaptively within a complex environment using imprecise processes. Complex system development occurs under rapidly changing circumstances. Producing orderly systems under chaotic circumstances requires maximum flexibility. The closer the development team operates to the edge of chaos, while still maintaining order, the more competitive and useful the resulting system will be. Langton has modeled this effect in computer simulations13 and his work has provided this as a fundamental theorem in complexity theory.
Methodology may well be the most important factor in determining the probability of success. Methodologies that encourage and support flexibility have a high degree of tolerance for changes in other variables. With these methodologies, the development process is regarded as unpredictable at the onset, and control mechanisms are put in place to manage the unpredictability.
If we graph the relationship between environmental complexity and probability of success with a flexible methodology that incorporates controls and risk management, the tolerance for change is more durable.

Current Development Situation of SCRUM

Systems are developed in a highly complicated environment. The complexity is both within the development environment and the target environment. For example, when the air traffic control system development was initiated, three-tier client server systems and airline deregulation did not have to be considered. Yet, these environmental and technical changes occurred during the project and had to be taken into account within the system being built.
Environmental variables include:
·  Availability of skilled professionals - the newer the technology, tools, methods, and domain, the smaller the pool of skilled professionals.
·  Stability of implementation technology - the newer the technology, the lower the stability and the greater the need to balance the technology with other technologies and manual procedures.
·  Stability and power of tools - the newer and more powerful the development tool, the smaller the pool of skilled professionals and the more unstable the tool functionality.
·  Effectiveness of methods - what modeling, testing, version control, and design methods are going to be used, and how effective, efficient, and proven are they.
4
·  Domain expertise - are skilled professionals available in the various domains, including business and technology.
·  New features - what entirely new features are going to be added, and to what degree will these fit with current functionality.
·  Methodology - does the overall approach to developing systems and using the selected methods promote flexibility, or is this a rigid, detailed approach that restricts flexibility.
·  Competition - what will the competition do during the project? What new functionality will be announced or released.
·  Time/Funding - how much time is available initially and as the project progresses?
How much development funding is available.
·  Other variables - any other factors that must be responded to during the project to ensure the success of the resulting, delivered system, such as reorganizations.
The overall complexity is a function of these variables : complexity = f(development environment variables + target environment variables) where these variables may and do change during the course of the project.
As the complexity of the project increases, the greater the need for controls, particularly the ongoing assessment and response to risk.
Attempts to model this development process have encountered the following problems:
·  Many of the development processes are uncontrolled. The inputs and outputs are either unknown or loosely defined, the transformation process lacks necessary precision, and quality control is not defined. Testing processes are an example.
·  An unknown number of development processes that bridge known but uncontrolled processes are unidentified. Detailed processes to ensure that a logical model contains adequate content to lead to a successful physical model is one such process.
·  Environmental input (requirements) can only be taken into consideration at the beginning of the process. Complex change management procedures are required thereafter.
Attempts to impose a micro, or detailed, methodology model on the development process have not worked because the development process is still not completely defined. Acting
5 as though the development process is defined and predictable results in being unprepared for the unpredictable results.

Overview of SCRUM

Our new approach to systems development is based on both defined and black box process management. We call the approach the SCRUM methodology (see Takeuchi and Nonaka, 1986), after the SCRUM in rugby -- a tight formation of forwards who bind together in specific positions when a scrumdown is called.

As will be discussed later, SCRUM is an enhancement of the iterative and incremental approach to delivering object-oriented software initially documented by Pittman9 and later expanded upon by Booch. It may use the same roles for project staff as outlined by Graham, for example, but it organizes and manages the team process in a new way.

SCRUM is a management, enhancement and maintenance methodology for an existing system or production prototype. It assumes existing design and code which is virtually always the case in object-oriented development due to the presence of class libraries.
SCRUM will address totally new or re-engineered legacy systems development efforts at a later date.
Software product releases are planned based on the following variables :
·  Customer requirements - how the current system needs enhancing.
·  Time pressure - what time frame is required to gain a competitive advantage.
·  Competition - what is the competition up to, and what is required to best them.
·  Quality - What is the required quality, given the above variables.
·  Vision - what changes are required at this stage to fulfill the system vision.
·  Resource - what staff and funding are available.
These variables form the initial plan for a software enhancement project. However, these variables also change during the project. A successful development methodology must take these variables and their evolutionary nature into account.

Scrum and CMMI Level 5: The Magic Potion for Code Warriors

Projects combining agile methods with CMMI are more successful in producing higher quality software that more effectively meets customer needs at a faster pace. Systematic Software Engineering works at CMMI level 5 and uses Lean Software Development as a driver for optimizing software processes. Early pilot projects at Systematic showed productivity on Scrum teams almost twice that of traditional teams. Other projects demonstrated a story based test driven approach to software development reduced defects found during final test by 40%.

We assert that Scrum and CMMI together bring a more powerful combination of adaptability and predictability than either one alone and suggest how other companies can combine them.

Successful software development is challenged by the supplier’s ability to manage complexity, technology innovation, and requirements change. Agile and CMMI methods both address these challenges but have very different approach and perspective in methods applied.

Management of complexity requires process discipline while management of change requires adaptability. CMMI provides process discipline and
Scrum enhances adaptability. This paper provides an analysis of the effect of introducing Agile practices into a CMMI Level 5 company.

Systematic made a strategic decision to use Lean as the dominant paradigm for future improvements after achieving CMMI level 5. Lean has demonstrated notable results for many years in domains such as auto manufacturing, and due to its popularity, has been adapted to other domains, including product and software development. Systematic identified Lean
Software Development [3] as the Lean dialect most relevant to Systematic.
Applying Lean Software Development, as a driver for future improvements in a company appraised to
CMMI level 5, depends on the adoption of a lean and agile mindset in the implementation of the CMMI processes, and Systematic placed special focus on implementing the Lean change in the spirit of the Agile
Manifesto.
Lean competencies were established, through handing out handout of books, formal and informal training, and walk-the-talk activities. Project Managers were trained in Lean Software Development, and Mary
Poppendieck visited Systematic to present a management seminar on Lean Software Development.
This seminar established an understanding of the
Agile and Lean mindset. The causal dependencies between the principles and tools in Lean Software
Development were analyzed, by Carsten Jakobsen appointed change agent for Lean, and resulted in the model shown in Table 1. The model groups the thinking tools (T) and principles (P) from Lean
Software Development according to causal dependencies, where elements to the right depend on one or more elements to the left. The model facilitated a way to prioritize what thinking tools to focus on. Left most tools were considered good candidates to start with.
The most important input for selection of what
Lean tools to consider first. was an analysis showing improvement opportunities with a potential good costbenefit.
Internal studies at Systematic show that the cost of fixing a defect increases from 1.6 hours when detected in the coding phase, to 12 hours when detected in the testing phase and 23.7 hours when detected in the maintenance phase. Therefore improvements that could eliminate or move any defects to earlier phases have the potential for high leverage.
We also observed that our focus on quality, gradually had led to longer test cycles.