Assembling Scrum Teams: A Nonviolent Story**
Room: Oak Alley
Track: Jazzin' It Up
During the past seven months I’ve been forming and coaching three Scrum Teams for my company’s new office. I’ve started this process by carefully selecting people that fits well in the team and here comes the first lesson: technology can be learned but not every personality is good for working in a Scrum Team.
Instrumental in my recruiting process has been the help of a recruiting consulting firm that did the personality tests to all candidates. This consulting firm operated under the premises of what I’ve described to them as the personality profile of a Team Member and/or a Scrum Master.
Based on those premises the consulting firm adapted their test and interviews to detect some key personality characteristics like being intelligent and having a balanced life. Even more importantly they looked for candidates that were good communicators and able to empathize with others.
Passive-aggressive candidates were discarded in the first round, actually one out of every five candidates were discarded not because of their lack of technical skills but for the subtle (and sometimes evident) violence in their communication.
The result was a pool of candidates that eventually got hired and that so far have been able to create a friendly and compassionate environment where every opinion is respected and individuals collaborate in a natural way.
The big take away from this session is that non-violent communication (NVC) can and actually work if you have people with the right mindset. Once NVC is operating Scrum works fluently with great results, but not only in terms of product increments but in more humane aspects like team morale and retention.
Coaching tools are also easier to apply and provide greater results with people that are more reflective and willing to learn from introspection.
The following is a tentative outline for this session:
•From coach to recruiter, learning how to recruit (5 min)
•The psychologist lingo (5 min)
•Defining what is a Scrum personality (10 min)
•Not just making a job offer (5 min)
•Welcoming new people (5 min)
•Coaching on NVC (10 min)
•Extending NVC above and below (10 min)
•Harvesting the fruits (5 min)
**This is a 60 minute session.
A Roadmap for (Agile) Engineering Best Practices – What Every Non-Technical Person Needs to Know**
Track: Jazzin' It Up
21st century IT development requires building quality into our development practices, yet many software teams fail to implement technical practices that are necessary for long term success. Practices like automated builds, automated tests, automated deployments, continuous integration, and continuous delivery are now considered essential for the success of any software development project. Without these practices, the quality of software goes downhill and teams can no longer sustain their initial high levels of productivity.
However, understanding and implementing these practices can seem daunting. This session presents an easy to understand roadmap for implementing engineering best practices. The roadmap explains what the practices are, the tools that support the practices, a recommended sequence to implement, and effort to implement.
Though this topic is about engineering best practices, attendees do not have to be technical to get value from this session. The session gives a non-technical look at a technical concept and is great for any person in the organization managing, working with, or working on IT teams/programs.
This session will present the engineering roadmap below. In each section, we will discuss the concepts, the tools, and effort to implement. The format of the session is presentation style while addressing questions throughout.
Do This First
1. Version Control
2. Build Automation
3. Automated Unit Testing
4. Continuous Integration
Next Do This
5. Static Code Analysis
6. Dependency Management
Then Do This
7. Automated Integration Testing
8. Automated Acceptance Testing
9. Deployment Automation
**This is a 60 minute session.
Chocolate, Lego and Scrum Jambalaya
Dana Pylayeva, Bryan Beecham
Track: Rolling Down the River
This session will challenge traditional definition of a Scrum team, expanding it’s boundaries to include Operations, Release Engineers and Security roles
After a brief review of a problem statement, attendees will dive right into a Treats4U.com simulation game, inspired by ideas from “The Phoenix Project” and "The Goal". We will be analyzing market demands, prioritizing a backlog, estimating and working in sprints. We will deal with the constraints introduced by lack of automation and accentuated by a culture of functional silos. The session participants will be working with LEGO and chocolates while learning about theory of constraints, continuous flow, minimizing waste, deployment automation, amplifying the feedback loop, while learning to leverage the power of cross-functional teams.
Drawing on the collective knowledge and hands-on experience of session participants, this workshop will emphasize important lessons that they can bring back to their organizations. This will be facilitated with a number of mini-retrospectives throughout the session and finally a fishbowl style retrospective at the end.
High level session outline:
Introduction and problem statement – 10 min
Game setup - 5 min
Treats4U.com simulation game (3 sprints) - 60 min
Fishbowl retrospective – 15 min
High level overview of the game:
Roles: Product Owner, Stakeholders, Scrum Team ( Dev + QA), ScrumMaster, Ops( System/Database Administrators), Release Engineer, Security Officer
A couple of sister-companies under Treats4U.com umbrella is trying to become profitable in the global market, producing party favors for children and competing with each other to deliver maximum value.To better understand market demands in each geographical region, product owners of each company will be working with the global stakeholders. Stakeholders will identify LEGO animal design, type of chocolate popular in their country/region as well as the estimated value of the end-product. Based on the market analysis, product owners will be working with the Scrum team to build new products and deliver maximum value to the market. Additionally, each country will have regulatory/compliance requirements, which stakeholders will share with the Security Officer only.
Participants will be creating a product vision, estimating stories, prioritizing them based on the market value, as well as building and shipping them to the market. The LEGO and chocolates are used to reflect knowledge work and not just a physical task.
Since these are new companies, there will be some challenges to overcome for Sprint 1:
- All the dev/qa/integration and production environments will need to be built by Ops (i.e. development can’t start until the dev. environment has been built).
Giving the complexity of the environments and lack of automation, all the deployments will be performed by a single Release Engineer.
- Outside of the Scrum team, people are still organized by functional silos (everyone will be asked to wear a name tag with their assigned role and only perform tasks specific to their role).
Production deployment will be performed at the end of the Sprint 1. Once products are delivered to the market, stakeholders will have a right to “not like them” if products are not meeting original requirements.
At the end of the Sprint 1, participants will be asked to count the number of products delivered into production and accepted by stakeholders. They will lose points for any unfinished products, emphasizing “the value they produced over activities they performed”. In the Sprint1 retrospective, teams will look at optimizations that they can do to their current process and the constraints that impede their productivity. (Potential improvements –smaller batch sizes and the early feedback from the stakeholders).
After working through the Sprint 2, teams will compare the value points and discuss results of their improvements.
Security Officer will have a set of cards with “security issues” that he/she will be giving to individual team members at random throughout the workshop.
ScrumMasters and Scrum Teams will have to work to remove the impediments and deliver on Sprint commitments, while addressing the security issues.
For Sprint 3, facilitators will ask everyone to remove their name tags - companies introduced automated “push button” deployments and configuration management as well as built cross functional teams – now all the team members can help with building environments, development, testing and deployments. Value points will be calculated one more time at the end of Sprint 3 and results compared between the 3 Sprints.
Key takeaways will be derived from Fishbowl retrospective at the end of the session.
Jump-starting the Agile mindset: bringing Scrum & XP into college software projects**
Garrick West, Tina Ostrander
The world of software development is continuing to go Agile, and students need to get the mindset before they leave the classroom. This session will present how an academic & a practitioner got together to adapt Scrum & Agile practices and apply them to deliver a strongly hands on course that successfully designs and builds websites for small businesses in the community. We will discuss the specifics of the course materials, adaptations to the Scrum framework, and the introduction of XP technical practices. We will then answer question and pose a challenge to the audience for time-box small group discussion & summary: “What would you do to help jump-start the Agile mindset in this course”? Our specific highlights are as follows:
The evolution of bringing Agile into the web development capstone class at Highline Community College:
Our background in education & development
Course book selections
How the class works with real customers
Adapting the customer role for student & course needs
The teacher as CPO
Mapping the Scrum framework to a 10 week course
Addressing & fitting the elements of Scrum for the course for students:
Stand-ups & scrum of scrums
Definition of done
Overview of Technical practices live demos & "hands-on":
Test Driven Development
Source control SVN for teams, "Git for one"
Customer satisfaction: reaction to final project from customers.
Student perception: student's take on applying Agile.
Lessons Learned, plans for the future.
Questions & feedback.
Small group time-boxed discussion: “What would you do to help jump-start the Agile mindset in this course”?
**This is 60 minute session.
Love Agile: Life in Scope**
Room: Belle Chasse
We spend more time with our co-workers than we do our families, so it makes sense that we would embark upon a framework that allows us to keep communication open and solve problems before they become systemic issues. In 2012, after the end of a long drawn out relationship, it became clear that these same principles could be brought home. Since that fateful moment (and a wildly Agile partnership) I have tried, tested, and retrospected what it means to practice Scrum in life and love.
Whether we are a new team starting out or an established unit looking to improve moving forward, this discussion aims to bring many of the techniques and tools we have in our box at work into our kit at home. Special emphasis will be paid to distributed teams, managing big life changing events, and knowing your limits by combining theories of psychology and the practices of Scrum.
The goal is to spend less time worrying and more time enjoying. Laissez les bons temps rouler!
**This is a 60 minute session.
Long Term Adaptive Release Planning with Scrum**
Don Patti, David Bulkin
Track: "Throw Me Something Mister!"
This workshop uses scenarios and exercise to prove why long term release planning is beneficial, under what circumstances, and how to make it work. It is a mix of tactical (like learning how to estimate much faster with alternatives to Planning Poker) and strategic (understanding how to align with long term organizational plans).
This workshop intersperses short blocks of traditional lecture with frequent discussion and exercise. The majority of this session is hands on learning.
Release Planning is part of the Scrum Framework, but seldom practiced well if at all. Many teams provide their relative estimates, at Sprint Planning; to gauge how much work they can get done in a Sprint, essentially moving forward with no long term plan.
Because of this they are unable to budget correctly, align with marketing, sync with sales and provide the lead-time infrastructure often needs to support cutting-edge solutions.
Others work in a traditional command and control environment, and they try to make agile work with a multi thousand line integrated master schedule, which is even worse.
Release Planning has generally been described as a one-day activity that takes place after each release. In the Release Planning session the team provides relative estimates, and the product owner uses those estimates to prioritize and create a release schedule.
There is not enough room for adaptive planning in this model, other than Product Owner reprioritization, so teams essentially give up on release planning. SAFe puts a focus back on long term release planning, but doesn’t solve the adaptive nature of what is required and SAFe still proposes a short look-a-head of three to six months.
In this session we will cover why long term roadmaps are beneficial; how to integrate long term road mapping with pre-planned, quarterly release planning events as well as supplement them with frequent, pre-planned (as often as weekly) short sessions; and, how to get input from team members to adjust the plan to stay agile.
Along the way, we will go over many practical approaches, like how your team can apply high-speed estimation techniques to estimate large backlogs in a fraction of the time that poker planning would take, and how your work can mesh with other long range planning activities in your organization.
The structure is as follows:
Question the audience about their approach to release planning, problems, and ideas on making it better
Review the classical Scrum definition of Release Planning
Describe situations where long term release planning is beneficial
Exercise on high-speed estimation. In this exercise, each table will have a set of cards for which they need to create estimate. The first couple of minutes will be scripted so that they learn the high-speed games. Then, each table will work alone to create the estimates, some of which are above the typical 100 scale. Finally we will compare the estimates across the tables.
Learning about high speed estimation is crucial, as it allows teams to plan much farther out, and adjust their plans on a frequent basis.
Review of how to apply high-speed estimation to allow for longer term release plans that are updated more frequently as new ideas are created and more is learned.
Discussion then exercise at each table on how to structure release planning activities in different types of organizations, along with a model of attributes to consider when creating the schedule. We will guide the group through different scenarios so that they can define specifically what release planning could look like under various circumstances.
As an example a organization with distributed, large teams, and separate groups for brand management, marketing, sales, compliance, etc., would need a different release planning approach then would a co-located team without those dependencies.
**This is a 60 minute session.
Product Owner and Scrum Success in a Traditional Organization
Track: "Throw Me Something Mister!"
This session will relate the stories of 2 successful product development efforts that used Scrum very effectively in an environment attuned to traditional development. The session will feature commentary from both Product Owners who will describe and relate their experiences from which others can benefit (and perhaps find hope.) We will describe in detail how both people operated very effectively in the role and overcame obstacles and other inertia to produce very effective, quality products for large end user populations (in one case, greater than 100,000 users.) One system was a large effort (>80,000 hours) and significantly important to the operation of the company (as its account management system.) The other system, though smaller, was very technical in nature and provided the means to track software company wide including configuration management. The session will appeal to both technical and non-technical people.
The Agile Dashboard
Track: Hop On a Streetcar
There are more to Agile metrics than velocity and sprint burn-down charts. However, most Agile teams focus on velocity and target story points which leads to executives misusing the metric and teams gaming the system. There are other metrics that can provide a more holistic view of the project's overall health. The Agile Dashboard collects such metrics and acts as an information radiator giving us real time project updates on value, performance, schedule, scope, cost, quality, and team spirit. Come learn what to measure and for how long. Learn how to read warning signs and what corrective actions to take. Learn to setup your own Agile dashboard to arm yourself with the right information and make careful and constant adjustments to ensure forward and safe progress towards your final deliverable.