Book: Scaling Software Agility

Scaling Software Agility“Scaling Software Agility: Best Practices for Large Enterprises” by Dean Leffingwell.

I bought this book several years ago and finally finished reading it. The author has a new book scheduled to publish by end of the year, which will be a nice update. If you are new to Agile, here are a few links to checkout:

Here are some notes from the book:

  • “teams will typically take twice as long as they estimate to reach the desired result. This is partly attributable to the complexity of the planning in waterfall projects being exponentially harder than it seems because different parts of the system ( or parts of the team) transition between phases at different times.”
  • “Agile avoids virtually all of these underlying assumptions of the waterfall model and address these problems in the following ways:
    • We do not assume that we, or our customers, an fully understand all the requirements, or that anyone can possibly understand them all up front.
    • We do not assume that change will be small and manageable. Rather we assume that change will be constant, and we deliver in small increments to better track change.
    • We do assume that system integration is an important process and is integral to reducing risk. Therefore, we integrate from the beginning and we integrate continuously. …
    • We do not assume that we can develop new, state-of-the-art unproven, innovative, and risk-laden software projects on a fixed-functionality and fixed-schedule basis. Indeed, we assume that we cannot. Instead, we assume that we can deliver the most important features to our customer earlier, rather than later, than the customer might have expected. In so doing, we can get immediate feedback on whether we are building the right solution.”
  • Changing paradigms in agile:changing paradigms in agile
  • “Strict command-and-control cultures also can inhibit agile. If management dictates the letter and law of all processes and technologies, teams will not be able to evolve to the self-organizing and constantly changing teams that characterize agile, nor will they be able to select the optimum technical path to a solution if they are directed by others to a different approach.”
  • “Unit testing, acceptance testing, and performance-and reliability-level testing are driven to occur inside each iteration.”
  • “In reality, the requirements versus design activities must be iterative. Requirements discovery, definition, and design decisions are circular. The process is a continual give and take, in that: Requirements cause us to consider certain design options. Design options cause us to reconsider requirements.”
  • Scrum of Scrums: “This team consists of the Agile/Scrum Masters from the various component teams, and they also hold a daily stand-up equivalent, typically either in person or via teleconference every day.”
  • Steering Committee: “Members of this team may include some or all of the Agile/Scrum Masters, but it also includes others representatives of the enterprise.” This may include, enterprise architect, VP/director level managers, system-level QA, uber-product owners/business owners.
  • “The steering committee meets weekly and address the following questions:
    • What is the status of the current release?
    • What coordination must we provide to facilitate progress?
    • Do the team still have a clearly understood mission?
    • Are we likely to meet the release schedule, and if not, how do we adjust scope to assure that we can meet the release date?
  • “those structural boundaries between the test and development organizations, tended to block the high velocity of communication necessary for more concurrent testing. Even worse, they also serve as impediments to effective process improvement that could have eliminated the vicious cycle to begin with.”
  • “One reviewer noted, ‘In some companies that are resistant to change, getting them to adopt the creation of unit and acceptance tests first, instead of waiting for the code or mapping to a classic requirement, may be one of the most fundamental ways of streamlining large-scale development and making those teams more agile.”
    Agile Testing Strategy
  • Sample iteration assessment quantitative metrics
    • # stories (loaded at beginning of iteration)
    • # accepted (defined/build/tested and accepted)
    • % accepted
    • # not accepted (not achieved within iteration)
    • # pushed to next (rescheduled in next iteration)
    • # not accepted: deferred to later date
    • # not accepted: deleted from backlog
    • # added during iteration, should typically be 0)
    • Defect count at start iteration
    • Defect count at end of iteration
    • # new test cases
    • # new test cases automated
    • # new manual test cases
    • Total automated tests
    • Total manual tests
    • % tests automated
    • Unit test coverage percentage
  • Qualitative Assessment
    • “What did we do well on this iteration?”
    • “What did not go so well on this iteration?”
  • Extending Architectural Runway
    • “Constant, incremental refactoring of the application so it evolves to better meet the new requirements needs, and
    • Constantly extending the architectural runway through modeling, research spikes, ‘hackthons’ (short periods of coding activity to test new theories and technologies), or other methods.”
  • “One way that teams approach the extension of architectural runway is to use this natural rhythm to their advantage and to ‘program’ design spikes into each iteration. Design spikes are activities intended to address design challenges, architectural extensions, and the impact of new technologies or to explore critical problems with the existing solution.”
  • “In agile, most technical decisions are postponed until the last responsible moment (LRM).”
  • “After all, it doesn’t really matter whether we can describe the story well verbally or in writing–what matters is whether the implementation of the story meets objectives of the user.”
  • INVEST for the basic attributes of a good user story:
    • “Independent. Whenever possible, stories should be written to be independent of other stories. Although this is not always possible, independent stories are far easier to implement, estimate, and test, and they minimize dependencies among teams.
    • Negotiable. Stories differ from our traditional notion of requirements in that user stories are negotiable. Negotiation between the development team and the product owners on the requirements continuum is integral to agile efficiency.
    • Valuable. Most stories will directly affect the user or purchaser, and the value to the user is obvious in well-written stories. However some user stories may reflect constraints on the system or architectural concerns, and these stories are important as well. When possible, however, it is best to keep technology assumptions and constrains out of the user stories.
    • Estimatable. Good user stories are estimatable, and they can be analyzed and estimated by the team with a reasonable degree of acuracy.
    • Small. Each user story should be sized to fit within an iteration and will typically require no more than a few person-days to implement and test. Larger, compound, complex stories should be divided into multiple stories that are required to realize the future.
    • Testable. Stories should be written so that the team can understand when the story is complete and can be accepted within the iteration. In some methods, the acceptance test itself is included with the story or attached to the story via an automated mechanism. In this way, the story and the acceptance test are part and parcel of the understanding and the implementation.”
  • “use cases often include preconditions and postconditions that define the required system states before and after the use-case execution.”
  • “Instead, management must put a stake in the ground and mandate to the teams: We will ship this often, and we will meet these dates. However, in so doing, management must also recognize that specific decisions regarding individual component functionality must be left to the teams. Otherwise, everything is fixed: functionality, resources, and schedule. The result cannot be an agile process, and the teams are likely to fail to deliver.”Synchronized Agile Release Train
  • Managing Interdependencies: “insisting on early and continuous integration is the most constructive move of all. For as continuous integration is accomplished at this highest system level, issues with the interfaces will expose themselves very quickly, and the component teams can adjust their course of action as necessary to minimize the risk and achieve the objectives.”
  • “Designating an Agile Evangelist This position was responsible for coordinating the training and rollout process and helping to resolve issues and facilitate communications. The agile evangelist also acted as Scrum master for the ‘scrum of scrums’ as the need to coordinate multiple, fast-moving component teams become obvious.”
  • “Reorganizing Around Agile Teams and Components As the company became more familiar with agile development, they reorganized the development teams around the agile process by assigning full accountability for the successful implementation of components to specific teams. Each team included a Scrum Master, developers, product manager, test/QA, and documentation resources.”
  • “Continuous Integration Is Critical to System Quality Over a period of many months, the teams built a continuous integration and test environment that reduced the time it took to produce a system-level build and smoke test from two months to one hour.”
  • “The requirement architect’s responsibility is to take the high-level features defined by product management and decompose them, on a just-in-time basis, into the more detailed requirements and stories needed to drive iteration planning and development.”
  • “The higher frequency of release cycles means that the enterprise can minimize or avoid the ‘patch cycle’ wherein pressure builds for defect fixes and minor enhancements on an interim basis. With the old waterfall model, the schedule constraints alone forced intermediate releases (whether we called them that or not), which in turn forced side development projects or special sustaining releases that were outside the normal development (and QA!) rhythm of the teams.”
  • “Scrum has a primary focus on the people, culture, and organizational change aspects of software agility. Indeed, its underlying philosophical basis was delivered in part from methods that unleashed the creativity and power of the ‘learning organization’.”
  • “To ignore this reality and instead take a fixed-plan/function/time/cost approach create a number of organizational problems:
    • Management actually believes that it can predict the cost, delivery schedule, and functionality that will be delivered, and it plans accordingly.
    • Developers and project managers are forced to live a lie: they pretend they can plan, predict, and deliver when they know that is not the case. They build one way but must pretend they build another way. Because of the conflict inherent in this pretense, in the end they are essentially without meaningful controls.
    • By the time the system is delivered, it is often irrelevant or requires significant change.”
  • “The agile trade-off is simple:
    • Know where you are every day with agile and evolve to the best fit for the customer’s real needs.
    • Think you know where you are on your well-formed plan and discover–very much later–that you are very wrong.”
  • “a full scrum implementation may take up to 2 years.”
  • “Scrum cannot be planned for an implemented with checklists, procedures and forms. Scrum is just a simple framework that identifies everything in an organization that gets in the way of optimally building software. The work to manage and remove these impediments represents the difficult part of implementing Scrum, and it is different for every organization because every organization is different.”
  • “You cannot identify all impediments up front because they are embedded in the organization and are therefore too familiar to be identified easily.”
  • Example impediments exposed by Scrum
    • Scrum process
      • People arrive late to daily Scrum and do not support basic discipline
      • Scrum meetings take too long–team is bored and consider the time unproductive
      • Scrum Master dictates design decision or micromanages
      • Teams are too large for effective daily Scrum and sprint planning
      • Teams do not report task-remaining time for burn-down analysis
    • People practices
      • Individuals are interrupted and tasked to work outside the sprint
      • Teams are isolated in cubicles and not in open Scrum area
      • Team members are not accountable for personal sprint commitments
      • Individuals are multiplexed across to many projects and teams
    • Product engineering practices
      • Cross-functional resources for definition, design, implementation, and test are not present on the team
      • Sprints do not fully implement and test potentially deployable increments of customer-valued features
      • product owner is not easily available or not integral to team
      • System integration is not forced at each sprint
      • Product owner won’t split up massive product backlog items to fit within sprint
      • Teams have ineffective resources for automating builds and integrations
      • Features are loaded into sprint after sprint begins
    • Organizational issues
      • Software process organizations enforce ineffective processes
      • Management assumes fixed-price, fixed-time, fixed-functionality delivery posture
      • Software test and/or system QA is separate organization and is not integrated with team
      • Organization rewards individual rather than team behavior
      • Existing rules or software capitalization demand adherence to document-driven, waterfall approaches
      • Teams are not collocated to the maximum extent feasible
      • Teams cannot make small, organizational space and expense decisions needed to do their jobs
  • “In a bottom-up implementation, it takes significant time, at least a year or two, for the practices and benefits of agility to spread throughout the organization and to reach the higher level management layers where the next level of organizational impediments must be addressed. Therefore, effective enterprise agility will take even longer.”
  • Agile Process Assessment Metrics


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s