Agile2012

Incompatibilities between CMMI and agile have largely been due to misapplication of CMMI stemming from a narrow and misguided understanding of CMMI. This is exacerbated when CMMI is viewed as a compliance standard for defining heavyweight processes rather than an improvement model to increase performance. Isn't it about time the Agile community just moved on and stopped dwelling and obsessing over CMMI and its supposed incompatibilities with agile? Yeah, I said it, _supposed_. There is nothing in CMMI that demands incompatibilities with agile practices, values, or the principles behind the manifesto. Any incompatibilities are due to either how people have inappropriately wielded CMMI, abused agile, or both. Most information/presentations about successes and failures of CMMI (with or without agile) have largely done little more than highlight what various organizations managed to do to satisfy appraisals. However, this compliance-driven perspective leaves out critical information about what CMMI actually works, how the appraisal is actually conducted, and how to use CMMI for actual improvement rather than appraisal compliance. In fact, most information and presentations on the integration of CMMI and agile have done very little to stem the tidal surge of misinformation and "CMMI malpractice" about how to actually work with CMMI -- both for the benefits of improvement as well as for getting coveted ratings. CMMI is a model. Models are tools. Before using any tool, users need instructions -- or at least they need to know what the tool is for and whether or not they've got the right problem solved by the tool. This lively, interactive, micro-tutorial will lay plain what CMMI is and how it works so that implementation of the model is clear thereby laying the groundwork for both the benefits of CMMI as well as achieving desired appraisal results. Properly used, CMMI can actually help lean and agile teams learn about themselves, find weaknesses in the way they work, improve their effectiveness and increase their performance. The session will share what I've done with clients for 10+ years that results in these outcomes -- while also achieving CMMI ratings -- while remaining entirely faithful to agile values and principles. The learning outcomes will prepare teams to pursue CMMI effectively with "level ratings" as a by-product of actual performance increases.

When organizations adopt an agile approach to development there is so much focus on the iterative nature of agile development that long range vision and strategic product design, "The Big Picture", can get lost. In this workshop, Certified Scrum Trainer and Agile Process Mentor, Jimi Fosdick, PMP, CST discusses the need to include long term product vision, coherent user experience and User Centered design and architecture along with specific best practices for achieving a coherent product that delights users and walks participants through hands on, game-based, exercises to achieve that goal. Topics will include: Discussion of Product Vision and hands-on experience crafting a compelling overall vision Discussion of User-Centered/Value-Driven design and hands-on exercises to incorporate user experience (UX) and software architecture early in the development process Explanation of the pitfalls of a lack of vision and so-called "hybrid" models for incorporating UX and architecture into agile projects including the exercise "How To Tell If Your Vision is Impaired"

Organizations are really bad at Risk Management. And the typical approaches to risk management are flawed - resulting in bureaucratic overhead and not much improvement in the performance of software development projects. Agile efforts have rejected bureaucratic and non-value adding efforts and in the process have rejected most of what is practiced as risk management. This is unfortunate - because the nature of agile development fundamentally changes how to benefit from effective risk management. Risk management is about managing uncertainty to reduce the probability and impact of unfortunate events and the maximize the realization of opportunities. This workshop builds on concepts from SEI's MOSAIC project and Eric Reis Lean Start-up to present a practical and proven to a systemic approach to integrating threat and opportunity identification and response into the management of Agile projects. Useful for typical delivery teams, this approach is particularly valuable in the large projects and large organizations.
http://submit2012.agilealliance.org/files/session_pdfs/Agile and the Nature of Decision Making.pdf

You care about security, but common secure Software Development Life Cycle (SDLC) practices such as traditional threat modeling and secure requirements analysis seem to be geared towards Waterfall development. What can you do? In this session we will explain the concept of Threat Modeling Express and model one of the audience member's actual applications, live, together. Threat Modeling Express is a two hour activity you do once a quarter that helps you put the right security requirements in your backlog (or other ticket/story/requirements management repository). It's extremely lightweight: you need a developer (yourself), somebody with security knowledge (possibly another developer), and somebody who represents business priorities (a product owner?). Together in a room you hash out the most common user stories/use cases, possible malicious intents, technical means to achieve those intents, group risk rating, and adding countermeasures to your backlog. At the end of the session you have group buy-in on the security risks you care about and how important they are relative to everything else. This is as lightweight as application security gets: attend if the words "lightweight" and "security" both appeal to you. Threat Modeling Express is an alternative to more rigorous / comprehensive design-level security activities such as threat risk assessments, traditional threat modeling, and architectural risk analysis.Threat Modeling Express sacrifices rigor in favor of speed. Threat Modeling Express is a process defined by Security Compass (an application security consultancy), but is really just describes a set of techniques that companies have been practicing informally for years. It's not proprietary and you can do it on your own without any third party assistance if you have the necessary domain expertise in-house. The speaker is one of the people who coined the term and has taught and used Threat Modeling Express at several large companies primarily in the financial services and utilities industries. NOTE: Although the speaker's personal agile experience is with Scrum, the process works equally well in other agile environments. More information about Threat Modeling Express: * http://www.infoq.com/articles/threat-modeling-express * https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032476372&CountryCode=US%20ForceRecrawl:%200
http://submit2012.agilealliance.org/files/session_pdfs/Threat Model Express_Agile 2012.pdf

As Agile has crossed the chasm into the enterprise, it is evident that "going Agile" at scale is vastly different from adopting Agile in small or medium sized organizations. This talk covers the critical role, practical responsibilities and tangible deliverables of the Agile Working Group (AWG), a dedicated set of internal Agile resources responsible for driving a sustainable adoption of Agile at the enterprise level. Developed as part of Agile Alliance's "Supporting Agile Adoption" workshop, this presentation aims to share proven practices for enterprise adoption of Agile methods.
http://submit2012.agilealliance.org/files/session_pdfs/Hesselberg_AWG_Handouts.pdf

This program will share Lean-Agile principles that guide both what to build and how to coordinate the teams that need to build it. We will cover how to apply these principles when there are several teams involved in creating software using either Scrum or Kanban development approaches. A common intent of all Agile methods is threefold: 1. Build the most valuable features 2. Build them efficiently 3. Minimize creating extra work The challenge to accomplishing this is not that great for one team working independently. However, when several teams have to coordinate, the challenges greatly magnify. When implementing software over several teams, we have found it to be valuable to manage the workflow from the perspective of what will provide value to the business – not quite the same thing as customer value. This can be used to guide how to slice work up into smaller chunks, enabling at least quick feedback, if not quick delivery, to ensure the right products are being built. A lot of thrashing can take place when teams work with poor coordination – greatly lowering efficiency. In large scale development, it is clear that working on the right functions, and coordinating their construction across teams is essential. Having teams coordinate amongst themselves has been the popular method. Unfortunately, this approach, typified by Scrum-of-Scrums, has a dismal track record. Having discovered the correct principles underneath large scale development, we now believe we understand why coordinating teams as a set of peer development organizations, can rarely be an optimal approach. Teams need to be guided by the value they are building, while self-organizing to improve the embedded feedback loops of development. The self-organization techniques required vary, depending upon several factors. These principles, not surprisingly, are directly related to the 3 intents mentioned above. This seminar will present both the principles underneath large scale feature implementation, as well as a few case studies demonstrating different implementations of these principles.
http://submit2012.agilealliance.org/files/session_pdfs/ScalingAgileWithLean_Agile2012.pdf

Find out how the Swedish police combined Kanban, Scrum, and XP in a 60-person project. This is a high-paced talk based almost entirely on photos, diagrams, and concrete examples. We’ll go beyond the basics and walk through the project step by step, from customer engagement, to the "daily cocktail party”, test, cross-team synchronization, multi-layer kanban boards, version control, metrics, and more. The project was finalist in the Swedish “Project of the Year” awards for 2011. We start with an organization in desperate need of a new way of doing things, and finish with cross-functional teams all working in sync to develop a scalable, complex system while continuously improving their development process.

All software projects have risk. Often the most valuable projects carry the most risk. Other industries also encounter risk and generate value by understanding and managing that risk effectively. Todd and Olav explore some of the techniques used in a number of risky businesses such as product development, oil and gas exploration, investment banking, medicine, weather forecasting, and gambling. They also present studies of software development uncertainties and highlight how software practitioners can learn from better understanding the uncertainties and dynamics. Through this process they introduce techniques and approaches to risk and risk management including utilizing real options and how this helps manage risk for software practitioners.

The continuing knock on XP, Scrum and Kanban is that they may work well for small, collocated teams, but they do not scale to the needs of the larger software enterprise. In this presentation, Dean Leffingwell will finally dispel this myth by describing the Scaled Agile Framework™, a well-defined and publicly available set of practices which have been used to successfully scale Lean|Agile development to hundreds—and even thousands—of practitioners at companies like BMC Corporation, John Deere and many others. Results typically include quality and productivity improvements of from 20-50%, along with increases in employee engagement and job satisfaction. In this presentation, Leffingwell will describe how the three key Agile constructs — team, backlog and timebox— can be scaled to the program and portfolio levels of the enterprise. However, since simply making Agile things bigger does not necessarily keep a system lean, Leffingwell will describe how the framework a) keeps work in process visible and limited, b) keeps backlogs and queues short, c) uses cadence and synchronization to align teams to a common mission, and d) applies system-level continuous integration to facilitate fast customer feedback. The presentation also includes a description of kanban systems to manage the flow of the business and architectural epics that drive the agile programs. The presentation concludes with a discussion of how lean thinking executives are instrumental in helping the enterprise achieve the ultimate business benefits that these innovate processes can deliver.
http://submit2012.agilealliance.org/files/session_pdfs/Agile2012 rev4.pptx.pdf

Agile software delivery strategies have taken organizations by storm, and those very same organizations are now scaling agile strategies across the entire IT organization as well as on very complex projects. Agile strategies are even being applied on enterprise architecture teams and are proving to be successful in practice. This presentation overviews IBM’s Agile Scaling Model (ASM) and how to take an agile approach to enterprise architecture. It also summarizes industry data exploring the effectiveness of agile strategies and of various enterprise architecture strategies.
http://submit2012.agilealliance.org/files/session_pdfs/Ambler Agile EA.pdf

Agile methods depend on effective cross-functional teams. We’ve heard many Agile success stories…at the team level. But what happens when a product can’t be delivered by one team? What do you do when the “team” that’s needed to work on a particular product is 20 people? Or 20 teams? One response is to create a coordinating role, decompose work, or add layers of hierarchy. Those solutions introduce overhead and often slow down decision making. There are other options to link teams, and ensure communication and integration across many teams. There are no simple answers. But there are design principles for defining workable arrangements when the product is bigger than a handful of agile teams. In this talk, I'll cover principles and practices and explain how they work together to address coordination, integration, and technical integrity. These are the principles and practices I'll illustrate. 6 Principles: Manage dependencies in the backlog as much as possible
Aim for long-lived cross-functional teams
Go as far down the technology stack as feasible
Organize teams around context boundaries rather than component boundaries were ever possible
Make cross-context communication explicit
Avoid late learning Technical Practices: Continuous integration (CI) within context
Integration across contexts at some other interval (keeping in mind “avoid late learning”)
Mutually agreed upon and developed automated test across context boundaries
Architectural & coding standards
Technical reviews Social Practices: Scrum of Scrums
Integrating Teams (keeping in mind “avoid late learning”)
Decision Boundaries
Component shepherds
Tech council
Product council
I've attached a PDF of the current version of my slides on this topic. I'm sure they will evolve by next August.
http://submit2012.agilealliance.org/files/session_pdfs/ScalingAgileTeamsDerby2012.pdf

As Enterprise-level organizations look to maximize the effectiveness of Information Technology and Software Development activities through adoption of agile techniques, it is common that agile development practices may interact or be impacted by other disciplines already entrenched within the Enterprise. This talk will explore three specific Enterprise disciplines that commonly interact with agile / lean software development: * Enterprise-level Process Improvement Activities driven through Six Sigma Methodologies (DMAIC, DMADV, Kaizen) * Business Process Management (BPM) * Enterprise Configuration Management (CM) For each discipline, recommended integration patterns will be presented to describe how agile development activities can improve the effectiveness of these common Enterprise disciplines. Discussion will also outline recommended services that staff supporting each Enterprise discipline (Six Sigma, BPM & CM) should provide to optimize the software delivery and innovation that can be achieved using agile and lean development techniques. The presentation will also focus on the unique knowledge, skills, abilities, and perspectives that Six Sigma, BPM & CM practitioners have and how often they can integrate with agile development efforts to help teams mitigate specific challenges. Discussion will highlight specific messaging strategies and patterns to ensure effective collaboration between core agile development staff and staff supporting other Enterprise disciplines. Lastly, the presentation will provide messaging strategies to deconflict the core activities of agile development from the core activities of Six Sigma, Business Process Management, and Enterprise Configuration Management. All materials shared during this presentation have been compiled during a 4+ year Enterprise-level change management effort embarked on by a large United Stated Department of Defense organization to adopt agile software development within an Enterprise that was proficient at Six Sigma, BPM and Configuration Management prior to adopting agile.
http://submit2012.agilealliance.org/files/session_pdfs/IntegratingAgileDevSixSigmaBPMandCM-Presented.pdf

Test plans are often secondary to story tests (aka acceptance tests) for an individual story.While this helps focus on finding the value of a story, it often missing the mark in an enterprise setting where real value comes from delivering a collection of stories. Large scale (enterprise ) agility often goes beyond a single story and spans stories and teams. Story maps are an excellent tool for visualizing cross cutting needs like testing across stories and other challenges that cut across teams. Story maps are a simple and excellent tool that foster cross cutting thinking and learning. Along with connecting testers who care about testing that spans stories, story maps are also excellent tools for connecting other cross cutting perspectives: architecture, user experience, sub teams and end user documentation. This session will teach participants to use story maps to address the many challenges that face large scale (enterprise) agility. Participants will work in groups to utilize story maps as tools for situational challenges and realities faced by multi-team and distributed team agile usage.
http://submit2012.agilealliance.org/files/session_pdfs/StoryMapsTestPlansAndOtherCrossCutting.pdf

Before Agile can scale as the primary mode of developing software, an Agile accounting standard needs to be developed to enable CFO’s to understand and leverage one of the most quantifiable and compelling benefits of Agile software development. In this hands-on tutorial, we will walkthrough the problem, map current accounting standards to an Agile project accounting model and walk through a practical and defensible solution that participants can customize and implement.
http://submit2012.agilealliance.org/files/session_pdfs/Agile2012_Agile Accounting Presentation(1).pdf

Scrum works great with small, focused teams on small projects. What happens when you need to deliver a medium to large sized program that require more people? Scrum gives no guidance on scaling. There are books and ideas out there (“Scrum of Scrums”, Integration Scrum teams) but none have delivered reliable results. These techniques often reduce the sense of collaboration and agility as the programs get larger. Decisions feel more autocratic, teams have a lower sense of control and happiness. Dynamic Governance (see http://www.governancealive.com/dynamic-governance/) may provide the answer. Called by some “Scrum’s big brother”, Dynamic Governance is an organizational method that uniquely combines best business practices with the principles of cybernetics and systems thinking to deliver a decision-making mechanism that works at scale. Developed in The Netherlands, it has been used successfully in organizations for over 40 years. This workshop will demonstrate how Scrum is a Dynamic Governance system for 1 team. It suggests some improvements, particularly for retrospective meetings. However, the workshop will focus primarily on applying Agile philosophy and the 3 principles of Dynamic Governance to design organizations at different levels of scale, including top management and organizational units that are not directly involved in the production of software. Decisions are made quickly, are biased toward action, and stick.
http://submit2012.agilealliance.org/files/session_pdfs/Meet Scrum’s Big Brother, Dynamic Governance v3.pdf

More than 10 years after the signing of the Agile Manifesto, agile is now officially mainstream. PMI is offering an agile certification and you can't hardly find an IT job description that doesn't ask for some sort of Agile experience. As a community, we've become pretty good at setting up agile teams and delivering agile projects. The next frontier for agile methods is tackling the enterprise and one of the toughest nuts to crack will the the traditional PMO. In larger more complex environments, it isn't sufficient to pair a single product owner with a single team and expect that the work of the business is going to get done. We are dealing with larger, more diverse groups of stakeholders, stakeholders who's needs often compete for the attention of the team. Furthermore, the teams have to work together in more complex ways that require tighter integration across teams to deliver larger, more complex feature sets. This talk will explore patterns for dealing with more complex organizations, managing interdependencies between teams, and balancing tradeoffs to optimize the project delivery organization. The key question to answer is 'when will we be done, and what will we get for our time and money'. We want to give the PMO a way to answer this question without having to resort to traditional plan-driven approaches. This talk will lay out just such an approach.

This presentation shows how to apply Monte-carlo simulation to Scrum and Kanban project models, and then use that model in a variety of ways for experimentation. The results can be used to build a date, staff and cost forecast for projects, and to find what development factors (defects, scope-creep, etc.) are causing the most impact. If you hate estimation, this session demonstrates how to mine data from an existing lifecycle management tools, and then model your process to determine what estimates will make the biggest difference in forecast, allowing you to eliminate other (un-necessary) estimation effort. Agile teams and Executive Management of larger enterprises are often at political odds when it comes to needing estimates, delivery forecasts and the impact of outsourcing. Through the use of modeling and simulating Agile projects as described in this session, you have techniques for quickly answering tough management questions without overburdening the development teams. Modeling and simulating potential project outcomes hundreds of times (using estimate ranges rather than single values) achieves a higher degree of outcome certainty leading to accurate forecasts, and well-informed management decisions. Finding insight from cycletime and other metrics that can be automatically extracted from lifecycle management tools makes modeling and simulation more accessible than ever before. During this session, the process to answer and solve the following questions will be explained - 1. How to reverse engineer and interpret historical data from lifecycle management tools. 2. Does it make economic sense to outsource development or testing? 3. What is the dollar cost of poor quality code (defect leakage)? 4. Do I manage the added-scope problem, or code quality problem first? 5. How do I get the staff I need? By the end of this session you will understand the basics of modeling and simulation, understand the types of problems simulation solves, how to communicate likelihood of outcomes with executive leadership, and be positioned to start applying these fundamentals on your own teams and projects.
http://submit2012.agilealliance.org/files/session_pdfs/Modeling, Simulation & Data Mining - Agile 2012 (Magennis & Maccherone).pdf

We know that we can only manage what we can measure – but how do we measure productivity, predictability, quality and value delivery of our agile projects and initiative? This interactive session was inspired by the response to Jim’s blog by the same title that drew over 8,000 hits in 4 days and will explore how we should (and shouldn’t) measure the success of agile projects and initiatives. As agile practices have spread widely during the last decade we still struggle with measuring progress in the same ways we did with traditional projects. Is velocity just another productivity measure that we shouldn’t be using? How is it helpful? What else should we measure – and how do we effectively measure value or cycle time? Jim Highsmith and Pat Reed will facilitate an exploration of these questions from both conceptual and very practical perspectives.

To some, the combination of Capability Maturity Model-Integration (CMMI®) and Scrum is akin to the mixture of oil and water. We will alleviate some of the concerns that participants may have when CMMI® is introduced into a Scrum environment. At a high level, attendees will be able to crosswalk their Agile/Scrum artifacts to satisfy evidentiary requirements for a Maturity Level 2 Standard CMMI® Appraisal Method for Process Improvement (SCAMPI A). Then they will learn how to tie up the loose ends with other standard project management artifacts. The end result will be a fully-populated Scrum/CMMI® alignment matrix.
http://submit2012.agilealliance.org/files/session_pdfs/Geocent Scrum CMMI (without animations).pdf

Agile teams speak in points and iterations, but project and business managers think in terms of dollars and dates. This conceptual and language barrier makes strategic business planning, funding, and progress management a significant challenge for sustained large-scale Agile. This session will include multiple case studies from large-scale Agile adoptions that we were part of and have supported over the past 7 years and how Agile values/principles went beyond just the development organizational boundaries into strategic planning and management.
http://submit2012.agilealliance.org/files/session_pdfs/Dollars and Dates are Killing Agile final.pdf

This workshop introduces an integrated set of collaborative team games for the entire risk management process. It starts by explaining the significance of risk management on projects by reviewing research statistics on the billions of dollars wasted annually on projects that fail due to poor risk management. Having established the importance of risk management a set of 8 new team based tools for agile risk management are introduced. By deliberately moving risk management from a project management activity to a team activity we dramatically increase the collective knowledge, visibility and in-depth insights into the issues and solutions for project risks. Through collaborative games each of the 6 PMI Risk Management steps are recreated as highly visual, team based activities that then create risk avoidance and risk mitigation stories for the product backlog 1. **Plan Your Trip** – (Risk Management Planning) a. 4Cs - Consider the Context, Costs, Consequences and Choices b. Deposits and Bank Fees – understanding features and risks 2. **Find Friends and Foes** – (Risk and Opportunity Identification) a. Doomsday clock, b. Karma-day c. Other risk identification forms (risk profiles, project risk lists, retrospectives, user story analysis, Waltzing with Bears - Top 5-10 for software) 3. **Post Your Ad** – (Qualitative Risk Analysis) a. Investors and Help Wanted – classification and visualization of opps and risks b. Tug of War – project categorization 4. **Today’s Forecast** - (Quantitative Risk Analysis) a. Dragons Den – next best dollar spent b. Battle Bots - simulations 5. **Backlog Injector** – (Risk Response Planning) a. Junction Function – choose the risk response path b. Dollar Balance – Risk / Opp EVM to ROI comparison c. Report Card - Customer/Product owner engagement d. Inoculator – inject risk avoidance/mitigation and opportunity stories into backlog 6. **Risk Radar** – (Risk Monitoring and Control) a. Risk Burn Down Graphs - Tracking and monitoring b. Risk Retrospectives - Evaluating the effectiveness of the risk management plan c. Rinse and Repeat - Updating risk management artifacts, revisiting process These techniques overcome many of the correct-but-not-sufficient aspects of traditional risk management: * Poor engagement - dry, boring, academic, done by PM, does not drive enough change * Done once – typically near the start, when we know least about the project * Not revisited enough – often “parked” off to one side and not reviewed again * Not integrated into project lifecycle – poor tools for task integration * Not engaging, poor visibility – few stakeholders regularly review the project risks Why so visual? Visual representation helps engage the left and right hemi-spheres of the brain. They allow us to tap into our spatial awareness / memory to avoid forgetting about risks and are the reason today’s military use visual tokens to represented enemy forces, despite having access to sophisticated tools. The impacts of forgetting about them can be fatal. The same goes for project risks.