CONSCIRES AGILE PRACTICES

Scrum and CMMI with Jeff Sutherland, co-founder of Scrum and Kent Johnson, CTO of AgileDigm. Kent co-authored the primary CMMI book on interpreting the CMMI and is the CMMI Maturity Level 5 Lead Appraiser for Systematic. Our presentation will briefly review how Systematic went to hyper-productive Scrum while maintaining CMMI Maturity Level 5 status and share how companies that want to go to any CMMI level 2, 3, 4, or 5 can cut the cost in half by using Scrum.

Quantified, Measurable and Testable. Specified so they are representative of the real requirements that your Stakeholders have, that they are easy to change, and in such a way that Business and your Product Owner can prioritize and the engineers/developers can develop towards them.

Some examples of Critical Product Qualities: User-friendly, Security, Performance, Reliability, Maintainability, Intuitiveness, Style, Correctness, Expandability.

Today, more and more sw and system developers are experiencing project delays and failures caused by unsatisfactory project qualities. The system developed has all the functionality, but the users are not satisfied with some product qualities like the performance, usability, security or reliability. In this focused workshop you will learn, and practice, how to specify the critical product quality requirements for your projects.

1st session: What are Product Qualities, Why are Product Qualities critical, How to specify Product Qualities, Standards and templates for specifying Product Qualities

2nd session: Practical Workshop on specifying Product Qualities for your projects in your domain.

3rd session: Case study.

How does one become a Master Craftsman? Practice, practice, practice. In this workshop we will get our hands dirty exploring some of the more common techniques for practicing the software craft. We will perform code katas, working on our sense of code smell, do some randori, and more. Bring your laptop and prepare for a mental workout. You will learn exercises that you can use to train yourself at home and teach your colleagues.

Theatre and software have much in common: teams create unpredictably innovative products that emerge from the making process itself; they create new things to a deadline; and they use an iterative rather than a sequential method. They make a prototype, not a plan; they see if it works; when it doesn’t, they make another, reconceiving to create new ideas out of conflicting ones; they see if the new one works; when it doesn’t, they make another; and so on until they have it right. The Artful Making workshop will explore some of what managers and software developers can learn about how theatre artists do that kind of work. The workshop will provide opportunities to learn and practice some of the things actors do as they prepare for creative work, engage in full collaboration, and function productively at the scary edge of their powers. Exercises and discussion will focus on three aspects of any artful collaborative process: Preparation, Concentration, and The Edge.

You’ve learned the principles and practices of Scrum. Your teams are agile—as far as the basics go. Now you’re ready to take the next step in your personal development as a ScrumMaster or agile coach. Join Lyssa Adkins in this experiential class, which offers skills essential for coaching agile teams. Lyssa shares practical and provocative techniques from the world of professional coaching, facilitation, collaboration, and conflict management. She demonstrates—and you’ll practice in small groups—what it means to apply the “coach approach” to agile teams. Learn how to create the environment for continuous improvement right from the beginning and discover the key points that ensure the product owner, customer, stakeholders, and coach are all doing their parts to support the team. Recognize when to coach the whole team and when to coach individuals. Take away exercises and tools you can use with your team immediately, and start on the path to become that agile coach who activates teams to create astonishing results. Come ready to learn and to make a personal commitment to become a great agile coach.

There has been much debate about how a Kanban System for Software Development is either similar or different to a Scrum approach. While many of the principles and practices are compatible with those of Scrum, some may appear to be at odds. This workshop will begin by discussing one definition of a Kanban System, followed by an exploration of the similarities and differences between Kanban and Scrum based approaches to software development through games, simulations and debate. Attendees should come away with an understanding of the benefits of both approaches and how and when to apply them, whether independently, or jointly.

Self-organization of human beings is a tricky thing. Agile coaches, especially ScrumMasters, are constantly challenged with how to motivate/persuade/trick their teams into doing things, without telling them what to do, but there is very little information or training on this topic. Allowing a team to self-organize along the lines of “oh well, they’re all adults, they’ll figure it out” is just as irresponsible as reverting to the command-and control school of management. This tutorial presents an approach utilizing leading-edge research and techniques from social complexity science and team dynamics. Learning outcomes
* An understanding of the social psychological and complexity aspects of teams
* A Sense-Making model for analyzing teams and situations
* A method for designing non-intrusive interventions for changing team dynamics
* Learn what’s really needed to get people to work together as teams.

This workshop will explore the culture of improvisers, and nail individual communication behaviors that block the creativity of groups (including the groups of voices in our individual heads). We will leave all our “rules” at the door and replace them with a few principles that set us free, and guide us, effortlessly, like gravity, to group creativity and collaboration.

As Scrum teams mature their desire to work collaboratively with internal stakeholders and external customers increases. In this deep dive session Luke Hohmann will show how the serious games described in his book Innovation GamesR: Creating Breakthrough Products Through Collaborative Play can be used to improve many Scrum practices. You will learn how to:

- Identify customer requirements for through the Product Box game
- Improve retrospectives through the Speed Boat game
- Prioritize your backlog through the online game Buy a Feature
- Plan a successful project through the game Remember the Future
- Develop better release plans through the game Prune the Product Tree

One of the most important parts of a ScrumMaster’s role is to remove barriers. Lean Six Sigma’s DMAIC methodology, used to solve difficult problems with unknown root causes, should be a powerful tool in the Scrum Master’s arsenal. Unfortunately, with all the blogs, articles, books, lectures and tweets on Scrum best practices, there are very few on utilizing Lean Six Sigma methods for solving barriers within a Scrum deployment and even fewer practitioners. This may be due to several factors, including misunderstandings in both worlds, resentment from legacy “process” improvement methods, bad historical application of Six Sigma within software development, no cross-realm expertise, and more. This presentation will focus on debunking the myths and misconceptions and present intuitive ways on using Lean Six Sigma methods as a powerful barrier-busting tool in the ScrumMaster’s, management’s and the team’s arsenal

How should we scale Scrum beyond individual projects and find a value-adding role for middle-level managers? How can PMOs avoid being process police and instead truly support Agile teams, enable enterprise rollout of Agile methods, and sustain long-term Agile adoption?

Learn how industry leaders are scaling Scrum with Agile PMOs that:

Sanjiv will share principles and techniques for the Agile PMO, and discuss how those concepts are being applied in the industry to scale Scrum to programs and portfolios of multiple agile and non-agile projects.

This session will present some less known ways of thinking about work management and backlogs and co-existence with traditional methods in large organizations.

In my experience in implementing scrum in larger and more traditional organizations (10s of teams), work management is a difficult problem. In particular Agile style elaboration of requirements causes difficulties in commitments. project status reporting, work allocation and resource planning.

Is there a way to address these issues in an agile manner that recognizes what actually happens in projects? I believe there is and I will present my experiences in these areas.

In particular, I have been rethinking the role of backlogs and releases and will present some (possibly) new way to consider them.

We would like to propose an hour session containing 5-6 Pecha Kucha presentations (20 slides, 20 seconds each).

The overall topic would be “Building Scrum Teams Effectively”. If this session is selected, the topic should be published, submissions for the available slots solicited and selected. We have experience with Pecha Kucha sessions and can organize this if required.

There is a thread that runs from the work of W. Edwards Deming and Joseph Juran, to the Toyota Production System to Six Sigma practices that firmly roots Scrum in historically successful quality practices.

We will explore these connections and elaborate on:

No Scrum implementation lives in a vacuum. Organizational culture, defined by William Schneider as “the way we do things around here in order to succeed”, is the air a project breathes day and night. The question we want to pop during this session is if the air we currently inhale is healthy enough for Scrum to live, thrive and sometimes nothing more than survive.

Based on the simple but incredibly powerful model of organizational cultures defined by William Schneider, participants explore their world from a new perspective by posing some crucial questions and comparing their answers to those of other attendants. Inquiries such as where I stand today, where I dream of being tomorrow and wich are some of the necessary steps to get there will be analyzed by attendants as the group of heterogeneous individuals they are.

In this presentation we show how an agile enterprise not only runs internal development processes using Scrum but also its collaboration with customers and suppliers based on cross-company Scrum-Teams and an agile collaboration platform. We will highlight challenges and scenarios of a large, real-world Scrum project.

This presentation will explore the how an Innovation Centric Culture and a Lean Operational Model are necessary in creating a Customer-Pull “Agile Business Framework.”

This “Agile Business Framework” leverages Scrum, and has proven to be effective in providing a delivery framework necessary for scaling Scrum upwards of 20+ teams over 4 core sites.

We will discuss the trials and tribulations of promoting localized optimization while scaling Scrum as an organization.

There will be content shared on why non-R&D activity needs to be included in the Lean Operational Model to effectively and regularly deliver in a customer-pull model.

We will show how Business Value is created and how to manage Business Value from the scope of “Release” to “Minimal Marketable Features” down to “User Stories” delivered by the smallest fractal Scrum team.

People often say “We’re doing Scrum at my company.” What does that really mean? Unfortunately it usually means the organization has picked a small number of Scrum practices they attempt to do without really paying attention to the overall results. If a company is “doing Scrum well” it may even mean they are doing as many Scrum practices as possible. However, in practice there is a big difference between “doing Scrum” and “living Scrum!” Companies LIVING Scrum perform better than companies doing Scrum. They see higher morale among their employees. They use Scrum as a tool rather than a process. Most importantly, living Scrum means being devoted to the principles which drive success rather than hoping the practices will drive success. Come learn the basic principles and how to internalize them so your team, organization or enterprise can LIVE Scrum rather than DO Scrum!

Our industry has pretty much accepted the value of automated developer tests and the practice of TDD is slowly making its way into being a mainstream practice of craftsman programmers for ensuring code’s correctness as well as aiding in its design. Similar benefits can be delivered with Acceptance Test-Driven Development (ATDD), a test-driven approach to implementing product backlog items.

We begin with an introduction to the core ideas and rationale behind ATDD, creating a baseline for understanding what kind of benefits one might expect from adopting the practice and for recognizing the dynamic that enables those benefits.

We discuss common variations of ATDD, ranging from completely manual to a fully automated process with executable acceptance tests, and from a serial process to a parallelized process. Before opening the floor to questions, the presenter walks through an example scenario, illustrating what the discussed artifacts might look like in practice.

Self-organization is often referred to as a best practice. Which is strange, because it is actually the default practice of complex systems. Self-organization has relationships with anarchy, emergence, evolution, and self-direction. But none of those are the same. Complexity science can teach us what the differences are.

The Darkness Principle and the Conant-Ashby Theorem are two examples of scientific concepts that explain why we do things the way we do in Scrum, and why delegation and empowerment are crucial.

There are different ways of delegating work to a self-organizing team. First of all, people’s level of experience with empowerment is important. Second, there are 7 authority levels that can be selected per task. Third, one can choose between delegating to teams vs. delegating to individuals. Fourth, the order (time-dimension) of delegation of work is important. There is a handy checklist for making sure you’ve properly delegated work to a self-organizing team.

After delegating work to an empowered team, a leader or manager is responsible for managing himself, managing top-level management, managing the empowered team members, and managing the environment. All stakeholders may have to change their attitudes to make self-organization work.

Finally, we can distinguish 4 types of trust between a manager/leader and team members. They all have to be in place, or else self-organization may fail.

Scrum is a simple framework; the terms and rules can be explained in a few bullet-points.

Unfortunately, novice Agile practitioners often apply Scrum’s techniques in simplistic ways, forcing inappropriate practices onto their teams in ways that actually harm the organization.

Thus the too-frequently heard lament from many organizations: “we’re supposed to be Agile now, why aren’t things better?”

Some successful Scrum practitioners work at a level of underlying truths which cannot be easily distilled into bullet-points. Their mind works in terms of Scrum, rather than applying tools and techniques. This is the primary difference between being highly successful and being somewhat successful. We may being projects to successful conclusions but were you really successful? Have you fostered a change in the way the organization goes about its business or have you just completed another project?

This session will help you gain insight into understanding and putting into practice a different way of thinking about practicing Scrum. Scrum can be applied to many different types of results-based goals. Whether your goal is to deliver products, develop software, further business development, achieve personal goals or tame some other unknown endeavor, you will gain insights, experiences and techniques you can take with you wherever you are.

How is a judge to decide on a case? Written law is general, abstract, concrete but not comprehensive. Particular cases, context, subjective issues are not considered in the text. Why is it not trivial to be a judge or a jury member? Because they have to interpret the law. And what have they used for centuries now to support their interpretation? Cases and spirit. Examples and intuition. Both ends meet. And what about Scrum?

Scrum is simple and hard. Why so? Because its definition is clear and concise, but in order to use that definition in real life we need to interpret it depending on the context. We clearly got the equivalent to case law: case studies and good practices have served us well for years now. Examples let us map, consider deltas and readjust depending on the context. But spirit has somehow been absent from the discussion. Or at least it has not had the prominent and explicit role it deserves. But can spirit be portrayed?

During this session we will try and seek to grasp, experience and hopefully gain understanding of the spirit that lives and breathes at the core of any healthy Scrum story. Through the use of interactive activities and brief discussions attendants will take a sip of the spirit, trying to learn with their souls and bodies what we talk about when we talk about Scrum.

Scrum and agile is well defined as a project approach, even though there is still much to learn. As agile projects work better and better, an increasingly common problem is not the project itself, but the surrounding culture and management structures.

To realise business benefit in super speed you need to rebuild the organisation around the projects.

It is one thing to deliver a single successful agile project but quite another to change the culture and organization around the project to ensure successful agile processes are repeatable long term. In some organizations the surrounding culture and structures may be too much even for that single successful agile project.

The seminar focuses on what I over the last ten or fifteen years have found to be needed from management teams and line managers to ensure successful projects. Examples and learning points derived from coaching people and teams in various organizations over several years will be shared with you.

We will follow a project from A-Z while we discuss what exactly (techniques and practices) managers need to do when.

After more than four years of successful experience with Scrum (worldwide 200++ projects), SAP has decided to introduce a lean software development model at a large scale in its development organization based on Scrum as core methodology.

For each organization, introducing Scrum at a rate of thousands developers a year makes a unique kind of demands.

We describe the approach to tackle the key challenges including

Amazingly, only 7% of communication is based on words while 38% is based on tonality and 55% on physiology. This workshop teaches rapport skills through a series of exercises.

We will briefly review the ART model (Acknowledge/Accept + Respond/Respect = Trust) to review verbal (words) rapport skills to contrast with non-verbal rapport. Techniques commonly used in NLP (Neuro Linguistic Psychology/Programming) such as matching angle of the spine and head; matching tonality will be presented. Multiple exercises will be used to understand the model and provide an opportunity to practice non-verbal rapport. One exercise is practice of matching physiology – involves working in trios: Speaker, Listener and Observer. Everyone rotates through active role as speaker matching the physiology of the listener. Observer is there to learn by watching. Listener shares feedback on how it went. Observer comments on how it appeared. This is repeated with tonality.

This talk will describe two large organizational implementations of Scrum which included 5 distributed teams with offshoring, building sales support related applications. The projects are ongoing and the talk will focus on the first 9 months which set the early tone.

Both good news and bad news will be presented as this talk is not about how wonderfully things went, but about choices made and their consequences. Topics covered will include stakeholder involvement, training, estimation and planning, response to issues, team structure/environment, and management involvement.

After a successful transition from a prescriptive waterfall process to Scrum and XP, the Corporate Internet Solutions group at Nationwide Insurance found velocity and efficiency stumbling due to the competing and vague priorities of corporate silos and a reliance on Just In Time Requirements Definition.

This presentation discusses how the team evolved the traditional Scrum process to better manage 17 dependent projects, and reluctant internal business partners, through a combination of activities including clear Pre-Discovery activities, scenario planning, RITE usability testing, and a kanban visual management system.

The kanban is a decoupled request pipeline where requirements are graduated in a progression from nursery through to high school, at which point they are ready for Release and Sprint Planning. Decoupling the requirements pipeline from the development iterations allows for, among other things, improved dependency management, better leveraging of scarce experts and the ability for business stakeholders to work on a different cadence.

This session is focused on the critical factors that help or disrupt Scrum teams from putting Agile values in practice. Its background is a research made by Sabbagh for his Master’s dissertation for a major Brazilian university. He interviewed team members and ScrumMasters of 16 different IT projects from 9 Brazilian states, confronting the data with testimonies obtained from an in-depth research made at the email archives of the Brazilian Scrum User Group.

The attendees will interact and collaborate through participative games. They’ll be encouraged to share their experiences and perceptions of what those critical factors are, iteratively analyzing and comparing them to the research findings. Real solutions will be presented and discussed.

Very important and interesting findings have been raised by this research and some are really surprising. They will be analyzed with theory (e.g. organizational behavior, communication and change; toyotism, Scrum theory) in a suitable light way.

Scrum brings software development into much closer alignment with Deming, and a review of Deming’s teachings and a fresh look at the application of his principals can help us use Scrum to make an even more powerful impact. This presentation will discuss how we can apply Deming’s teachings using Scrum. Specifically, the presentation will discuss: 1. Deming’s 14 management principals 2. Quality = Results of work efforts / Total costs 3. The “Plan-Do-Check-Act” process

The science of positive psychology is far more than thinking good things, holding hands and singing Kumbayah. It’s full of complicated formulas, laboratory experiments and hard data – and it has a lot to teach us about team performance. Come to this session to learn why the leaders in team coaching training focus on positivity as a doorway to improved performance and why a psychology book called “Positivity” has hit the mainstream press in a big way. Would you like more creativity and less pointless conflict on your teams? Positivity can help you get there. In this session, we explore how.

The software development industry has a poor track record for developing and employing effective metrics. Most of the metrics employed are tangential to the true goal of software development (which is delivering business value) and are thus ill-regarded by developers, especially agile developers. However, good metrics are important to management, in order to understand the status and progress of their teams, and to make projections into the future. Therefore, we must provide meaningful metrics that give useful information to the business – but also enforce agile values.

In this class, we discuss the following: velocity, burndown graphs, running tested features, EVM metrics (CPI and SPI), and earned business value. This discussion includes methods for calculation, how to present them to management, why they’re important, and how they enforce (or fight against) agile values.

Experience on how we took SCRUM mainstream at HP.

First: I’ll introduce the audience to the problem we had at our hands… all this different and isolated teams using Scrum that wanted to take it more mainstream to their organization but had problems doing so.

Second: I’ll expose my scars to the audience on all the different routes we tried to take such as offering trainings, use of collaborations tools to be closer to the organizations, work on governance and guidance… just to fall into deadends.

Third: I’ll show how we used the Agile Manifesto and Scrum to put real attention to our organizations (individuals) and the interactions with them; and how the collaboration through a team of voluteer CSMs available to coach others took our Scrum implementation to a new level across the company.

Each section will take 15 mins with heavy use of pictures, leaving 15 mins for Q&A’s

This mini-course will introduce Business Value Engineering as one of the key engineering practices that must be continuously improvement.

After a brief intro, at each table each team will discuss what Business Value means in the context of the Product Owners’ business (product).

And how to estimate it, and how to measure it after the fact. Each team will be asked to quickly document the BV model.

After a partial debrief of this exercise, each team (table) will do a BVE mapping exercise based on the real conditions at the Product Owners’ company (or group or department).

Some results from this exercise will be discussed in the group.

Then we will lead a brief summary, to discuss implications, continuous improvement and next steps.

If we must do this in 60 minutes, each part will be short and tight.

If 90 or more minutes, then a more leisurely pace with more Q&A.

This presentation describes how Atlantico, a Brazilian R&D organization, implemented Scrum practices integrated with CMMI model for maturity level 5. The major challenges at the moment are described, and the means used to solve them. One key aspect of this presentation is the discussion of cases and results based on measured results within an organization that already had performance baselines and quantitative management for productivity and quality for traditional or non-Agile iterative methods before introducing Scrum practices. Through the combination of Scrum and CMMI, innovative practices were introduced in the organizational process resulting in a new style of management. Main improvements achieved were related to increase in productivity, directly influenced by high commitment and development of project team. Another interesting result was a methodology and model to integrate Story Points and Agile Estimation with our already established Use Case Points size and effort estimation approach.

We started as AnyCo, and we became AwesomeCo.

We spent two years applying various agile practices, trying to improve our project success rate.

Then we met Scrum, and 12 months later, we were a great team.

This is a case study of an actual mobile software company, whose name has been changed to protect the innocent.

I joined AnyCo to help transform it to AwesomeCo by applying agile practices. AnyCo’s initial software process was waterfall.

We eventually found and rigorously applied Scrum, with great results.

AwesomeCo now delivers truly great software products, with very high quality, predictable time lines, predictable costs, and satisfied customers.

I’ll share how we made the transformation, what prompted it, how I got the courage to do it, and our successes and failures.

The presentation includes:

Agility including Scrum began as a very successful approach to deliver development projects and is now well defined. The success of Scrum has made it possible to apply agile principles to other areas of the business, such as business change, line management and more.

Sales Driven Development moves Scrum, Lean and other agile frameworks and principles up to the enterprise level, where effects of synergy are critical. By forming multi disciplinary teams, with a high level of empowerment (budget responsibility), in other areas than software development an organization is likely to create the most powerful products. These products will enable the enterprise to survive in shifting markets.

We introduce how ROI-teams can transform technical development into business product development. In combination with one or more Scrum development teams the ROI-team develops products at the needed speed and the needed level. The seminar focuses on explaining the over-all concepts including several practical examples from real life.

With the growing popularity of Scrum throughout IT organizations the framework is being applied in a number of large and complex organizations. Many of these face challenges and impediments leading to the situation where Scrum faces the temptation of “institutionalization”. It is changed, tempered, or adjusted. Perhaps as a temporary measure, perhaps simply to help align Scrum with other processes, or perhaps it is meant as a necessary adjustment for the specific circumstances. What happens exactly when a change agent finds oneself in this situation? What are the trade-offs being made when Scrum, a fundamentally trans-formative process becomes part of the institution? Join to facilitators who will argue the pros and cons of this situation and invite the audience to participate in the discussion.

Enterprise Scrum is a “Scrum Writ Large,” a continuous improvement process modeled after Scrum, but scaled, using fractal thinking, to a much larger organization. It is not Scrum-of-Scrums. It was developed in late 2008 at Citrix Online, and has been iteratively improved since then.

Enterprise Scrum has quarterly sprint cycles, weekly standups, effort measured in “estimated team months,” and prioritization partly based on Net Present Value. Prioritization is performed iteratively, to avoid squandering developer time. Several resource allocation strategies were tried, everything from total self-organization to traditional approaches. Through a series of retrospectives and adaptation, a hybrid is emerging.

Evidence for Enterprise Scrum’s success is anecdotal, but strong: Executives know and plan against the engineering department velocity, remove blockers, and promote agile in their own departments. Because engineering can quantify its value, funding key engineering projects, including debt reduction, is understood and approved at the CXO level. We have seen situations where other departments voluntarily redirected their funds to the engineering department, because engineering could prove its high profitability.

Based on a large in-house software project, this presentation will illustrate how to incrementally evolve architecture and design for a system across Sprints. One of the principles that we adhered to during architecture and design evolution was: “use before reuse”.

At the start of the project, we identified some of the important cross-cutting requirements and desired architectural qualities of the system. But we did not create any up-front architecture. Instead we began by implementing one story without any architecture, and then refactored it to a layered, distributed architecture. We then implemented one more story and refactored to create the first version of an application framework. We verified the framework by implementing a couple of more stories through framework extension. Gradually more architectural features and patterns were introduced in the system through progressive refactoring. Similarly, design and implementation for complex stories was incrementally done through progressive refactoring.

According to the Gartner Group will companies that are trying to restrain their workforce Internet usages be extinct within the next 5-10 years. Children of today use twitter, Facebook, Google wave, as a normal part of their daily lives – it is their network and backbone! The social medias like blogs and twitter are to them what email and phone was to us and our parents. We call these children Digital Natives!

So how do we overcome the need for exposure and social interaction – both regarding recruiting and keeping skilled people in your organization, BUT also in high regards how can we use social media in our agile Scrum projects?

The next wave of Scrum adoptions will take place in systems development organizations. These companies require a unique approach and proficiency in scaling Scrum to successfully lead domains such as software development, hardware development, systems engineering, embedded software development, deployment, supply-chain, and firmware development that often require the complex coupling of agile and business stage-gate processes.

While other presentations might focus on scaling software agility, this session will focus on scaling agility beyond software to the broader complex systems development process. We will provide an overview of agile systems development with Scrum and the resulting opportunities for Agile practitioners including a pragmatic exploration of patterns based on real-world adoptions.