McMenamins Ringlers Pub

Description: To facilitate the highest levels of team performance, your practices need to transcend the ordinary. This includes performance review practices. When you use team-based performance reviews, rather than individual-based, you boost collaboration and coherence in a team, which leads to higher performance. Join us for a discussion on how one Fortune 500 Information Technology group used these practices to help solve complicated technical challenges.

The Speaker: Jackie Barretta is a successful business change agent. She’s built groundbreaking organizational cultures as a Fortune 500 executive, she’s won a reputation as a leading edge thought leader with her writing and speaking, and, as the Founding Partner of Nura Group, she’s pioneered new ways to conduct business through consulting and training. She is the author of an upcoming book, Primal Teams, which describes the emotional energy of elite teams and helps readers create it in their own teams. She is the former senior vice president and chief information officer for Con way Inc.

Well-functioning agile teams often reach a point where continued improvement requires change in the organization beyond their team. As a team member or change agent, how can you best engage with key figures in the larger organization?

Adam Light will lead a dialog that examines agile from the perspective of various roles outside the agile team including the CIO (or other IT leader), the leader of Product Management, and the leader of the PMO. Our discussion will consider each role in turn, discussing what people in that role see, hear, and think about, how best to engage the role, and what specific protocols can be effective in each case. Read his related blog post at http://www.sotechadvisors.com/resources/chasing_the_constraint/

Adam Light is Management Consultant and Principal at SoTech Advisors where he helps managers and teams apply lean and agile methods to unlock greater value from software development. Adam works with enterprise clients to adopt and scale agile methods, design and operate agile work systems, plan and deliver critical projects, and build the knowledge foundation necessary to sustain continuous improvement.

This month we'll be revisiting the ever popular topic of tools to manage our work. What are they? How well do they work? How expensive are they? Are they worth it? Do we need anything more than a good wall and a never ending supply of post it notes and pens?

This topics packed out our previous venue at Paddy's last year. Come and bring your friends. We have more space now, and even more beer and pub grub.

See you there! Oh, and hey, if you're coming it helps if you ping me at jean@azuregate.net so I can warn the pub to bring on wait staff reinforcements if we're going to be a horde. This gets you your food faster and adds minutes, if not years, to my lifespan.

Over the last decade, agile practices continued to gain a foothold in many companies. Many of the practices were first tried on a smaller scale, and tailored to green-field projects. But, as agile practices are adopted at multi-site, larger companies, with complex back office projects, they bring with them additional and unique challenges. Take for example, Cambia Health Solutions, a not-for-profit, health Solutions Company. Cambia has a relatively large IT group, which develops its own software solutions and integrates software from other vendors. It has a distributed workforce that spans four states with many work-at-home employees. Cambia’s mainline business is regulated by various state entities and national agencies. Many of Cambia’s projects are large, mandated compliance projects that have a fixed time box and a set scope. Missing either the deadline or scope could potentially mean losing a significant portion of its business or facing monetary penalties. Can agile practices work and scale to solve business problems facing the company? What if you also operate within an IT organization that is structured with functional silos? And what if you have reluctant business partners who define software requirements and perform final verification of software solutions? To tackle these challenges, Cambia organized an Enterprise Transition Community to lead the transition from a patchwork of agile practices to a large-scale agile implementation. Find out how we carried out this transition, what we have learned along the way, and how that might help organizations of all sizes take on a similar challenge.

Aashish co-presented a related paper with other Cambia staff at last year's PNSQC. You can find the paper here by searching on Aashish's name on the page: http://www.pnsqc.org/past-conferences/2012-conference/paper-and-presentations/#papers

Aashish Vaidya is a Technology Manager leading Specialized Teams at Cambia Health Solutions. He is a founding member of Cambia’s Enterprise Transition Community, and other Best Practices Exchanges. He also serves as an internal coach on Agile and QA practices. Aashish has over 20+ years working in technology development and leadership positions for companies such as Compaq, Intel, and Kronos Incorporation. In 2012, Aashish was a Co-Author and presenter at PNSQC. In 2011, Aashish was a panelist on Technology Association of Oregon’s panel discussion: QA’s Role in Agile. He is a graduate of Texas A&M University, with a Bachelor of Science degree in Aerospace Engineering.

Estimating stories, sprint commitments, and releases--estimating in general--remains a real bugaboo for all teams. Agile teams have different approaches to estimating. What's worked best for your team?

Has your team come to consider estimating "waste?" How do you make that work in your environment? What's your rationale and how does it test out in practice?

Come share your techniques, tactics, strategies, and war stories with colleagues over lunch. Same bat time, same bat station. See you there.

And, hey, we're about to bust our seams again. If you ping jean@azuregate.net or the AgilePDX list that you're coming, it can help us help the restaurant to provide fast service and the best possible layout for the tables. RSVP's appreciated NOT required.

This month’s topic is how to build trust with executives when you’re working with immature teams. This is likely to raise questions such as: • What is an immature Team? • What do we mean by “immaturity?” • How do you help a Team move toward greater maturity? • When we say “executives” do we mean anyone beyond the first level of supervision? Anyone in management? Anyone outside the Team? • Is Team immaturity a valid excuse for missing commitments, and does the responsibility lie with the Team?

As well as: • Just how do you “build trust,” anyway? • Is building trust even possible if there is no trust to begin with? • How much of my job is about trust building?

Come stumble in after your holiday revels and have lunch and a beer with like-minded colleagues. Someone please bring an “executive” along so we can hear their point of view, as well.

This month we’re all about managing the backlog:

Backlog Grooming: What does it mean? How do teams do it? Outside the sprint? What other things can be considered to be done "outside" the scrum team to facilitate a better backlog of stories that are ready for the team? Planning days take too long if the stories aren't ready for the team. It takes effort--how are teams ensuring that it gets done? Should we/ do we consider backlog grooming another of the critical 'scrum ceremonies'?

Estimating the backlog: How do teams estimate the backlog? Who does it? How do teams accommodate the business pressure to have information about sizing from which to make long term business plans (roadmap planning)? Is estimation a key part of the grooming process?

PO’s, BA’s, SM’s, and Team members, link hands and make the walk over to Ringlers on Burnside at noon this Friday. Bring your questions, your answers, and your backlog grooming passions.

Yes, there is still beer.

This month, we’re talking about QA's role on the Agile Team.

Fresh from a successful ATONW (Agile Testing Open Northwest) we will delve deeper and discuss what QA's role is on agile teams.

Same bat time; same bat place: noon on Friday at Ringler’s (not Ringler’s Annex, keep heading east) on Burnside. Good food. Good beer. Good, straight talk.

It’s that time again, and this month we return to the topic we tabled last month in favor of discussing the recent big agile conference. This month, we’re talking about the business analyst role on the Agile Team?

“What?! A business analyst on an Agile Team?” you may say. Yes, many companies explicitly call out this role on the Team to support the Product Owner or draw from a pool of BA’s to fulfill the Product Owner function. The questions before us are many:

Is this a good idea? What are the costs and benefits? When does it make sense? What about role boundaries? Doesn’t this institute them? How come the BA would be on the Team? (some actually report into a product management function along with the PO’s.) Why doesn’t my Team do this? Isn’t this anti-Agile?

Well you might ask. Come down and ask it of a bunch of colleagues primed with questions and answers of their own.

Same bat time; same bat place: noon on Friday at Ringler’s (not Ringler’s Annex, keep heading east) on Burnside. Good food. Good beer. Good, straight talk.

It’s that time again! And, based on discussion on the list earlier this month, we are going with the topic of the recent Agile 2012 conference. If you attended the conference, please come and tell us what you saw and what we should know.

Looking forward to seeing you all at Ringlers!

This month’s roundtable discussion topic is tools, tips, and techniques for engaging effectively—and even happily--with project managers in an Agile environment.

The project management role has been with us for some time and, in the Agile community, has a certain reputation. While Agile has emerged strongly, the project management role remains, and in many organizations, is metamorphosing along with Agile while in others remains much as it was 5 to 10 years ago.

Predictive and adaptive approaches to getting work done do not always coexist happily. How does an Agilist work well with a project manager who may constrained to function from a more traditional management perspective? It can and does happen; there are models.

Come this Friday to Ringler’s on Burnside and bring your stories, your problems, and your PM friends. Beer is available.

Agile methods are empirical methods, designed to adapt and improve based on data. So why do many experienced team members recoil at the very mention of metrics? What makes a good metric? How can practitioners avoid using good data to do bad things? July's pub lunch meeting will frame a discussion around selecting and implementing useful metrics for agile work systems.

We’re meeting again this Friday at Ringlers on Burnside. This month, in preparation for a more in-depth discussion of metrics next month, we’ll discuss perhaps the most common metric (some would debate whether it’s a metric at all): velocity. To get an interesting perspective on the topic, you might want to read "Velocity is Killing Agility!" a blog post by Jim Highsmith (http://jimhighsmith.com/2011/11/02/velocity-is-killing-agility/).

Is he right or wrong? Do agile teams need metrics at all? What kinds of issues with or needs for metrics do you find where you work?

Have you noticed or felt the need for a difference in the way your lead, follow, or are led since agile methods came into your organization? Do you think you need to see a change in leading or following in order for your organization or team to become more truly agile?

Come out to rant, rave, engage and connect with fellow Interaction Design practitioners and people interested in Interaction Design. We meet up bi-monthly to network with each other and become inspired together.