Agile 2015 – Team Building Sessions
I used to attend Agile conferences pretty frequently, but at some point I got burned out on them and the last one I attended was a 2007 conference in Washington, DC. This year, when the Agile Alliance conference returned to the DC region, and I decided it was time to give them a try again.
It’s interesting to see how things changed since I last attended an Agile conference. Agile 2015 felt much more stage managed than in previous years, with its superhero party, the keynotes making at least glancing reference to it (the opening keynote, Awesome Superproblems, appears to have been retitled for the theme, since all the references in the presentation were to “wicked” problems instead of “super” problems), and making one go through the vendor to get to lunch. It also seemed like there were mostly “experts” making presentations, whereas previously I felt like there were more presentations by community members. I have mixed feelings about all of this, but on the whole I felt that my time was well spent. Although I didn’t really plan it, I seem to have had three themes in mind when I picked my sessions, team building, DevOps and craftsmanship. Today I’ll tell you about my experiences with the team building sessions.
Two of the keynotes supported this theme: Jessie Shternshus’ Individuals, Interactions and Improvisation and James Tamm’s Want Better Collaboration? Don’t be so Defensive. I’d heard of using the skills associated with improvisation to improve collaborative skills, but the Agile analogy seemed labored. Tamm’s presentation was much more interesting to me. I’m not sure he’s aware of the use of the pigs and chickens story in Scrum, but he started out with a story about chickens. Red zone and green zone chickens, to be precise. Apparently there are those chickens (we’re outside of the scrum metaphor here, incidentally) that become star egg layers by physically abusing other chickens to suppress their egg production. These were termed red zone chickens, while the friendly, cooperative chickens were termed green zone chickens. Tamm described a few unpleasant solutions (such as trimming the chickens’ beaks) that people had tried to deal with the problem, and ended up by describing an experiment whereby the the red zone chickens were segregated from the green zone chickens, with the result that the green zone chickens’ egg production went up 260% while only the mortality rate went up for the red zone chickens (http://blog.pgi.com/2015/05/what-can-chickens-teach-us-about-collaboration/). Tamm then went on to compare this to human endeavors, pointing out the signs that an organization might be in the red zone (low trust/high blame, threats and fear, and risk avoidance, for example) or in the green zone (high trust/low blame, mutual support and a sense of contribution, for example), while explaining that no organization is going to be wholly in either zone. He wound up with showing us ways to identify when we, as individuals, are moving into the red zone and how to try to avoid it. This was easily the most thought provoking of the three keynotes, and I picked up a copy of Tamm’s book, Radical Collaboration, to further explore these ideas. The full presentation and slides are available at the Agile Alliance website (www.agilealliance.org).
In the normal sessions, I also attended Lyssa Adkins Coaching v. Mentoring, Jake Calabrese’s Benefiting from Conflict – Building Antifragile Relationships and Teams, and two presentations by Judith Mills: Can You Hear Me Now? Start Listening Instead and Emotional Intelligence in Leadership. Alas, It was only in hindsight that I realized that I’d read Adkins’ book. In this presentation, she engaged in actual coaching and mentoring sessions with two people she’d brought along specifically for the purpose. Unfortunately the sound in the room was poor and I feel like I lost a fair amount of the nuance of the sessions; the one thing I came away with was that mentoring seems like coaching while also being able to provide more detailed information to them.
Jake Calabrese turned out to be a dynamic and engaging speaker and I enjoyed his presentation and felt like it was useful, but that was before I went to Tamm’s keynote on collaboration. I did enjoy one of the exercises that Calabrese did, though. After describing the four major “team toxins”: Stonewalling, Blaming, Defensiveness and Contempt, he had us take off our name badges, write down which toxin we were most prone to on a separate name badge, and go and introduce ourselves to other people in the room using that toxin as our name. Obviously this is not something you want to do in a room full of people that work together all the time, but it was useful to talk to other people about how they used these “toxins” to react to conflict. In the end, though, I felt that Calabrese’s toxins boil down to the signs of defensiveness that Tamm described and that Tamm’s proposals for identifying signs of defensiveness in ourselves and trying to correct them are more likely to be useful than Calabrese’s idea of a “Team Alliance.”
The two presentations by Judith Mills that I attended were a mixed bag. I thought the presentation on listening was excellent, although there’s a certain irony in watching many of the other attendees checking their e-mail, being on Facebook, shopping, etc., while sitting in a presentation about listening (to be fair, there was probably less of that here than in other presentations). Mills started by describing the costs of not listening well and then went into an exercise designed to show how hard listening really is: one person would make three statements and their partner would then repeat the sentences with embellishments (unfortunately, the number of people trying this at once made it difficult to hear, never mind listen. The point was made, though). We then discussed active listening and the habits and filters we can have that might prevent us from listening well and how communication involved more than just the words we use. This was a worthwhile session and my only disappointment was that we didn’t get to the different types of question that one might use to promote communication and how they can be used.
Mills’ presentation on Emotional Intelligence in Leadership, on the other hand, was not what I anticipated. I went in expecting a discussion on EI, but the presentation was more about leadership styles and came across as another description “new” leadership. It would probably be useful for the people that haven’t experienced or heard about anything other than Taylorist scientific management, but I didn’t find anything particularly new or useful to my role in this presentation.
On February 25th and 26th, I had the pleasure of attending the “Agile in Government” conference put together by AFEI (The Association For Enterprise Information). The theme of this year’s conference was Mutual Adaption – Adapting Agile to acquisition and acquisition to Agile.
While attending the conference, I had the privilege of listening to some great speakers on various topics, including contracting Agile in the government, DevOps use in the government, how cloud computing is the next ‘big’ thing for government agencies, and how EVM plays a role in government projects.
Roger Baker kicked off the event with the keynote talk on day 1 discussing how to ensure the success of Agile projects. He had 2 very powerful points: base the solution on solving the mission and not the technology and what he called ‘Success Makers’ for Agile projects. Mr. Baker pointed out that he is very adamant about keeping program lengths 6 months or less to root the program in deadlines, which helps to keep things moving. He also discussed that the acceptable rate of success should be more like 80%, instead of the current 16%. Mr. Baker’s success factors are to ensure prioritization, impose deadlines, force decision making, and involving users in everything; it “takes a village to move things forward” he notes. My favorite quotable sentence from Mr. Baker was “Agile is not the answer to everything, but waterfall is the answer to nothing.”
There were a number of speakers that touched on how to use contracts in the government for acquisitions; after all, that was the theme of this year’s conference. Each of the speakers discussed how there are numerous types of contracts that lend themselves to Agile very well. One that is becoming more and more popular is that of indefinite delivery, indefinite quantity (IDIQ) which allows for changes through task orders. These speakers concentrated heavily on the FAR[1] which has been shown support Agile acquisitions.
Another topic that was a headliner was that of EVMS, or earned value management system. EVM is a management tool and not something that is a day-to-day monitoring tool. EVM helps to track time and budget at a program level. The one thing that makes the EVM stand out is that it is really about value; as a couple speakers pointed out, you really have as much time as you need but it is about the amount of value that you need to deliver in a set timeframe. The easiest way to ensure that the value is kept in check, relevant to the time and budget, is to prioritize. Prioritization is a point that was continually hammered by each speaker, including those that spoke of EVM.
David Linthicum, keynote speaker on day 2, spoke about how cloud computing is the future for the government. He pointed out how it not only helps to speed things up but also how it is something that really cannot be ignored if government agencies wish to have systems to be more reliable and scalable. As with a number of other speakers, Mr. Linthicum pointed out that just switching architecture is not the answer to becoming faster, more reliable, and more scalable; there also need to be things such as continuous integration, automated testing, and the ability to spin up environments at the drop of a hat. All of these concepts lend themselves to points made that it is paramount to adhering to developing on cadence, releasing on demand. Mr. Linthicum laid out a number of variables that need to be accounted for when moving to cloud computing and noted numerous times that a change of that magnitude takes time. He hypothesized that if government agencies began planning to move to cloud computing now, and moved forward, they would be there by 2019-2020. Another point that Mr. Linthicum drove home is that, contrary to what some think, it is not possible to ‘balance out’ the cost with the savings; there will be a cost to moving, but then savings in things like operations and reliability will be seen long term—not immediately.
Another speaker that was of interest was Mr. Victor Page. He was from the DSDM Consortium and spoke about how DSDM is an Agile method that is becoming more widely used than it has in the past. Mr. Page talked about how many believe that, by its name Dynamic Systems Development Method, that it is a method that tells you what to do and how to do it; however, he followed this statement by saying that it is more a framework than a method. DSDM, as a framework, is more about showing what to do but leaving leeway in how to implement the framework. Many, according to Mr. Page, are starting to ‘rename’ DSDM to “Driving Strategy; Delivering More”.
I was honored to speak to the group on day 1 about how teams are more than resources and they should be treated as such in a talk titled “Teams Are People Too”. In the 30-minute slot, I outlined how most teams are treated in traditional projects and how that treatment should be shifted when looking at teams in Agile. I tried to point out how teams should be treated inside an agency, as a vendor-based team, and as a team that is split between an agency and a vendor.
In probably the most enjoyable session of the conference, I had an opportunity to participate in playing a round of the Agile Contracting Strategy Board Game developed by FWD Think. This game is laid out similar to a cross between Monopoly, Trivial Pursuit, and Trouble. Each of 4 teams, of 3 people each, roll a monster set of dice and move their ‘car’ around the board. With each square the ‘car’ lands on, there are questions or challenges that the team must complete. When a right answer is given or a challenge is completed, the team is awarded money. Whichever team has the most money at the end of the game (in our case, the timeframe allowed to play), wins. I found this game to be very helpful in understanding some of the nuances of Agile and acquisitions. As an aside, my team of 3 won at our table!
As you can see from this short synopsis, there was a lot to take in and a lot to be learned in 2 days. In all, there were approximately 120 people in attendance. All-in-all, it was a very full 2 days!