Evolute Consulting - Architecture & Process

The book is divided into three parts by the author, each of them dealing with agility on a different scale. The first part deals with the history of agile processes, and how they could be improved (into SAFe) to mitigate their pitfalls and shortcomings. The second part deals with practices that apply to teams scaling their agile approach. With the chapters in the second part the book lays the groundwork for later methodologies such as the SAFe framework. And for the final part, the author looks at how to turn the entire enterprise/organization into an agile entity, allowing it to apply the agile practices at all application or system scopes.

The starting point of the book is the “why?”. When we moved from a “code it – fix it – code some more” approach to a waterfall methodology in 1974 with the CapGemini System Development Methodology, it was to formalize and structure the development process to create an increase in quality. This was achieved through the introduction of a structured set of activities (see the illustration below) that relied on four assumptions:

1. There is a reasonably stable set of requirements that can be derived with ample analysis time.
2. During development, changes to these requirements are small enough to be managed without extensive rethinking of the chosen solution.
3. System integration is a relevant and necessary process that is predictable enough through upfront architecture and planning.
4. Software research and innovation needed for the solution can be done in a predicable schedule.

Waterfall Methodology Model

All these assumptions turned out to be untrue to some degree in the face of technological and business changes that are constantly occurring in the reality of today. The main issue with this methodology arose when the project teams couldn’t accurately predict when they would deliver the solution. The need for introducing an agile approach in software development stems from the need of organizations to deliver software more quickly than their competitors, since the characteristics for achieve a “win” in their market segment are perceived to be the following:

• The organizations are often the first to market a specific product or solution.
• The product or solution addresses a pain that the customers are feeling.
• The product or solution has the requisite functionality and quality.
• The organizations adapt more rapidly to changes (both business and technological) than their competitors.

In order to compare the different agile methodologies in the first part, we need common ground. First, let us talk about a proper definition for development agility. The key elements of agile development can be summed up as close collaboration between the different stakeholders, intensive iteration and rapid prototyping, openness to changing requirements, and not wanting to let extensive processes and stacks of formal documentation bog down development. Pouring the essence of these key elements into a proper formulation, I like the proposal of Gwanhoo Lee and Weidong Xia in their 2010 article “Toward Agile” for MIS Quarterly, where they specified the following:

This definition is also used as one of the lynchpins of a PMI article that came out in April 2017 [ Recker, J., Holten, R., Hummel, M., & Rosenkranz, C. (2017). How Agile Practices Impact Customer Responsiveness and Development Success: A Field Study. Project Management Journal, 48(2), 99–121] on the same topic. Here the authors suggest a research model for assessing the different agile methodologies for appropriateness, based on their key characteristics in 3 distinct categories (management practices, development practices and standards/norms). They assess them using a measurement method based on distinct criteria (coverage, measurement, relevance and access), and it is worth reading up on their findings. As a short summary, I have added below a screenshot of the research model they employ.

 
Agile Development Methodologies Research Model

When describing the different agile methodologies (chapter 3 to chapter 6), the book always takes into account the following structure in its argumentation: the key characteristics, the fundamental tenet, the basic values and principles, the key practices, the process model and its applicability. While I will summarize the fundamental tenet, process model and applicability below, the others can be found in this excel document, complete with a mapping onto the highlighted research model.

The fundamental tenet of eXtreme Programming (XP) is that it rejects the principle of Big Up-Front Design (BUFD) that was the cornerstone of the Waterfall methodology. Starting with minimal up-front design, it introduces pair programming, a technique where to developers simultaneously implement functionalities, with a focus on simplicity of code and frequent refactoring. It also promotes Test-Driven Development (TDD), where a unit test is written before the implementation of the software. As to the applicability of the methodology, here are some of the cases it might not easily apply to: projects where cost of change increases exponentially over time, safety-critical systems, solutions requiring formal documentation (for example government regulated), projects where continuous integration and testing is impossible, organizations for which flexible hours are not possible, projects where paired developers cannot physically sit next to each other.

eXtreme Programming Methodology Model

SCRUM is by far the most well-known and most practiced of the agile methodologies. Its fundamental tenet is described in the book as empirical process control. Since software development is inherently complex and unpredictable, so to tackle this problem, SCRUM aims to repeatedly produce acceptable quality implementations by creating visibility on the solution in small, incremental steps, which can be evaluated and inspected, and if need be adapted to the constantly changing needs. This inspection is a double cycle with a daily inspection of what happened yesterday and will happen today, as well as an inspection at the end of a 30-day sprint. The projects unsuited for this methodology are projects with large and distributed teams, organizations that don’t allow team empowerment and self-management, projects where continuous integration and testing is impossible, corporate cultures that resist significant change.

SCRUM Methodology Model

A typical SCRUM team consists of a Product Owner, a Scrum Master and the development team implementing and unit testing the functionalities. A product owner represents the interests of the customers and key users. In addition to this, he is a soundboard for developers to verify their decisions about design against the intent of the user story. A Scrum Master responsible for overseeing and teaching the team the SCRUM principles and best practices as well as eliminating any impediments or blocking issues.

Rational Unified Process (RUP) was developed by the Rational Software Company, that was later bought up by IBM. RUP not only covers the Software Delivery LifeCycle (SLDC), but also a broad range of practices from business modeling to configuration management and project management. It focuses on being a complete methodology with a lot of depth and flexibility. This complexity however does tend to scare people off, who in turn look for simpler methodologies. The fundamental tenet for RUP is iteration. Development of a solution happens iteratively and incrementally through a number of phases as shown in the process model below. The Eclipse community has an open source variant of this methodology called Open Unified Process (OpenUP). Since the methodology can be tailored to fit any type of project or any scope, there are few projects it cannot handle. However, the methodology is best suited for building solutions with high complexity because of its extensive procedures and documentation options.

Rational Unified Process Methodology Model

Chapter 6 of the book groups together a number of light-weight methodologies that aren’t as widespread in use as the previously mentioned agile methodologies: Lean Software Development, Feature-Driven Development (FDD), and the Dynamic Systems Development Method (DSDM). Each of these has some insights and practices that can be assimilated into a methodology for approaching, but most importantly, DSDM with its tenet that requirements cannot ever be fixed, gave us the inverted triangle of project management, where it is no longer the scope of a project that is fixed, with time and resources varying, but where resources and time become fixed to support an ever changing scope.

Of all the paradigms that change in agile development, this is the most essential one. It also gives rise to the practice of working code in a short time box. The team commits itself to delivering small chunks of working code by a fixed date. This fixed span in time will be the time box. This fixed timespan does not only apply to iterations being time-boxed, but also extends to releases being time-boxed, as well as meeting being time-boxed. The reason behind the small development chunks is not only so they become more doable and manageable, but so that these chunks can be estimated and tracked throughout the iteration. As with FDD, it also helps with ownership and accountability of the developed code. The risks associated with smaller chunks are also lessened, and more easily detected.

Other paradigm shifts when switching out waterfall development for agile development are discussed in chapter 7 and include the following:

• Measure of Success: Conformance to plan switches to response to change and working code.
• Management Culture: Command and Control switches to leadership setting the direction and the agile team self-organizes how to achieve as much work as possible in the time frame given.
• Requirements and Design: Big and up-front switches to continuous/emergent/just-in-time design.
• Coding and Implementation: Code all features in parallel and test later switches to code and unit test at same time and deliver serially.
• Test and Quality Assurance: A separate test cycle late in the project switches to continuous, concurrent testing throughout the project.
• Planning and Scheduling: A detailed fixed scope and use of PERT switches to a two-level planning with fixed time, and estimated scope.

In order to successfully scale any of the agile methodologies, there are two types of challenges that need to be tackled: the challenges inherent to the agile methodology caused by the assumptions taken when adopting the methodology (small team size, customer is part of team, collocation, emergent architecture, lack of requirements analysis and documentation specifications, cultural and physical environment), and the challenges that already exist within the organization that is switching to an agile state of mind (process and project management organizations, existing formalized policies and procedures, corporate culture, fixed schedules, fixed functionality mandates, high degree of distribution, people organized by discipline rather than product line, friction between IT departments and business users).

Part two of the book attempts to hand tools and techniques for scaling agile development by having a chapter for each of the seven agile team practices that fit in this mold: Define/Build/Test teams, two-level planning and tracking, mastering the iterations, smaller and more frequent releases, concurrent testing, continuous integration, and regular reflection and adaption.

All user stories and iterations follow the same pattern: define the code, write the code, test the code. This process is concurrent, collaborative, and atomic. It needs to be done completely within one iteration, or not at all. Defining the code is the interaction between product owners, developers and testers about what needs to be developed. This is a feedback loop between requirements laid out by the product owner that cause the consideration of certain design options, and design options that cause us to reconsider requirements. The feedback loop is possible since a team is organized to contain all needed skills for these three steps. Building the code brings with it the possibility for new design options and the resulting feedback. Testing will check whether the intent of the story is still intact. An architect or Quality Assurance team will stand outside of the team, and provide verification of design options against the overall system or enterprise capability map and technical capabilities such as existing performance criteria or other KPI. Essentially all successful teams should have the following characteristics: having the right people on the team (all skills needed), being led and not managed, understanding the mission, communication and collaborating continuously, being accountable for the result.

As the name indicates, the two-level planning consists of a planning with two distinct granularities. Iteration planning is about measuring and landing short iterations (fine-grained). The two-level planning can be extended upon with a third level not mentioned in these chapters, namely the roadmap of the organization.

The fine-grained planning happens at the start of each iteration, with the team holding a planning meeting in which it reviews the prioritized items in the backlog, selects the stories for this iteration, and defines and estimates the associated tasks to complete. In addition to this selection and resulting estimations, it also results in an iteration theme (a statement of what is intended to be accomplished), and documentation of the plan to be put up somewhere visible to the whole team.

The coarse-grained planning consists of measuring and landing releases or phases (coarse-grained). The result of this planning is a release plan that identifies the features, defect fixes, and other work the team hopes to deliver in the upcoming release. It establishes the schedule for the release (duration, end dates of iterations, milestones…). This is coupled with the identification of the skills and thus resources needed for the release, along with estimations on the rate of production. Finally, it also lists the quality and readiness criteria to which the release will be held.

If multiple releases are needed to culminate into a product release, multiple release plannings will be combined in a release roadmap. This roadmap will be a high-level representation of what features are to be delivered in each release and how these releases are related (either sequentially or in parallel), identifying possible dependencies. When releases in such a roadmap are implemented by different teams, it is advised to physically put these teams in the same room when doing the planning sessions so that all teams are aligned towards a common goal.

Each of the planning levels is subject to planning adjustments along the way, usually derived the iteration tracking. Actions to adjust the scope (resulting in an updated backlog) can be decided upon during reflection moments (usually daily and weekly) associated with the particular level, such as for example a daily scrum standup for the iteration planning where each team member identifies what he did the day before, what he is going to do that day, and what impediments are blocking him. The frequency of these reflection moments is determined at the beginning of the project in an iteration planning cadence calendar, stipulating the rhythm and time boxes for meetings, checkpoints, retrospectives…

The execution of the iteration has the team starting development based on the estimated tasks, and each member repeats the following basic process until the backlog of the sprint no longer has any tasks: Take responsibility for a specific backlog item, develop and unit test the item, deliver it by way of integrating it into the system build, and declare the backlog item as developed and ready for acceptance testing. Once the iteration ends, the iteration is to be accepted after a successful demonstration to the product owners, customer and/or end users. This will provide the feedback and guidance to steer towards the release goals.

The main benefit to smaller and more frequent releases is increased responsiveness to the customer through constantly changing market conditions and a reduced risk to the organization as customer feedback about the effectiveness of the newly delivered functionalities is delivered to the organization faster. Releases in the agile paradigm are schedule driven. The release date is fixed, but the planning of the iterations usually does take into account events (such as planned holidays) that alter the availability of the team members.

In order to prepare the organization for agile at scale and to track the progress of the different implementations, a structure must be put in place to enable this. The book proposes to structure three types of organizational units, each with their own composition and responsibilities:

• Agile Component Teams: These are the typical agile development teams already discussed in this review. They perform a daily tracking of what their team members are doing.
• Scrum of Scrums: This unit serves as the tactical manager and coordinator of the different agile component teams. This team should be made up of the scrum masters of each of these teams, and it also does daily tracking.
• Steering Committee: An organizational unit consisting of the Enterprise Architect, VP or director level managers, system-level QA, and business owners. They perform weekly tracking of the different agile component teams and follow up on release status, coordination between teams, adherence to the mission/strategy, and expectations to meet the deadline.

Chapter 13 deals with agile testing practices. In the agile mindset, all code must be tested. Functional barriers between product owners, developers and testers are gone and test organizations should no longer take on large bulks of untested code. Rather, code is delivered in small manageable chunks. Tests are written before and during coding, and testing is a team effort, with both testers and developers writing tests. There is also a strong emphasis on automating as many test scenarios as possible, so that they can be easily retested with subsequent releases. Most agile test strategies focus on four types of testing: Unit Testing, Acceptance Testing, Component Testing and System/Performance Testing. The book also praises the Framework for Integrated Testing (FIT) approach, which is a method created by War Cunningham to design automation of acceptance tests.

Having small iterations of development to speed up releasing new functionalities, a system that allows for continuous integration of these functionalities is needed. This comes in the form of a fully automated and reproducible build that is created and tested multiple times a day. This repeated integration of code produced by the developers significantly reduced the number of merging issues that might arise. This type of system is called Continuous Integration and is the subject of chapter 14. Merging issues are among the most significant risks a waterfall development model brings with it. Continuous Integration happens in three steps: Integration of the source code (after a developer commits it to the source management system), automated build of the code, and automated verification tests. Whenever a build fails, this is coupled back to the people involved with the build. I have briefly touched on this topic doing the review of the “Expert AWS Development” book as well.

Another important aspect of agile teams is the need for process improvement. Because autonomous teams are accountable optimizing overall performance, they need to continuously make improvements to their proper way of working and the workings of the software they deliver. The most common way to approach this is to plan retrospective exercises for each iteration as well as for the release. The iteration retrospective is the first opportunity in agile development to assess and adapt current practices. It provides a key learning opportunity for all team members on what went wrong and how to try and fix it or improve the result. Assessment of a sprint will happen both in a quantitative manner (did all items of the sprint get accomplished) and qualitative (determining what went well, and what didn’t). After each release, a retrospective is held with a larger scope (all iterations in the release) with a larger set of stakeholders. The release retrospective assesses the value delivery, conformance to deadlines and possible refactoring and architectural debt.

Part 3 of the book focused on restructuring the organization to make it agile. It focuses on 7 principles:

1. Intentional Architecture
2. Lean Requirements at Scale
3. Systems of Systems and the Agile Release Train
4. Managing Highly Distributed Teams
5. Changing the Organization
6. Impact on Customers and Distribution
7. Measuring Business Performance

When defining Intentional Architecture, the book starts with the IEEE 1471-2000 definition of software architecture as a historical starting point. Beware: In 2011 this standard was upgraded to the ISO/IEC/IEEE 42010:2011, “Systems and software engineering - Architecture description specification”:

It links this standard to the definition elaborated by Barry Boehm and Richard Turner, who stipulated architecture to be the following:

• A collection of software and system components, connectors and constraints.
• A collection of system stakeholders’ need statements.
• A rationale which demonstrates that the components, connections and constraints define a system that, if implemented, would satisfy the collection of stakeholders’ needs statements.

A third perspective on this definition comes Grady Booch, Philippe Kruchten, and others, and is incorporated in the RUP methodology. Software architecture can be named and managed and encompasses the set of significant decisions about the organization of a software system:

• Selection of the structural elements and their interfaces by which a system is composed.
• Behavior as specified in collaborations among those elements.
• Composition of these structural and behavioral elements into a larger subsystem.
• Architectural style that guides the organization.
• Decisions involving non-functional concerns: usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, aesthetic concerns.

When mapping these definitions to the agile mindsets of this book, the author looks at each of the mentioned agile methodologies: The definition by Kent Beck about architecture in an XP project is that architecture emerges from a first iteration where the set of simple basic stories should be indicative of the entire system, and should thus force you to create the entire architecture. Once these stories are determined, narrow the focus to select the minimal number of those stories that makes the solution work. This results in the needed architecture. Scrum has no engineering practices per se and just adopts those of XP. FDD looks to domain object modelling as the lynchpin of the architecture design. The object model can be as general or as detailed as needed for the project and is also used to define the needed relationships between the different objects. The nature of these relationships is determined to be either static (generalization/specification) or dynamic (messaging).

The difference in definitions for software architecture stems from the complexity and criticality of the system being designed. The higher these qualifiers the more likely a need for an intentional architecture is needed. The other types of architecture are incremental or emergent architecture, which has been built over the course of several iterations, and the evolved architecture that supports the needs of current and future stakeholders. As more components are built for an organization, the need for them to interact properly should be handled by the appropriate type of architecture. The architecture should contain as much as possible ripple effects of changes in a single component.

An architectural component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component realizes and conforms to asset of interfaces This definition comes from Philippe Kruchten as part of the RUP methodology. Applying this to the agile mindset, components are considered the architectural building blocks in large-scale systems, and agile teams should be organized around them. The defined interfaces define the behavior of these components, and as such can be shielded from changes in the other components of the system, with a system architecture holding the overall system together. If there is not sufficient system architecture defining the components, there is no need for an agile team to be established around components.

These components are held together by the system architecture. This architecture is composed by enterprise teams. But the design of the original architecture poses a cyclical problem. There can be no teams without existing architecture to set them up around, and there can be no architecture developed without teams. To solve this, an initial team needs to be set up that will determine a basis for the component-based architecture in conjunction with a prototyping team that will test this architecture in the first few iterations. This basis will then support the formation of application teams. The application teams integrate as often as possible with the architecture while the architecture team provides the needed utility (domain models, component models, deployment models… ) for new features. The author speaks of architectural runway as existing or planned infrastructure sufficient to allow the incorporation of current and anticipated requirements without excessive refactoring. Extending architectural runway necessitates the proficiency of the teams with constant, incremental refactoring to meet changing needs and modeling activities/research spikes to support the needed extensions. These research/design spikes are best structurally planned in the iterations.

In a scrum setup the concept of a backlog is employed. Here all requirements/stories are listed for consideration to develop. These requirements are still high-level and are elaborated in the sprint for which they are selected. It is the role of the product owner to make sure that this backlog is maintained and prioritized, and that it contains a work estimate for each of these items. The product owner also identifies future development possibilities and adds these to the backlog.

Seeing how RUP is more document-heavy, it employs a more rigorous approach to requirements. Their ongoing refinement and development are described in three key artifacts:

1. The vision document: An overview of all features and benefits to be built.
2. The use-case model: A visual model of the actors in the system and actions they can perform. An elaborated use case should describe the flow of events in clear and understandable language.
3. The supplemental specification: A capture of all non-functional requirements for the system.

Compressing the benefits of each of these methodologies into a workable solution for lean requirements at scale, the author arrives at a set of practices concerning vision, roadmaps and just-in-time elaboration. The practice of having a vision translates into all stakeholders working towards a common purpose. Inheriting the vision document from the RUP approach or the backlog artifact from Scrum, this document is frequently used by agile teams as part of the business case for new initiatives. The roadmap stipulation is a model of how we see our implementations evolve over a longer period of time in order to be able to properly set priorities to the items in our backlog so that an evolutionary product is visualized.

The just-in-time elaboration of the requirements is an application of one of our agile tenets of investing more time in coding and less time in requirements documentation. This elaboration is done in three steps:

1. Feature Realization: The high-level requirements of the backlog are allocated to components to be developed. The user stories and uses cases needed for the realization of the component and its behavior are identified.
2. Optimizing across Requirements and Design Continuum: Several distinct solutions are envisioned for the requirements and are rated for difficulty of implementation and user benefit. These solutions are added into a design continuum (much like the TOGAF continuum) to be drawn upon in later stages for implementation or refactoring.
3. Requirements Elaboration: The requirements linked to the components chosen for development in the sprint are now elaborated in more detail and matched to a described solution.

Chapter 18 deals with the need for systems of systems. This means agile planning and management constructs that are needed for building larger scale systems. For this an agile component release schedule is needed. This schedule is a series of iterations (usually 3) followed by a hardening period right before a release period (either internally or externally). Even with this improvement over standard waterfall release schedules, there are still issues with creating a reliable and synchronized schedule over multiple teams where integration phases and the slowest team driving the release are still in effect. A release train where we forcefully synchronize the teams, is needed for this. Such a release train is based on several principles:

• Shipping often, and meeting the dates set forth in the schedule.
• Certain intermediate, global integration milestones are set and enforced.
• Integration is practiced at top level as well as at component level.
• Constraining release dates means that functionality for component releases should be flexible.
• Common infrastructure, functional, and interface components must be tracked earlier so not to block the different tracks.
• All development teams need a primary and fallback plan in order to meet the expected delivery dates.

Synchronizing all the different tracks to the iteration schedule is not absolutely mandatory, but it is highly beneficial: The integration now also happens at top level, making the overall system follow the schedule, these integration phases also have iterations and internal releases available for customer assessment and acceptance. Also, the issue of the slowest team dictating the release dates no longer figures.

Once this proverbial train has left the station, it is important to keep it on the tracks and on schedule. This becomes the responsibility of a specifically dedicated team. This team has been called a multitude of names: release train management (RMT), scrum of scrums, steering committee… The name doesn’t matter, but the composition of this team should be several senior team leaders, development directors, QA personnel and one or more mandated system architects. Together they are responsible for the planning and managing of the release train. This means setting the schedule and the milestones, communicating the vision and common requirements for the series of releases to the teams, and leading the release planning meetings that organize the activities for the individual teams. Since each of these teams provide real-time data of their progress, certain patterns can be detected early on (such as teams running late, deviating velocities from the initial plan, or interdependencies becoming critical blocking factors), so that steps can be orchestrated by the RMT to correct for these deviations.

Since at scale, all development will have to be distributed development, there is a need to be able to manage such a development setup. Chapter 19 hands us several tools to follow up on distributed development teams as standard native models of agility with only locally situated teams. The offsite teams require new roles in the team structure, usually a mirror role for each role that is locally active (architect, product owner, quality assurance manager, and development manager vs secondary architect, requirements analyst, secondary QA manager, and agile/scrum master). Other tools in the belt are multiple daily scrums (each team has its own preparatory daily scrum before attending letting a representative of the team attend the overall scrum), a multisite SCM solution (such as for example GitHub), a centralized repo for agile project management, and shuttle advocacy (rotating team leaders visiting offsite teams).

When setting up an agile approach on a program and/or portfolio level, the organization truly needs to be transformed from a traditional structure to an agile-ready mindset with the appropriate practices:

• Accelerating successful adoption of the agile mindset with expert coaching. For example: Designate an agile evangelist to coordinate training and the rollout process of the agile practices.
• Use the agile pilot projects to identify impediments and set up a support structure for change.
• Set up tooling for coordinating multiteam development. A sensible setup of your Application Lifecycle Management (ALM) environment should support offsite distributed development. This allows for the setup of round-the-clock development over different teams in different parts of the world.
• Create a highly responsive development organization and enhance your time to value. One of the tools supporting this is for example a continuous integration and deployment solution.
• Embrace fast-changing customer needs. An interesting approach is to create the role of a Requirements Architect that has this scope and mandate.
• Do not lose sight of agile improvement after the first five years of agile success. Keep up a mindset of continuous improvement and expand your agile adoption throughout the organization.

When introducing an agile way of working, this will not only impact development (the focus for the previous chapter), but every aspect of the organization. Chapter 20 examines the impact the introduction of agile has on the sales and marketing process, as well as the impact these changes have on customers. These departments will face challenges and reap benefits from the change.

The benefits for the sales and marketing departments manifest as more products/services to sell with a better fit to the needs of the customer. The increased frequency of releases also means more flexibility to outmaneuver the competition. And as they are now also more closely involved in the development process, their visibility, knowledge and ability to influence the releases and their content drastically increases.

The challenges accompanied with the agile way of working for the sales and marketing departments stems from the agile principle that business people and developers must work together daily throughout the project, so resources from these departments need to be freed/allocated to make this a reality. This might necessitate an increase in number of people within these departments, or an integration of development team members into these departments to take up a more product owner-oriented role. Another challenge to contend with is the smaller and more frequent releases. The need to evaluate software in the marketplace and correct for errors or changing needs is at the core of the agile mindset. However, this comes with a set of challenges associated with such increased frequency, most of them stemming from additional change management in preparing departments (marketing overhead for creating material and timing release news cycles, sales training for new products/services and updating of license/support agreements, operational overhead in deployment and migration). This also results in an impact for the customer base who could suffer more frequent training for the new releases, possible additional installs, keeping up with changing licensing agreements…

In order to reduce the impact of increased development cycles, there are several possible strategies. The first option is to ignore the agile releases, and still schedule the to-market releases when the planning allows for it. All other (agile) releases will be considered internal releases only. This option however diminishes the benefits of early feedback and competitiveness in the marketplace to some degree. Option 2 is “chasing agile”. The concept is to match the marketing and sales activities to the agile release cycles. This is fully compliant with the agile mindset: Every internal release will be an external release. The third option is the optimize through decoupling development releases from external releases. Here the to-market release is completely independent from the internal agile releases. Where in option 1, the to-market release is still coinciding with one of the agile releases, her we no longer consider this to be needed. This is done to still have frequent releases but at the same time have consideration for the impact of such changes on the customer base, and carefully weighing the tolerable level of disruption, as well as properly time the product announcements to the market.

Chapter 21 breaches on the topic of changing the organizational mindset. The speed of such change depends on the degree of change still required in the organization, the urgency within the organization to improve its software development and delivery process, and the effectiveness of the leadership supporting this change. Agile requires a certain philosophical mindset to achieve its maximum potential. These can be considered dogmatic and are as follows:

• Effective software development is best implemented via an empirical rather than a planned or predictive process. This comes from the realization that non-repeatable activities of such complexity cannot be defined in advance, thus they require an empirical process control model.
• Once organizational impediments are removed, a self-organizing and self-managing team delivers better software. These impediments are usually encountered in 4 areas: the scrum process itself, people practices/corporate culture, product engineering practices, and systemic organizational issues.
• Time and budget for an iteration are planned up front, but the exact functionality developed in such a sprint cannot be predicted.

Another spin on this can be seen in Ba – the Zen of Scrum as coined by Jeff Sutherland. The concepts behind Ba are the following:

• Dynamic interaction of individuals and organization creates a synthesis in the form of a self-organizing team.
• Ba has a self-organizing nature. It provides a shared context in which individuals can interact with each other.
• Team members create new points of view and resolve contradictions through dialogue.
• Ba is shared context in motion where knowledge as a stream of meaning emerges.
• Emergent knowledge codified into working software self-organizes into a product.
• Ba needs to be “energized” with its own intention, direction, interest, or mission to be directed effectively.
• Leaders provide autonomy, creative chaos, redundancy, requisite variety, love, care, trust and commitment.
• Creative chaos is generated by implementing demanding performance goals. The team is challenged to question every norm of development.
• Under great time pressure extreme use of simultaneous engineering emerges.
• Equal access to information at all levels is critical.

Rolling out any agile methodology in a large organization requires several steps of which some are generic to any type of situation:

1. Finding an evangelist of local sponsor. This sponsor can take the lead in various ways, such as personally undertaking the study and mentoring in the agile methodology of choice, bring in expert guest lecturers, empower fellow managers with an affinity for agility by placing them in special project teams aimed at fostering and implementing the methodology in the organization.
2. Taking small initial steps to test the waters. Prepare for these pilot projects with training scrum master and product owners, establishing metrics for success, and establishing an initial product backlog.
3. Reflecting on successes and failures, taking into account the metrics specified in the previous step, then moving forward, step by step improving the processes.

These metrics are the topic of chapter 22, which is the final chapter before the conclusion chapter of the book. The main metric for agile development is the existence of working software, and whether we can demonstrate it is suitable for use in its intended purpose. This demonstration happens at the end of every iteration. When measuring team performance, we look at agile project metrics. These metrics come in two flavors: iteration metrics (applied to each iteration to provide fast feedback for development in the next iteration) and release metrics (applied to the slower cycle of higher customer value releases).

When trying to optimize the agile process itself, the method of rating its different areas of performance on a scale from 1 to 5 gives a proper indication of where to look for improvements on the current way of working. These areas are: Product Ownership/Management Capability, Release Planning and Tracking Capability, Iteration Planning and Tracking, Team Effectiveness, Testing Practices, and Development Practices/Infrastructure.

These performance metrics tie in nicely with any possible Balanced Score Card (BSC) initiatives that might exist in the organization. For an in-depth look at how BSC operates and its philosophy, I will refer to a review I did earlier of “The Balanced Scorecard” by Robert Kaplan and David Norton. The synergy of these agile metrics and the BSC can be set into the 4 quadrants usually associated with the BSC, namely Efficiency (mapped to the Internal Business Process Perspective), Value Delivery (mapped to the Financial Perspective), Quality (mapped to the Customer Perspective), and Agility (mapped to the Learning and Growth).

The book offers a nice overview of these metrics in a quadrant with some sample measures:

Efficiency Measuring the R&D organization in meeting with the current deliverables, productivity, revenue and cost targets. Sample metrics: contribution margin, organizational stability, team velocity	Value Delivery Measuring the value of the software delivered to customers. Sample metrics: number of releases, value feature points per release, architectural refactors
Quality Measuring the quality of the products/services as determined in the customers environment. Sample metrics: number of defects, support satisfaction, escalation rate percentage	Agility Measuring the ability of the organization to improve and meet future performance objectives. Sample metrics: Agile self-assessment metrics

In conclusion, I agree with the author that agility at a larger scale is a possibility, and thus large-scale systems development should not shy away from agile practices. The book lays a proper foundation on how to tackle these types of projects, and hands a number of tools and practices to achieve successful development. However, these tools and practices do not form a coherent methodology, as the author himself suggests forging your own way to agile enlightenment and your proper way of doing things. The SAFe methodology has done just that, and offers an option for not needing to create your proper methodology. It would have been nice to find some reference to this framework, but the book predates the framework by too much time for this to be a reality. Maybe in a future updated version of the book.

Review

ALM

Comment