Agile Charting: A Practical Guide. Dr. Alan Moran

Transcription

1 Agile Charting: A Practical Guide Dr. Alan Moran

2 The material in this document (excluding the IARM logos and cover image) may be reproduced free of charge in any format or medium providing that it is reproduced accurately and not used in a misleading context. The IARM copyright must be acknowledged and the full document title cited. Unless otherwise stated all images (excluding the IARM logos and cover image) are reproduced with kind permission of (c) Alan Moran, All Rights Reserved. The IARM logo is a trademark of the IARM. Copyright (c) 2014 by the Institute for Agile Risk Management. All Rights Reserved.

3 FOREWORD The technique of agile charting has evolved over several years of personal experience and has proved to be as effective as it is simple. Yet despite occasional and sometimes oblique references to its origins, it appears to be a largely overlooked device when describing and managing agile processes. In response to the many requests that I have received for further information, this publication was produced by the Institute for Agile Risk Management with the support of the agile community and has been made available to you entirely free of charge. I hope that it gives you some food for thought, assists you in your daily work and that you too can contribute to its future development! Dr. Alan Moran MBA CITP Managing Director Institute for Agile Risk Management

4 CONTENTS Foreword 3 Contents 4 Agile Charting 5 Agile in a Nutshell Agile On The Line Agile Charts Slicing the Chart Framing Feedback Creating an Agile Chart Charting Guidelines Worked Examples 13 Scrum Extreme Programming (XP) Dynamic Systems Development Method (DSDM) Disciplined Agile Delivery (DAD) Soliciting Feedback Tooling Escape Velocity Clockfacing Afterword 25 4

5 AGILE CHARTING Agile charting 1 addresses issues surrounding the linear representation of agile processes that are usually derived from traditional phased approaches to project management. Put simply, it equips teams with a simple but powerful tool for communicating intent and soliciting feedback. The principles and key features of agile charts are presented in this chapter before moving on to concrete examples in the next chapter. Agile in a Nutshell Agile grew out of a movement to establish within IT, practices that were founded on tight feedback loops, timeboxing, collaboration and communication, self-organization and empowerment. Born of the recognition that traditional phased approaches to project management (e.g., Waterfall) introduced structures that inhibited initiative and innovation, agile encouraged adaptive planning, reflection, servantleadership and an open, embracing attitude towards change and risk. The inherent structure of agile processes comprises of multiple overlapping timeframes, that capture the essence of iterative development and incremental delivery. Within the IT industry, various agile methodologies express distinct facets of engineering (e.g., XP), product development (e.g., Scrum), architectural (e.g., SAFe) and project management (e.g., DSDM) approaches. Although anchored in the traditions and values of the industry that gave birth to them, many methodologies strive to reach beyond these boundaries to offer scalable frameworks within which arbitrary iterative and incremental activity can be framed. Agile should therefore be considered an evolving and growing movement, whose values and principles (as described in the agile manifesto 2 ) repeatedly find expression in new and adapted techniques. Agile On The Line The recurring cadence of activities in agile projects requires a cyclical rather than a linear representation in order to accurately capture their true structure and dynamic. To understand the problems associated with traditional linear representations of project activities, consider Figure 1 which shows a small subset of the sort of tasks that might typically be found in an agile process for an IT product development project. In this example, each iteration begins with a planning session and concludes with review and retrospective activities that look at what has been achieved and what might be improved next time. Each day begins with a stand-up meeting followed by solution development and is concluded with a build of the software product to ensure that it is deployable. This pattern repeats itself throughout the iteration. The following issues arise with this linear representation of an agile process: 5

6 6 CONTENTS Figure 1: Limitations of Linear Representations. Many tasks reoccur in the same sequence at regular intervals (e.g., daily stand-ups, solution development and nightly builds). This is not only repetitive to maintain but also does not reveal any deep insights into how the process can be improved. Even minor changes to the process (e.g., doing some development work before the daily stand-up meeting or introducing a mid-day build) require considerable reworking of the diagram which in turn inhibits feedback and continual improvement initiatives. Some activities that occur at multiple levels throughout a project are linked (e.g., planning often occurs at release, iteration and daily levels) but linearity makes it harder to detect and exploit this dynamic. Agile Charts Agile charting addresses the issues with linear depictions by rendering the process not as a line but as a series of concentric circles, the traversal of each of which implies multiple transitions of its inner circle. This simplifies not only the creation but also the maintenance of the process representation. By clearly communicating intent, this fosters and encourages feedback to improve the process and facilitates explorative discussion of alternative approaches. Figure 2 shows what a generic agile process might look like in terms of an agile chart that uses increment, iteration and day cycles. Reading from outside inwards in a clockwise direction, the increment begins with the formulation of the underlying business case i.e., what is the release trying to achieve and on what basis this achievement will be measured. This enables delivery planning to take place which usually involves the creation of high level requirements. As the product evolves, acceptance testing might occur as a prelude to training users and support staff, after which a deployment may take place. Finally, benefits may be assessed to see if they have in fact been realized. Moving down to the iteration cycle, each iteration begins with a planning event to refine high level requirements and to decompose these into tasks. The common working area for the project might host an information radiator which displays all project relevant artefacts (e.g., Kanban board, backlog, risk log etc.) that one might expect to be updated at least once in each iteration. Throughout the iteration, acceptance testing of the emerging solution takes place and progress towards the iteration goal may be tracked using an appropriate burndown chart. The iteration concludes with a demonstration of what has been achieved, which usually stimulates discussion on what should be done in the next iteration. This is

7 SLICING THE CHART 7 Figure 2: Generic Agile Chart. often followed by some form of reflective activity to capture lessons learned from the iteration that may be used to improve the overall process. Finally at the daily cycle, each day usually commences with a short stand-up meeting followed by solution development that finishes with a complete build of the product. Agile methodologies are invariably open concerning which techniques could be employed though some (e.g., XP) encourage the use of an integrated set of practices at this level (e.g., pair programming, test driven development, continuous integration and refactoring). Of course this is merely one approach that the project might take. For example, some product focused methodologies do not clearly delineate between release and iteration, choosing to leave open at the end of each iteration whether or not a product could in principle be shipped. Other methodologies give greater weight to activities that are unrelated to product development, but which must still be accounted for during the release and deployment phase (e.g., training of users and support staff). Furthermore, some may argue that a release cycle really belongs within a project cycle in which business case and project governance are tackled, leaving only change and release management activities to the release cycle. Since much depends on the nature and practices of the organisation, an agile chart in whatever form it takes, will usually reflect these specific circumstances. Slicing the Chart Some activities are best described as recurrent i.e., they occur at differing levels of granularity and at multiple cycles. This is a natural feature of iterative processes and is important since it draws attention to the fact that the cycle at which an activity should take place is a reflection of its intensity and frequency. Since most agile events are timeboxed, intensity and frequency are bound loosely by a single degree of freedom, making them broadly inversely related to each other. For example, planning takes place at all levels ranging from high level release planning, through to the decomposition of requirements into tasks at the iteration level and finally the details of their implementation at the daily cycle. This dynamic is captured through the use of slices (e.g., the planning slice in the upper right quadrant of figure 3) that

8 8 CONTENTS connect events that are low intensity and high frequency (inner cycles) to those that are high intensity and low frequency (outer cycles). As an aside, the more abstract an agile process is, the fewer slices it tends to have. Figure 3: Slices of a Generic Agile Chart. Slicing helps to decide at what level a specific event should take place and how the different levels interact with each other. Consider, for example, quality management which might comprise of lengthy code reviews (an iteration event requiring perhaps a full day) versus short pair programming activities that can easily be accommodated with normal work on a daily basis. The link between these two and their role in quality management might not be that apparent to a team until a slice is thrown around them. This encourages the team to consider other quality management efforts and where they might fit into the slice. Other slices become immediately apparent from figure 3. For example, test management (the bottom slice of figure 3) covers daily testing (e.g., test driven development) as well as acceptance testing at iteration and increment cycles. Furthermore deployment activities form a natural slice (on the left hand side of figure 3) that ranges from daily builds (perhaps into a test environment), to demonstrations (which might involve artefacts being deployed into an integration environment) and releases (into a production environment). Framing Feedback A central tenet of agile is that reflection is required from all project team members and that this should be collated at specific points in time (e.g., retrospectives). This in turns leads to adaptation and improvement of the process. Agile charts are therefore not only an effective means of communicating intent, but also of soliciting feedback. This enables a team at the start of the project to map out their understanding regarding the sequence and frequency of activities, thereby gaining consensus about how they intend to work together. In time, the need to adapt will inevitably arise. Placing an agile chart in a communal area and inviting team members to annotate it (e.g., writing comments on the chart, using coloured dots

9 CREATING AN AGILE CHART 9 to mark areas for improvement) for later discussion in the retrospective is a great way of achieving this. In fact, there is an immediacy and openness, as well as a clarity about the context of the feedback, that makes this approach very easy to adopt. An example is provided in the next chapter. In this context an agile chart can be used as a continual process improvement vehicle. It is probably worth colour coding changes so that future intent is communicated clearly and the boundary between current and target practices is not blurred (i.e., what is planned but not yet implemented). Focus on improvements that generate the most value and try to introduce these one at a time so that the improvement plan does not disruptdevelopment too much. This is important since the successful introduction of a new practice owes as much to learning how to use it effectively, as it does to the fact that it is being used at all. Over time, the most appropriate set of practices will become documented in the agile chart and may form the basis of a template agile chart for other similar projects. Bear in mind, however, that projects do differ and that the goal is not necessarily to standardize practices across an organisation, but rather to encourage and foster a culture of continuous improvement within and between teams. Since much depends on maturity and attitudes within a team, do not expect that something which works well for one team must automatically work well for others. Don t forget that improvement might also mean dropping an existing activity or doing it in a different manner. If many project teams within the organisation are using agile charts then it becomes as easy to exchange ideas as it is to exchange the charts. In fact, simply wandering around to see how other teams describe their processes is often sufficient in itself to get some ideas going within the team. Creating an Agile Chart Agile charts are created on the basis of the actual working practices of a project and are refined thereafter based on reflection and adaptation. Since an agile chart reflects the collective commitment towards a specific way of working on the project, it is important to involve all team members. The first step is to decide on an appropriate level of granularity for the cycles. Generally speaking, cycles for releases, iterations and days often suffice. It is not unreasonable however, to also include a project cycle containing the release cycle. Do this only when the need arises, however. Often it is easiest to start from the inside out i.e., begin with what happens on a typical day. Of course not all days are entirely the same (e.g., an iteration planning often requires a full day that differs from the usual routine of daily stand-up, development and builds often found in IT projects). Such details are typically subsumed at higher cycles (e.g., by placing a planning activity on the iteration cycle). Focus on key events and their order without being overly prescriptive (e.g., an IT project might describe a solution development event but leave it to individual team members to decide how they wish to perform this activity). Once the inner cycle is done, move out to the next cycle and repeat until the chart is done. When complete, the chart should be discussed within the team in order to validate it. Honesty should trump aspiration at this point as it is important to capture an accurate account of how work is actually being performed (i.e., if a specific activity is planned but not yet realised then either omit it or mark it appropriately e.g., in brackets or italics). Figure 4 shows a chart in the early stages of creation. The team has decided to go with three cycles but is unsure about whether the outer cycle is really a release or a project. This might reflect different understandings within the team about the use of language (e.g., merging of the concepts of a project and its deliverables). At the day level there is a reasonably clear idea of what happens though there appears to be some discussion about how (or whether?) test driven development (TDD) should be performed. Resist the temptation to simply get the chart done for completeness sake. Sometimes, it is probably

10 10 CONTENTS worth accepting the fact that not everything is yet clear. In practice, however, most teams do manage to get a reasonably full chart early on which they can validate against project experience over time. Figure 4: Early Stages of an Agile Chart. With each transition of a cycle take the opportunity to reflect on its accuracy and relevance. Use the physical presence of the chart to solicit feedback and discuss this in each iteration retrospective. The agile chart will then become a living document that tracks the progress of the team towards a process that works best for them. In general terms, it is worth starting out simple and adding more detail to the chart as needs dictate. Bear in mind, that sometimes more than one chart is used (e.g., a process chart and a tools perspective chart as described in the next chapter) though within a project they often share a common foundation. Charting Guidelines Since agile charts promote understanding, communicate intent and solicit feedback they are appropriate for describing the overall project approach and how to tackle solution development, quality and testing, risk management as well as a wide range of other activities. The following guidelines ought to be borne in mind when agile charting: Agile charts are event granular dependent. The art to using an agile chart lies in the understanding of the granularity of the event, which in turn determines where it is to be rendered on the chart. For this reason, iteration planning (an event that often consumes a whole day) is placed on the iteration cycle rather than the day cycle, which is better suited for shorter and regularly repeating events. Agile charts are order based. The ordinal nature of agile charts captures iterative and incremental activities helping the team to understand how the process plays out in their daily work. Order means just that, try not to read too much into it!

11 CHARTING GUIDELINES 11 Agile charts are not planning instruments. Agile charting should not be understood as the basis for detailed planning or be used as a substitute for other planning artefacts. The ordinal and event based nature of charts, also means that the precise placement of an event on a chart does not have relative temporal implications (e.g., testing half way through the iteration does not mean it begins at the end of week one of a two week iteration). Be aware of implicit and emergent activities. Some activities are emergent in character which means that they are diffused over several activities and cycles and only evolve over time. Sometimes this can be difficult to capture on the chart though recurrent slices do help. It is perhaps advisable to acknowledge this within the team and use a visual metaphor appropriate to the specific circumstances (e.g., cloud icon). Agile charts target the dynamic of the process. Agile charts excel at rendering the project approach dynamic and facilitating open, innovative discussions. They therefore require continual updating, indicative of the reflection that should be occurring within the team. Owing to project vagaries, they should perhaps not be used to force standardization of agile practices across an organization. Notes 1 In his book, Agile Software Development, Alastair Cockburn describes a cyclical representation of agile processes which he refers to as process cycles and attributes it to Don Wells. This simple idea is developed further in this publication into a project communication and management tool. 2 See and for details.

12

13 WORKED EXAMPLES This chapter illustrates by example the application of agile charting. The first batch of examples concern common mainstream methodologies and are a good starting point for those currently using one of these approaches. Thereafter some specific practices (e.g., soliciting feedback, clockfacing, escape velocities) are presented which might be used in combination with the methodological charts. This chapter is intended both as a reference and as a source of inspiration for charting within project teams. Scrum Playing on sporting metaphors the term "Scrum" is intended to evoke the collectivism of continual and incremental effort, contrasting with the relay-race of phased development approaches, which separate out and linearize the software development lifecycle. Scrum 1 is best described as a framework for the agile development of software products, rather than a methodology that prescribes specific tools and practices. Rooted in empiricism it is founded on notions of transparency (e.g., common standards), inspection (e.g., detection of variances) and adaptation (e.g., process correction and alignment) that express well the central features of agility (e.g., iterative and incremental development, feedback loops, self-organizing and cross-functional teams). Developed originally during the 1990s it has today established itself as the most popular expression of agility within the IT industry. As shown in figure 5, the primary elements of Scrum comprise of high level forced ranked requirements recorded in a product backlog from which a subset, known as the Sprint backlog, is selected that leads to a potentially shippable release increment. Figure 5: Scrum Process Model. The principles of Scrum capture both humanist and business values such as courage, openness and respect, as well as focus and commitment. Though its set of official practices is limited to iterative development (referred to as sprinting) and planning, daily scrum meetings and closing Sprint review and retrospectives, these are frequently augmented with other techniques such as Scrum-ban (essentially the 13

14 14 CONTENTS use of a Kanban board) and burndown charting. Although iterative development and incremental delivery are not as clearly delineated as in other methodologies, it is evident from the descriptions of planning activities that there is at least an implicit division between the two. Fixed length iterations, referred to as Sprints, constitute the primary container for all Scrum events each of which enables inspection and adaptation of the process. Chronologically, the first of these is the Sprint Planning event during which deliverables and the work required to deliver them are determined. These are derived from the Product Backlog (an open-ended list of well-defined and understood requirements, enhancements and fixes that are estimated and assigned value) and used to create the Sprint Backlog that communicates, forecasts and monitors activities in greater detail on a daily basis. Much of the work at this stage is focused on gaining consensus regarding understanding of the requirements and how they should be implemented (e.g., design) and tested during the course of which a well-defined and coherent Sprint goal is determined and formulated. Thereafter the team meets on a daily basis (the Daily Sprint) to briefly (i.e., no more than fifteen minutes) discuss their contribution towards the Sprint goal, the planned activities for that day and to declare any impediments that lie in their path. At the end of a Sprint there is a Sprint Review meeting to determine the state of affairs of items on the Product Backlog and propose any necessary adaptations, gather feedback on the iteration itself and review other details related to the project (e.g., budget, timelines, next steps). Finally the Sprint Retrospective is an opportunity for continual process improvement (e.g., by taking a closer look at relationships within the team, use of processes and tools) and how it can be implemented in the next Sprint. Figure 6 is a rendering of the Scrum events (left) and products (right) as commonly encountered on Scrum projects. This may serve as a good starting point for a Scrum project and ought to be amended as appropriate. Figure 6: Scrum Agile Charts of Events (left) and Products (right). Two slices, planning and deployment, are immediately evident from the structure of Scrum. This reflects the manner in which daily Sprint and release planning and deployments are each in their own right interconnected. The overview of Scrum events illustrated in figure 6 depicts a simplified version of the Scrum process, that distinguishes between release and Sprint cycles based on the levels of planning implied by the methodology. It is worth noting that the distinction between a Sprint and a release is not universally clear in Scrum which often uses the term iterative and incremental development to merge

15 EXTREME PROGRAMMING (XP) 15 the two together. Ultimately, the aim is to deliver a minimal usable set of software that is potentially shippable, i.e., thoroughly tested, documented and well-written code. In practice, however, it is reasonable to expect a product team to focus on the solution development and to create artefacts that could be deployed either by them or another team, as determined by the project working environment. Extreme Programming (XP) Extreme programming 2 (XP) has been a highly influential agile methodology that assumes a very engineering focus by advocating specific principles (e.g., Collective Ownership, Architectural Simplicity) and techniques (e.g., Test Driven Development, Continuous Integration, Pair Programming) that can be used in the context of IT projects. XP is a disciplined undertaking that benefits from high levels of skill and commitment to standards together with a willingness to embrace openness, trust and a sharing of knowledge. Figure 7: XP Flow Chart. Whilst XP does acknowledge a distinction between releases and iterations, its culture and expression within mature teams can make it take on a very fluid form that blurs these boundaries. Notwithstanding, release based activities revolve around the definition of a vision (i.e., System Metaphor) and its elaboration in the form of a release plan and the deployment of deliverables. Within an iteration, planning sets the scene for development and testing which leads to a product demonstration and an opportunity to reflect on lessons learned. It is at the daily cycle, however, that XP shows its true colours through its recommendation of a variety of integrated practices (e.g., refactoring, test driven development, pair programming, continuous integration and builds). Today, these elements constitute the foundation of any agile IT product development environment. Figure 8 shows one possible interpretation of XP in a project environment that clearly delineates between iterations and releases. Note, that some elements of XP could span multiple cycles (e.g., architectural spiking, maintenance of a sustainable pace) though within a specific project context it is likely that these can be localised more accurately. Rather like Scrum, the structure of XP admits multiple slices (e.g., planning, quality and deployment), enabling a team to identify and exploit such dynamic early on in the project. The actual practice of XP within a project reflects strongly the characteristics of the project team (e.g., maturity, skill) and it is to be expected that in spite of the apparent tight structure of XP, there will inevitably be movement on the chart in relation to the position and weight of activities.

16 16 CONTENTS Figure 8: XP Agile Chart. Dynamic Systems Development Method (DSDM) The Dynamic Systems Development Method 3 (DSDM) is a project management based agile methodology which grew out of Rapid Application Development (RAD) techniques developed during the 1990s. It underpins both the APMG accredited agile project management AgilePM certification and the Agile Project Framework and is maintained by the DSDM Consortium. As depicted in figure 9, DSDM is based upon a lifecycle model that is initiated by a Pre-Project phase (e.g., formulation of business case and outline plans) and transitions to a feasibility and foundations phase (e.g., development of business case, solution architecture and delivery plans) oscillating between evolutionary development (e.g., iterative development) and deployment phases (e.g., incremental delivery) before concluding with a post-project phase (e.g., benefits analysis). DSDM is a mature approach that sits comfortably with many traditional facets of project management (e.g., quality, risk and configuration management) and integrates well with a wide variety of other frameworks (e.g., portfolio management). DSDM also incorporates a rich set of products, many of which can be endowed with a level of ceremony appropriate to the project circumstances (e.g., communications in terms of an informal mail or a formal versioned documentation). These include a terms of reference (e.g., drivers, goals), business (e.g., business case, prioritized backlog), solution (e.g., architecture and development approach) and management (e.g., delivery plan and project approach) foundations along with delivery control and quality assurance artefacts that accompany the evolving solution and culminate in a delivered product, a project review and an assessment of its benefits. Figure 10, which depicts the DSDM events and products, constitutes a good initial starting point for a DSDM project (note the different levels of granularity with events framed at the increment level and products at the project level). It should be observed, however, that owing to the high level nature of DSDM, such charts need to be further annotated with specific practices and activities reflecting the decisions taken during the foundations phase in relation to the development and project approaches. The three levels of agile project management planning (i.e., outline, delivery and timebox) become very clear as a slice in the right hand side of figure 10. Similarly, the demonstration of control slice (i.e.,

17 DISCIPLINED AGILE DELIVERY (DAD) 17 Figure 9: The DSDM Lifecycle. Reprinted with kind permission of (c) DSDM Consortium All Rights Reserved. Figure 10: The DSDM Lifecycle and Products Charts. timebox records, project review and benefits assessment) steadily builds up a picture of overall progress towards business goals. DSDM invites consideration of the wider context of the project environment (e.g., governance, portfolio and risk management) and thus it is inevitable that these will also make an appearance in the chart (e.g., perhaps adding an additional project cycle). This is to be encouraged if it supports the team and its stakeholders in their overall understanding. Disciplined Agile Delivery (DAD) Disciplined Agile Delivery 4 describes itself as a process decision framework that is based on the synthesis of several different agile methodologies, incorporating elements of Scrum, Unified Process, Extreme Programming and Lean approaches, amongst others. It supports several distinct delivery lifecycle models one of which, depicted in figure 11, describes a Scrum based approach endowed with elements of the

18 18 CONTENTS Rational Unified Process (RUP). Though the overall process is broken down into phases (i.e., inception, construction and transition) individual iterations follow a coordinate-collaborate-conclude cadence. Interestingly, it is precisely these phases, inherited from RUP, that impose a linear superstructure onto its otherwise cyclical substratum (which is usually taken from Scrum or Lean). Figure 11: DAD Scrum/RUP Lifecycle Model. Reprinted with kind permission of (c) Scott Amber + Associates All Rights Reserved. The inception phase is concerned with identification and prioritization of initial projects along with the determination of appropriate roadmaps and funding. It concludes once initial modelling, planning and organization (which yield the initial high level requirements, a release plan and a stakeholder vision) have been completed. Each construction iteration begins with a planning and modelling session before moving to collaborative practices that find expression in daily work. Towards the end of the iteration a demonstration of the iteration deliverable in the form of a consumable solution is presented, followed by a retrospective and concluding activities (e.g., updating of the release plan, determination of a "go forward" strategy) that naturally flow into the next iteration. With a construction iteration, each day usually begin with a daily coordination meeting following which project management artefacts (i.e., the task board and iteration burndown) are updated. During the day collaborative activities include resolving issues, modelling, writing code and tests, integrating and deploying solutions before concluding with finishing activities such as stabilizing builds. A wide range of practices that borrow heavily from other methodologies come into play and are categorized as standard (e.g., refactoring, continuous integration, model storming, architectural spiking) or advanced (e.g., test driven development, look-ahead modelling and planning, non-solo development). The process concludes with a transition phase that sees a consumable solution taken from construction transferred into production where its operational life may give rise to new tasks (e.g., bug fixes, improvements) that are added back to the requirements backlog. The mixture of linear and cyclical influences found in the DAD Scrum/RUP lifecycle presents a challenge when rendering the entire process as an agile chart though figure 12 does at least capture the structure of a construction iteration embedded within an abstracted release lifecycle. Owing to the copious practices and principles found in DAD, such a chart would require further refinement to adequately reflect the actual workings of a specific project environment.

19 SOLICITING FEEDBACK 19 Figure 12: DAD Scrum/RUP Lifecycle Agile Chart. The challenge of charting most DAD lifecycles reveals their mixture of phased and cyclical elements. Rather like the pre-project and deployment phases of DSDM, the concept, inception and transition phases of DAD can be subsumed into a higher cycle without the need to create distinct and separate inner cycles for each of them. DSDM, however, does appear to deploy its overarching incremental structure in such a manner that the timeboxes therein follow similar sequences of activities. The approach taken here could still be said to be acceptable for DAD since the construction phase is the primary focus of activity in the lifecycle. Soliciting Feedback Agile charts offer an excellent framework for gathering feedback which can be done continually throughout an iteration or at the end during the retrospective. The underlying chart perspective (e.g., events, tools) frames the feedback and slicing indicates possible knock-on effects of the negative feedback that a process may encounter (e.g., difficulties with daily builds might signal future problems with demonstration builds). Figure 13 shows a sample feedback chart. Areas of satisfaction have had stars placed on them to indicate positive feedback and those where issues have arisen have been marked with thunder bolts as negative feedback. It is evident that there are issues in the daily build that might be leaking into the iteration build. This might be an early warning of build issues that could one day be manifest at the release level and thus warrant some attention (e.g., creation of a task for the backlog). There appear elsewhere to be some minor issues though the overall consensus is rather positive. The absence of negative indicators on a feedback chart ought to be challenged as it might point to "group think" dynamics where individuals feel unable to challenge the prevailing view. As with feedback in general, however, there is generally a propensity to focus on the negative so it is also worth confirming also if the absence of good indicators is to be interpreted as positive feedback. Finally, consider applying the Honda taboo of "no criticism without constructive suggestion" 5 by insisting that negative feedback must always be accompanied by a constructive suggestion on how to

20 20 CONTENTS Figure 13: Soliciting of Feedback. improve the situation. In such cases, negative feedback might be numbered and referenced suggestions gathered next to the chart. For example, if someone feels that there is too much interruption of discussions during the daily stand-up meetings, then they are permitted to register this negative feedback only if they contribute a practical suggestion for improvement (e.g., using a talking stick 6, the holder of which is the only one permitted to speak at any point in time). Tooling A typical agile IT project environment utilises a variety of tools in order to generate and manage project artefacts. For example, it is not uncommon for code to be maintained under version control (i.e., software configuration management), built automatically when checked-in (i.e., continuous integration), packaged as deliverables that are stored in a repository (i.e., artefact management system) and delivered automatically into target environments in a controlled manner (i.e., scripted change, release and configuration management). This requires the collaboration of an integrated set of tools (sometimes referred to as a toolchain) each of which is associated with one or more events in the agile process. The charting of these tools and events yields the following benefits: Clarity about which tool to use when, particularly in organisations that use several different vendors each with overlapping tool functionality. Clarity about the evolving status of artefacts during the agile process (e.g., at what point does a snapshot deliverable become a release). Overview of the agile infrastructure that enables support staff (e.g., system administrators) to quickly deploy and configure appropriate project environments. Ability to clearly distinguish tool boundaries that reflect different organisational cultures (e.g., lightweight agile tracking for product development versus quality gate mechanisms such as change management for deployment into production systems).

21 ESCAPE VELOCITY 21 Ability to annotate tool based practices (e.g., software configuration management naming conventions) on a per-project basis ensuring consistency and transfer of best practices. Figure 14 illustrates a project toolchain based on a selection of generic tools including Wiki (W), Kanban Board (K), Continuous Delivery (CD) and Version Control (VC). Figure 14: Tool Perspective of a Generic Agile Process. It is surprising how much time can be consumed with discussions surrounding the use of tools (e.g., how best to manage documentation). Though much of this reflects underlying process uncertainties, some does arise from differences in personal tool preferences or unresolved issues over which tool best suits a given purpose. This can be compounded by organisational requirements (e.g., the need to document first line support guidance outside of the project infrastructure) or vendor licensing conditions. Whilst agile charting does not solve any of these problems, it does enable the team to be very clear about how tools support its processes and can facilitate discussions on finding optimal solutions. Escape Velocity Escape velocity employs the metaphor of escaping gravity in order to describe how specific product characteristics must be met before a product can be released for use. Once achieved, however, the team should strive to remain "in orbit" and not let the product drop back below the required standards. In software development environments criteria such as test cover coverage or static code analysis metrics are often used. Escape velocity typically applies at the iteration level and sets criteria that act as a quality gate between iterative development and incremental delivery. Some methodologies (notably Scrum and DAD) suggest that at the end of every iteration a product should be in a potentially shippable state whilst others (e.g., DSDM) foresee iterations delivering not only end-user products but other also artefacts (e.g., insights gleamed from a feasibility study). Therefore teh application of escape velocity is subject to a certain degree of methodological interpretation that is best left to the team. Figure 15 reminds the team (via the text written on the iteration arc) that they should strive for a minimum test code coverage of fifty percent, thereby setting an expectation that new code must immediately

22 22 CONTENTS be accompanied by a significant amount of unit tests. Furthermore the tangle index (a measure of cyclical code dependency) must not be allowed to rise too high. Finally predefined static code analysis (SCA) and unit test suites must be in good standing at the latest by the end of the iteration. Such annotations to the agile chart serve as a constant reminder of what is meant by quality and how much effort should be expended in delivering it. Figure 15: Escape Velocity Criteria. Escape velocity criteria are orthogonal to iteration definition of dones in the sense that they apply to every iteration and are often concerned with global or emergent conditions (e.g., testing, quality, security). As such both can be used in combination. Clockfacing Clockfacing refers to a simple way of communicating where a project is in the process by using hands to mark out its iteration and increment co-ordinates (or add additional hands if necessary). The chart can be updated during the daily stand-up meeting and immediately conveys where the team is without the need to interrupt its member or ask for updates. Equally important, merely moving the hands is in itself an act of validation of the chart allowing team members to review its accuracy. Figure 16 shows a clockfaced agile chart that is approximately half way through an iteration with a release pending in the near future. The team is engaged in acceptance testing and training and will likely to be ready to have the product is a production ready state very soon. Since agile charts are event and order based, clockfacing warrants a health warning! The purpose is not to impose a strict temporal interpretation onto the chart but rather to indicate where the team is in the process. Accordingly hands may be permitted to move backwards as well as forwards as and when circumstances dictate (e.g., setbacks in testing). Construction of the clockface need not be complicated. For example, using sticky tack and a couple of strings is probably more than adequate in most cases. Include only as many hands as is practical and informative for the team (e.g., a daily hand rarely makes sense owing to its high maintenance).

23 CLOCKFACING 23 Figure 16: Clockfacing an Agile Chart. Notes 1 The Scrum Guide, is excellent and concise overview of Scrum principles and practices. 2 For a description of the practices cited here please refer either to or 3 DSDM, which was briefly marketed under the brand name Atern, is described in detail in the DSDM Atern Handbook, as well as in the Agile Project Management Handbook (DSDM Consortium, 2010). The DSDM Agile Project Framework pocketbook (DSDM Consortium, 2014) is also an excellent and simple overview of the current principles and practices of agile project management. 4 For further information concerning DAD see Disciplined Agile Delivery, Amber & Lines, IBM Press (2013) or visit 5 For a discussion of the Honda taboo see The Knowledge-Creating Company, page 63, Nonaka & Takeuchi, Oxford University Press (1994). 6 The origins and practice of talking sticks are described in the following article _Talking_Stick

24

25 AFTERWORD We trust that you have found something of use that you can apply in your daily work! Help us to improve this publication further by sending us your feedback or perhaps submitting your own contribution (including worked examples and descriptions citing any sources that inspired or influenced you) to All contributions will be acknowledged though may be subjected to editorial review, amended and/or developed as appropriate.

26 The Institute for Agile Risk Management (IARM) is a Swiss based institution that exists to promote the principles and practices of agile risk management in the context of agile project management and the agile enterprise. It undertakes research and provides training in association with its network of third parties in the agile and academic communities as well as in the private sector. For further information concerning the institute please refer Follow us on LinkedIn by visiting