Context: We all know that scrum scales by having multiple scrum teams rather than having one large team.  In practice, it may so happen that each team is so focussed on what it is considered its own goals and there is possibility that the team may miss “Whole-Team’s” shared goal. This is where, Scrum of Scrum helps coordinate the work among scrum teams so that all involved scrum teams work towards shared goal through resolving their mutual dependencies and integrate their work effectively keeping the shared goal in mind.

Scrum of Scrum – The Purpose:  Scrum of scrum meetings help improve coordination among cluster of scrum teams working for a shared goal. These meetings will allow scrum teams to discuss their dependencies, discuss any overlap among their work increments focusing especially on areas of overlap and integration.

scrum of scrum

 

Problem Solving is the key: Unlike daily stand up meetings, Scrum of Scrum meetings are problem solving meetings. Thus, it is recommended to block 30 to 60 minutes for this this meeting on the calendar. If an issue is brought to the attention of this group, issues to be addressed with the people present. Incase, the issue cannot be addressed immediately (either because right participants are not present or more information is needed), it is placed in issue backlog for scrum of scrum group. Kindly understand that large number of scrum team members will be waiting for the resolution of issues present in the issue backlog. Thus, scrum teams collaboratively will work towards resolution.

Attendees for this meeting: Each scrum team will designate one or two persons to attend a scrum of scrum meeting. It is recommended to designate one technical contributor and one scrum master. The team will choose their representative based on who will understand and comments raised in Group Issue log. Thus, team can rotate their representatives to the scrum of scrum meetings

Frequency: Team chooses the frequency for scrum of Scrum. It can range daily once to twice a week. To start with, I recommend having these meetings thrice a week (Monday-Wednesday-Friday) or twice a week (Tuesday-Thursday).

Duration for the meeting: 30 to 60 Minutes

Agenda for this meeting:

First Fifteen Minutes – Each Participant answers below 5 questions:

  1. What has your team done since we last met?
  2. What will your team do before we meet again?
  3. Impediments faced by your team currently and who can help you resolve these?
  4. Are you about to put impediments in another team’s way so that other teams are prepared?
  5. Status Update on the actions owned by your team from the last Scrum of Scrum meeting?

Rest 45 Minutes: Resolve Problems and discuss items on an issue backlog

Note: Actions are assigned only to the respective teams not to the individuals in the group’s issue backlog.

Guidelines:

  • Team names to be referred in the meetings instead of individual names.
  • Backlog of issues to be maintained and the same needs to be current after every Scrum of Scrum Meeting.
  • Scrum of scrum meetings can scale even further where each scrum of scrum meetings can nominate one to two individuals to scrum of scrum of scrum meetings at the global level.
Advertisements

Crystal

Crystal is family of methods designed for projects ranging from those run by small teams developing low-criticality systems (Crystal Clear) to those run by large teams building high-criticality systems (Crystal Magenta).  Crystal Clear is aimed at small projects with core team size of one to six people.  For large scale projects and high criticality systems, Crystal Magenta is suggested.

The Crystal methodologies embrace and promote many other agile principles as well, including:

  1. Frequent Delivery of build increments.
  2. Reflective environment where periodic ways of continuous improvement methods are adopted
  3. Team members are collocated to allow them efficiently share the information
  4. Personal Safety :  Emphasizes the need to create an environment where people can safely raise issues or questions
  5. Focus: This means team members know what to work on and have the time and peace of mind to work on it.
  6. Easy Access to expert users: Through such access, the team can get up-to-date requirements and rapid feedback.
  7. Technical environment:  Crystal methods rely on automated tests, configuration management and frequent integration.

Dynamic System Development Method (DSDM) is centered on eight principles. Although these principles were created before the Agile Manifesto was written, they are closely aligned with Agile Manifesto. The egith principles are:

  1. Focus on the business need
  2. Deliver on time
  3. Collaborate
  4. Never compromise on quality
  5. Build incrementally from foundations
  6. Develop iteratively
  7. Communicate continuously and clearly
  8. Demonstrate Control

DSDM helped to popularize early architectural considerations, agile sustainability filters and agile contracts.

Feature Driven Development is a simple- to-understand yet powerful approach to building products or solutions.  The project team will first develop an overall model for the product, build a feature list, and plan the work. The team then moves through design and build iterations to develop the features. It consists of below steps

1. Develop an Overall Model

2. Build Feature List

3. Plan by Feature

4. Design By Feature

5.  Build By Feature

(Steps 4 and 5 will be iterated)

FDD recommends a set of good practices, derived from Software engineering. These practices include:

  1. Domain Object Modelling: In this practice, teams explore and explain the domain (or business environment) of the problem to be solved.
  2. Developing by feature: This practice involves breaking functions down into two-week or shorter chunks and calling them features.
  3. Individual Class (code) ownership: With this practice, areas of code have a single owner consistency, performance and conceptual integrity.
  4. Feature teams: Small and dynamically formed team specialized in implementation of chosen features.
  5. Inspections: These are reviews that help ensure good-quality design and code
  6. Configuration Management: This practice involves labelling of code, tracking changes and managing the source code
  7. Regular builds: Through regular builds, the team makes sure the new code integrates with existing code.
  8. Regular builds to ensure the new code integrates with existing code. This practice also allows them to easily create a demo
  9. Visibility of Progress and results: This practice tracks the progress based on completed work.

Extreme Programming is a software-development-centric agile method. The core values of this methodology are:

  1. Simplicity:  The team should keep the phrase “Find the simplest thing that could possibly work” in mind and build that solution first. Thus, this value addresses complexity, extra features and waste.
  2. Communication:  Ensure all team members know what is expected of them and what other people are working on.
  3. Feedback: The team should get early feedback. Failing first can be useful, especially if in doing so we get new information while we still have time to improve the product.
  4. Courage: It takes courage to allow our work to be entirely visible to others.
  5. Respect: Respect is essential on XP projects where people work together as a team and everyone is accountable for the success or failure of the project.  Respect team member differences

In XP, lightweight requirements are known as “User stories”. User stories are used in planning releases and iterations.  Iterations are typically two weeks long, and developers work in pairs to write code during these iterations.  All Software developed is subjected to rigorous and frequent testing. Then upon approval by the customer, the software is delivered as small releases.

While scrum focuses on “how to accomplish the complex scope through incremental iterations, XP focuses on what good software development practices to implement.

XP Practices:

XP Practices

Fine scale Processes

1. Pair Programming: In XP, production code is developed by two developers working as a pair and provides real time reviews of the software as it emerges. It saves time because the pairs catch issues early and there is a benefit in having the larger knowledge of two people. Working in pairs also helps spread knowledge about system through the team. Pair programming means that all code is produced by two people programming on one task on one workstation. One programmer has control over the workstation and is thinking mostly about the coding in detail. The other programmer is more focused on the big picture, and is continually reviewing the code that is being produced by the first programmer. Programmers exchange roles after  agreed periods.

The pairs are not fixed; programmers switch partners frequently, so that everyone knows what everyone is doing, and everybody remains familiar with the whole system, even the parts outside their skill set. This way, pair programming also can enhance team-wide communication.

2. Planning Games:  XP has two planning activities, or planning games – Release planning and Iteration planning.  A Release is a push of new functionality all the way to production user. A project has typically one or more releases.  Iterations are short cycled development cycles within a release that scrum calls “sprints”.

3. Customer Tests: Customer develops the Acceptance Tests to be performed . It is to help the team to confirm that the software is working.

4. Test Driven Development: Almost all the product organizations today are struggling with lots of technical debt where we have lot of code in place that is not testable and scalable.  We want to implement TDD because we want to build the product that is just sufficient to meet the necessary tests expected. This thought process when clubbed with refactoring will make our code testable, scalable and flexible.

What is Test Driven Design? Test Driven Development advocates “no code is added without first writing an automated test”

To drive code with tests, a developer starts by writing a test for the code he wants to write. He runs the test to check that if it really does fail. Now He writes the minimum code to make the test pass. After each new test passes, he looks for opportunities to consolidate the code and eliminate duplication. He builds up the code by repeating these steps.

Developing code this way encourages a developer to think about solving one small problem at a time. It also helps the developer work from the outside in rather than inside out, because for each test they consider the interface of the code before its internal logic, because applying TDD drives the developer to make small design decisions as they go, it’s also sometimes referred to as test-driven design.

5. Whole Team: All the contributors sit together in the same location, as members of a single team. Within XP, the “customer” is not the one who pays the bill, but the one who really uses the system. XP says that the customer should be on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator.

Continuous Process

6. Continuous integration: Integration involves bringing the code together and making sure it all compiles and work together. This practice is critical, because it brings problems to the surface before more code is built on top of faulty or incompatible designs.

XP employs a continuous integration, which means every time  a programmer checks in code to the code repository (typically several times a day), integration tests are run automatically. Such tests highlight broken builds or problems with integration, so that problem can be addressed immediately.

Thus, the development team should always be working on the latest version of the software. Since different team members may have versions saved locally with various changes and improvements, they should try to upload their current version to the code repository every few hours, or when a significant break presents itself. Continuous integration will avoid delays later on in the project cycle, caused by integration problems.

7. Small releases: The delivery of the software is done via frequent releases of live functionality creating concrete value. The small releases help the customer to gain confidence in the progress of the project.

8. Refactoring:  It is process of improving the design of existing code without altering the external behaviour or adding new functionality. By keeping the design efficient, changes and new functionality can easily be applied to the code. Refactoring focuses on removing duplicated code, lowering coupling (dependent connections between code modules), and increasing cohesion. When “changes in one part of the code affect lots of other parts”, the system is telling you to refactor your code by changing the architecture, making it simpler and more generic.

Shared Understanding:

9. Coding standard– Coding standard is an agreed upon set of rules that the entire development team agree to adhere to throughout the project.

10. Collective Code Ownership: Multiple people work on all the code which results in increased visibility and knowledge of the code base. This practice leads to higher level of quality, with more people looking at the code. There is greater chance that defects will be discovered. There is also less of an impact to the project if one of the

11. Simple Design: By focussing on keeping the design simple but adequate, XP teams can develop quickly and adapt as necessary. The design is kept appropriate for what the project currently requires. It is then revisited iteratively and incrementally to ensure it remains appropriate. XP follows a deliberate design philosophy that leans toward, “what is the simplest things that could work?” as opposed to complexity structures that attempt to accommodate possible future flexibility. Since code bloat and complexity are linked to many failed projects, simple design is also a risk mitigation strategy. Thus, XP practices advocate programming only what is needed today, and implementing it as simply as possible,

12. The system metaphor is a story that everyone – customers, programmers, and managers – can tell about how the system works. It’s a naming concept for classes and methods that should make it easy for a team member to guess the functionality of a particular class/method, from its name only. For example a library system may create loan_records(class) for borrowers(class), and if the item were to become overdue it may perform a make_overdue operation on a catalogue (class). For each class or operation the functionality is obvious to the entire team.

Programmer Welfare

13. Sustainable Pace: XP recognizes that the highest level of productivity is achieved by a team operating at a sustainable pace. While periods of over time might be necessary, repeated long hours of work are unsustainable and counterproductive.  The practice of maintaining a sustainable pace of development optimizes the delivery of long term value.

What is Agile?

The term agile was not chosen at random; at the Utah workshop in 2001 where a group of modern methodology leaders convened, two alternative names were considered: adaptive or agile. Both emphasize flexibility.   Oxford dictionary defines the word agile as “ability to move quickly and easily”.  Thus agility is our flexibility to move quickly and easily so that we become light weighted and adaptable to embrace the change. Let us now contemplate the need for the change

Why Change? Let us for a moment introspect why many software development organizations are striving to be agile. Software development enterprises are seriously concerned with their existing development models as they are not able to deliver their product increments to market on time, unable to cope up with fast changing customer expectations and thus losing their market share to their competition. When enterprises are on the edge of losing their very existence itself, strategists are doing everything necessary to embrace the change.  Technically speaking, traditional development with single-component silo skill set groups, delayed or weak feedback loops, front loaded predictive planning, and a sequential flow from analysis to test is not very successful in today’s volatile world. In this approach, real working software is not visible till late in the game. Also, processes and tools are taken front seat and we find little or insufficient interactions among the end user who requested the change and the developer who is building the product. Traditional approach focuses more efforts on contract negotiation and adherence and we see little or no collaboration with end customers. In nutshell, traditional software development models emphasis following the set plan and makes it quite difficult for the team to respond to the change. These are impacting Return on Investment of enterprises predominantly because of below problems.

  1. Releases are taking too long time
  2. Stabilization takes too long time
  3.  Changes are hard to make
  4. Quality is failing
  5. Teams relaxes initially and works extended hours in the final days – This hurts employee morale and employee satisfaction
  6. Lack of transparency
  7. Lack of ability to improve
  8. Reduction in flexibility
  9. Increase in business and technical risks

Embrace the change: In this process, I must want to acknowledge the quote from Jack Welch.

Willingness to change is a strength even if it means plunging part of the company into total confusion for a while.—Jack Welch

Agile Manifesto signed by Agile Alliance group:  On February 11-13, 2001, at Utah, 17 subject matter experts  practicing  Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened. “A Manifesto for Agile Software Development” was emerged and signed by all participants. The term “Agile” came from Martin Fowler. The group was named as “The Agile Alliance”. They formed Agile Manifesto that says

Agile Manifesto

Effective Agile Implementation requires us implement below model. That is we got to implement Agile Values and principles  for sure in the process of uncovering better ways of developing software through Agile Methods.

Agile implemetation

Agile development is based on sets of values that support and encourage being agile. Let us visit Four values of the agile manifesto in detail:

  1. Individuals & Interactions over Processes & Tools: Individuals are the ultimate source of value! – Engage them early :: Focus Team attention on the Individuals and interactions involved ::  It’s People – Projects are undertaken by people; Problems are better solved by People rather than Processes or tools; Scope is debated by People and Acceptance of the Product is done by People….:: Build Productive and effective interactions among the Project Team
  2. Working software over comprehensive documentation: Delivery is the primary goal of the Team :: Working Software to be the basis for Go/No Go Decisions
  3. Customer collaboration over contract negotiation: See from the  Customer’s eyes and Work with the customers :: Collaborate, and deliver the product as per the customer vision :: Maintain healthy and cooperative relationships
  4. Responding to change over following a plan: World is so Dynamic People change their priorities very often :: Change is a fact and inevitable. Honor changes as and they come :: Adapt, inspect, and Improve; continuously

Agile Principles: ( refer www.agilemanifesto.org/principles)

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

What is agile methodology? An agile methodology—such as Scrum—is a lighter-weight approach to complex software development. Agile methodologies promote proven product development concepts in a simple framework, including long lived self-organized cross functional teams, short iterative full life cycle feedback loops and lowering cost of change thereby increasing agility and feedback, enable earlier ROI and thus reduce the risks. In essence,

  • The team is given clear goals
  • The team organizes itself around the work
  • The team regularly delivers the most valuable features
  • The team receives the feedback from people outside it
  • The team reflects on its way of working in order to improve
  • The entire organization has visibility into team’s progress
  • The team and management honestly communicate about progress and risks.

This way of working is based upon values of self-respect, respect for others trust and courage.

Why Becoming Agile is worth It:

Becoming Agile is worth because it brings Agile methodologies feature self-organized teams that are empowered to achieve specific business objectives. Agile framework is iterative and incremental in nature and brings you closer to what the customer wants by involving the customer at every step. Agile is all about empowering the team and getting closer to what the customer wants. It drives the decision-making process lower in an organization, making that organization more responsive and adaptive. It relies on lean governance (management) and more disciplined. Agility is the flexibility to deliver customer value with focus on:

  • Using Incremental and Iterative approach, Agile focuses on Rapid and Frequent deliverables of shippable Working Product increment.
  • Time Boxed in nature
  • Rapid and Flexible response to change
  • Open Communication and Collaboration at all levels
  • Rolling wave Planning
  • Long lived self-organized cross functional teams – A leadership philosophy that encourages teamwork, self-organization and accountability.
  • Promotes Frequent Inspections and Adaptions
  • High Return on Investment
  • Lowers the Cost of the work.

Survey Results: The 7th annual “State of Agile Development” survey was conducted between August 9th and November 1, 2012, Sponsored by Version One, the survey polled 4048 individuals. The results showed interesting insights.

Why Organizations are adopting Agile?

    1. Manage Changing Priorities
    2. Accelerate time to Market
    3. Increase Productivity
    4. Enhance Software Quality
    5. Better alignment IT/Business
    6. Project Visibility
    7. Reduce Risk
    8. Simplify Development Process
    9. Enhance Software maintainability/extensibility
    10. Improved Team morale
    11. Reduce Costs
    12. Improve engineering discipline
    13. Manage Distributed Teams

Benefits experienced with Agile adoption

    1. Ability to manage changing Priorities
    2. Increased Productivity
    3. Improved project visibility
    4. Improved Team Morale
    5. Enhanced Software Quality
    6. Reduce Risks
    7. Faster time to Market
    8. Better alignment between IT and Business Objectives
    9. Improved/increased engineering discipline
    10. Enhanced Software maintainability/extensibility
    11. Manage Distributed Teams

 In essence, becoming Agile is worth it because we can observe below gains:

    1. Higher productivity and lower costs
    2. Improved employee engagement and job satisfaction
    3. Faster time to market
    4. Higher quality
    5. Improved stakeholder satisfaction
    6. What we’ve been doing no longer works

Tag Cloud