Agile2016 Things

BTW, have you watched "Stranger Things" yet? Amaze-balls!

I’ve had two great opportunities to learn and reflect this summer. The first was the Agile2016 Conference, and the second came 3 weeks later when I took my family on a beach vacation. Those two weeks have allowed me to mentally prepare for what happened today: I went from zero direct reports to four who, along with my technical lead that reports to our Director of Engineering, comprise the team that I will be leading in developing cloud-hosted solutions for Walmart’s brick-and-mortar stores. It will be my first time leading a team in my current capacity, much less leading one where the majority of the team members are brand new to both each other and the company itself. Here are some things I’ve decided to try with my new team.

1) Personal Maps

I actually want to try a whole bunch of things that Jurgen introduced in his opening keynote, but this is the one I’m starting with. I’m working on mine now and, on Wednesday, my tech lead and I will present ours to the team. We’ll give them about a week, and then they’ll share theirs. I will keep mine up-to-date in a digital format that I can share with any other new team members that arrive in the future, as well as all of my friends here on the Internet.

2) Modern Agility

I’ve joined the Slack team, followed them on Twitter, joined the Facebook group, and plan on getting involved with their open source repo on GitHub. I’m not sure what exactly I’m going to do with all this, but I’ve got the sticker on my laptop that reminds me everyday to Make People Awesome; Deliver Value Continuously; Make Safety a Prerequisite; and Experiment & Learn Rapidly. I’ll be re-watching Joshua’s mid-conference keynote when I share it with the team and perusing his slides for further hints and advice on how I can implement Modern Agility on my team.

3) Focus on Impact

The conversation in the Agile community has been trending more and more to value, but I most like the term that David Hussman used: impact. Before our team builds anything, we’ll define the impact it will have once it’s been delivered. We won’t work on things that don’t have impact, and we won’t call it done until we’ve validated whether or not the impact was made. 

4) Shorten Improvement Cycles

Following the conference, I had lunch with Woody Zuill of #NoEstimates and #MobProgramming fame. He talked about the process by which Mob Programming came into existence. He was trying to help the team learn how to identify what’s working and what’s not by holding short, daily retrospectives. By narrowing the timeframe for inspecting and adapting, the team could more easily pinpoint daily activities that were beneficial or not. As a software engineer, I see the daily retrospective as the algorithm that produced the solution of Mob Programming, and I want to see what kind of results it produces when I provide my team as the input to that algorithm.

5) Highlight Learning, not Failure

Coming back full circle to Jurgen’s “Managing for Happiness” keynote, I want to use the Celebration Grid approach in our fortnightly retrospectives to highlight learning. I’ve grown accustomed to the “Fail Fast” language that permeates the Agile community, though I always use the Spotify language of “fail fast to learn fast to improve fast”. Well, if you fail fast but don’t learn from it then it’s not useful, so why not focus on the learning and not the failure?

Those are my five action items following a weeklong conference, a week of restful reflection, and challenge of leading a brand new team for the first time. If you attended #Agile2016, what were your takeaways? If you’ve ever been in a situation similar to mine, what advice do you have for me? I look forward to hearing from you!

Introspective: Conversation Framework

We're all just faking it and hoping everything works out.

What's in a Number?
For at least half a year now, there has been a growing movement in the Agile Community for #NoEstimates - the concept that estimating the size of your work, regardless of method, is detrimental. The idea is intriguing and thought-provoking, which automatically gives it some degree of merit among those who are constantly striving to push the boundaries of Agile. The thoughts on the subject that most resonate with me on this subject come from Dan Mezick of Open Agile Adoption fame and Valerie Santillo, a blogger I met last year in D.C. and have kept in touch with since. What both of these thought leaders have said is that the conversation that leads to the estimate consensus is the most valuable aspect of the estimation process, and that great care should be taken to maintain that learning process.

The question then becomes: can you have a learning conversation and reach some sort of consensus as a team without an estimate to trigger that the consensus has been reached? My intent here is not to answer the question, but to illustrate how powerful this concept - using a conversation geared towards achieving consensus as a framework for learning - can be in practice.

Meetings, or Games?
Dan Mezick describes this consensus-driving conversation framework in the context of gamification. He posits that all meetings are games, and uses Jane McGonigal's definition of good games to show that meetings are ineffective because they are broken! A good game contains: a clear goal; clear rules; a way to get feedback; and opt-in participation. In a later post, Dan details How Games Deliver Happiness & Learning by putting gamification in terms of senses: a sense of control; a sense of progress; a sense of membership and community; and a sense of higher purpose and meaning.

Estimation as a Game
I propose that Story Point Estimation, particularly the Planning Poker approach or similar, meets the criteria for a good game as stated above. First, there is a clear goal: to agree on the "bigness" of each User Story. This is where my concern with the #NoEstimates movement comes into play, though I'm definitely open to their alternatives. Second, there are clear rules; the team has a Definition of Done for each Sprint, and each User Story has Acceptance Criteria to help the team understand what the User Story is (and isn't). Third, there is a way to get feedback through both conversation and revealing of Story Points. Conversation, in theory, would be good enough. However, experience has taught us that assumptions not stated in the initial conversation are revealed when discrepancies emerge as Points are shared. By having disparity in estimates, we are providing feedback that our assumptions differ. Fourth, the participation is opt-in - or, at least, it should be. Estimation should be done at a time and for a duration that the team agrees to. Nobody on the team should feel like they are being forced to participate. If there are, the Scrum Master or Agile Coach needs to step in, mine for conflict, and find out why the team member is disengaged so that the team can fix it.

Now let's look at it in terms of senses. First, there's the sense of control. The process of Planning Poker should, again in theory, prevent the process of estimation from being dominated by a loud minority. Every participant should feel some level of control over the direction of the conversation. Second, the sense of progress. As votes are cast and the numbers converge, we feel like we are nearing our goal for each Story. On a deeper level, we're growing closer as a team and gaining a more in-depth understanding of the system being built, which provides us a feeling of accomplishment and satisfaction. Third, the sense of membership and community, which should have been fostered prior to the activity and is reinforced throughout the conversation. Finally, the sense of higher purpose and meaning. This sense is driven by the nature of the work being discussed and estimated; a team that isn't opting-in may not feel this sense.

Every Meeting as a Game
What I've just walked you through are the conclusions I've started to form about how ALL conversations should be structured. It's the context with which I constructed the training material for the senior management that my fellow Coach and I were tasked with training on Agile. We started with the goal: how will each person change their behavior as a result of the paradigm shift we take them through? The mechanism we chose was the 5-Spoke Wheel Retrospective that we would end the training with. Starting with the end in mind, we created a framework for having the participants discuss the Principles of Agile and the Themes of Product Development Flow that would result in them debating with each other and examining the work they do on a daily, weekly, monthly, quarterly, and annual basis. As facilitators, we spoke for about a quarter of the time, opting for audience participation and group teaching instead.

I was shocked and amazed with not only how smoothly the class ran with so little structure, but with the amount of positive feedback we got afterwards! I then thought back to my early days with my first Scrum teams, how they would talk about how little time they spend in meetings now that they've gone Agile. When questioned about their Daily Scrum, Story Time (Backlog Grooming), Sprint Review & Demo, Sprint Retrospective, and Sprint Planning meetings, they would respond, "Oh, we don't really think of those as meetings; they're more active group conversations."

Framework for Success
Personally, I like Story Point Estimation and will continue to use it as a tool to help people bridge the gap from traditional (Waterfall) project structure and more Agile approaches. If they decide to do away with estimation altogether and can do it in such a way that the valuable conversation is not lost, I say go for it. I will also begin to encourage everyone to take a gamification approach to meetings with the goal that people not only look forward to them, they are insulted at the insinuation that their conversations are called "meetings". After all, meetings are dull, pointless, no-fun snooze-fests!