Is being an "outstanding Servant Leader" a contradiction in terms? How does someone who facilitates the success of others see progress along a desirable career trajectory? How do you know whether you're being the best Servant Leader you can be? Where can you learn more?

The Pub Lunchers chose this topic as an evolution of the discussion on managers and power.

The Scrum Guide identifies Servant Leadership as the model that Scrum Masters should use, and this approach to leadership is considered desirable among Agilists whether or not they are Scrum Masters. But, what is servant leadership?

Come on down to Ringlers on Burnside on 7/10 (NOTE CHANGE TO ADJUST FOR JULY 4th) and talk it through with people who have been there, done the homework, have the stripes to prove it or want to be there do that and get the stripes.

We'll be in the back starting promptly at noon to wrestle with this perennially attractive topic.

RSVP's to [email protected] are very welcome but not required.

This June Cotten Blackwell's Agile team started a 3-month pilot adoption of pair programming and TDD – almost exactly as practiced during Coderetreats (http://coderetreat.org/facilitating/structure-of-a-coderetreat), which they used to kick off their pilot and can’t recommend strongly enough.

So exactly how did they get management and team approval (and active support) for TDD/pair programming?

Well, they are definitely blessed with Product Managers (and Directors) who are very big-picture, and highly open to persuasive business cases grounded in data and metrics. But, they think that how they made the business and technical case for pair programming and TDD is worth sharing – and that much of it might be highly applicable to your team.

Bio: Cotten Blackwell is an engineering manager, Agile champion and Swift developer with over 15 years experience leading, coaching and mentoring software development teams. For the last four years he’s been doing that at Huron Consulting Group, where he’s known for his focus on improving team health and employee development and retention. Cotten has driven continuous improvements in Huron’s mastery of Agile and Lean Startup fundamentals, and has leveraged multiple software teams to more consistently, more deeply engage in risk identification, analysis and mitigation.

RSVP's to [email protected] very welcome but not required.

Last month the pub lunchers pointed back to a perennially sticky topic. We know retrospectives are a key aspect of continuous improvement and progressive agility. Most of us do retrospectives regularly. Many of use use the standard references like Derby and Larsen's /Agile Retrospectives: Making Good Teams Great/. And, many, if not all of us have had the experience of nothing the team agreed to change during the retrospective actually being changed. My personal favorite was a recent retro where the team rescinded all agreements made during the retro within 90 minutes of making them. In fact, within about 5 minutes of facing the Product Owner in the planning meeting.

So, is it a lack of resolve? Is it poor facilitation on our part? Is it taking on too much? Is it not taking on doable things? What the heck?

But, sometimes things go well. Sometimes teams dig in and use their retrospectives to improve something every sprint. Sometimes team members eagerly take on facilitating their own retrospectives and teams look forward to the next retrospective even as they are planning the current sprint. Sometimes they summarize data showing the existence of organizational impediments, for a task force, and take their data to executive leadership with a viable plan for change--which is actually accepted.

What can we spot about retro's that do NOT result in change so we can call out those smells when we scent them, so we stop a sterile retro in its tracks and turn things around? Or, ensure that we develop a pattern of potency in our retrospectives?

Join us Friday, 9/4, from 12p to 1p for pub grub, beer, conversation, commiseration and a few smashingly good ideas to help you or others turn your retrospective experience around once and for all.

We'll be in the back room. Show up a few minutes early to chat with the friends and colleagues you haven't seen all summer and hang around as long as you like after to make new friends.

RSVP's to [email protected] are welcome but not required. It helps know how and whether to move the furniture, which saves us having to do it after the discussion has begun.

Join us for a Lean Coffee discussion about Agile beyond the frameworks. We'll start with some definition of topic boundaries then jump right into Lean Coffee discussion.

Following up on the topics that emerged among attendees at the “State of Agile” discussion at Puppet Labs gathering on 6/17, we’ll dig into what we think it means to be Agile disregarding the constraints and supports of the three most common frameworks currently in use. In some quarters, the term “agile” is being deprecated in favor of “nimble;” in others, the term “business agility” is increasingly favored. The case was made on 6/17 that Agile as we know it doesn’t speak to the needs of the enterprise outside of IT or engineering, and, especially, senior business leaders do not show up as what we often think of as agilists.

So, what’s under Scrum, XP, and Kanban? What about the manifesto and principles can we grasp as tools to operationalize agility wherever we are—without spouting Scrumese or Agile cuteness. How do we both grow ourselves as agilists and as a community and support our colleagues toward a more mature grasp of Agile and Lean. Or, is Agile passe and do only the consultants and behemoth enterprises not know that, yet?

Pizza and pop provided by PNSQC and beer provided by Puppet Labs, as usual.