This is not a RAGBRAI Post! - Intertech 25th Anniversary

Last week (Wednesday, August 3) I attended Intertech's 25th Anniversary   Peculiarly, two of my coworkers were there as were their wives.  The Twin Cities tech industry is mighty small.  I asked Sanjay if one of the two women at the end of the row in the rather short skirts was his wife and he laughed because his wife told him about the two women I was asking about.  In my defense, they looked like interns (young), so I was wondering exactly how young Sanjay's wife was.

Presentations included Jim Karg on IoT.  Lonnie Weaver-Johnson on Organization Benefits from Agile and Scrum Adoption.  And Tom Salonek, who runs Intertech, on Delivering High Performance Using Employee Engagement.  There was a little bit of good information in each presentation, although they were at a higher level then I tend to like.


Jim referred to the Gartner 2015 Hype Cycle, which I always forget exists.  It worries me that hybrid cloud computing and machine learning are over the hump given thsoe are spaces I'm working in lately.  Those others things - I'm not even close to worrying about them.

It was a good presentation on battery tracking in golf carts.  I wasn't quite sure how you get enough golf carts under IoT to make it worthwhile, but perhaps golf cart purchasing/selling or storage is more centralized than I understand.

Weaver-Johnson was pretty basic Agile/Scrum.  We've been Agile-ish for going on 3+ years with Hussman's help, so it's old hat, even if we're constantly refining our process.  Amusingly, I had a group that went back to our old testing-signs-off-on-stories process despite quality having had a more free reign on one of my teams.  All stories, even 0 points/days get a quality review/signoff and estimate.  Maybe that's more agile.  It's hard to say.  But I know the team likes it and is more efficient using the process and they talk more, so those better communication chains are what really matter.

Weaver-Johnson referred to the Cuckoo Effect.  It's a variation on our culture training where we're taught to look for how to make something work, not what's wrong with the idea.  I don't think it's a good metaphor - because when cuckoos invade your nest, there's a positive side, baby cuckoo birds.
https://chrismurman.com/2014/11/11/blog-post-dont-let-the-cuckoo-effect-ruin-your-organization/

I liked Salonek's presentation best.  He has a new book, The 100: Building Blocks for Business Leadership.

I haven't read it yet because I'm knee deep in: Analytics, a Foundation Novel I started on RAGBRAI, a Saunders book I took to RAGBRAI but haven't finished, the end of Disrupted, and Elastic, Angular2, Python, D3, AWS, Eureka, and Spinnaker documentation.  And a little bit of ANTLR and other nonsense.  It's queued up.  I'll get there very soon.

He talked quite a bit about culture fit for new hires.  Intertech does a lot of screening and looks at Key Result Areas (very specific goals) and TTI Success Insights (DISC based - you know my opinion on  those sorts of things - they're talking tools, not science), Tom noted that as far as pay was concerned, aim for slightly above market and make sure pay isn't an issue.  That's exactly what Dan Pink says in Drive.  It's all the more compelling given I just had another employee leave to do contracting.

Enjoyable.  I'm glad I stayed for the presentations and free beer and I won 4-5 days of training at Intertech while I was there which I'm jazzed about.  I can't decide if I'm more interested in Angular 2 or .NET Core.  I think .NET core, although the description still says there's a focus on MVC which bores me to tears.  Well...not quite tears.  But I don't want to learn more MVC.

Lilac-Breasted Roller

My boss gave me an unasked for book, User Story Mapping from O'Reilly.  I wasn't sure what to think about it, although only 45 pages in I can honestly say even as we're reading the book we're not exactly following the practices.  There's a very compressed version of Ben Horowitz's Good Product Manager, Bad Product Manager on page xviii and xix.  The bits about reference customers versus competitors, (not) prioritizing, and prototypes every day are all obvious failures for us (at least in my projects).  

A bit evangelistic, or more accurately perhaps a bit motivational, but Agile books usually are.  I'll chat about it a bit more as I get further in, although the forwards go up to xliv, so I'm already 44 pages (a 1/5) in before the book even gets started.

But my first question for my manager was why did he give me a book with a Lilac-breasted Roller on the cover, known for it's life-long monogamy?  Was it a not so subtle hint that I (and my co-manager, who also received a copy) wasn't leaving the company until I retire or die?  That doesn't upset me, but it's disturbing to have your manager say it with a book.  He told me he was going to respond, and then just didn't know what to say to that and gave up, which he was pretty sure was what I was up to all along.  Look at that, he hasn't even cracked open his copy yet and we're already embracing the core tenant of mutual understanding.  Win!

How you can tell a team is on an agile project where I work...

Email, Meetings (and Managers)

A cross post from my corporate blogging...

A local blogger (Conner McCall) posted these email rules he wished co-workers would adhere to:

1. No email shall contain less than one actionable item
2. No email shall contain more than three actional items
3. Any email that is information only should be posted to a wiki/website/blog and not be sent by email
4. Anyone responding to an email that follows rules 1-3 which asks a question whose answer can be found within the email they are responding to, shall be fined $5
5. Senders of emails breaking rules one or two must buy any recipients of the email lunch.

Tough love!  I can only imagine the fine he'd leverage on someone who hit "respond to all."
Along the same lines, Midwest TED has a presentation by Jason Fried of 37Signals called "Why Work Doesn't Happen at Work" (15:21 minutes) which includes the quote, "Meetings and managers are two major problems in business today."  Harsh, but managers should be actively working to eliminate unnecessary meetings and all the distractions that prevent team members from doing work (and I'd add, as a member of the the corporate initiative team currently finalizing the career planning framework, that the discussion about which meetings need eliminating and what can be done to remove distractions is an action item at every level).  I think we see that voiced more clearly in our Agile projects where discussions about roles that don't include whether managers and architects are vestigial organs - I'm not saying they are, but it's a thread in some Agile commentary if you're an avid reader - frequently focus on the necessity of the manager to rapidly eliminate roadblocks to team velocity, particularly at the touchpoints where a non-Agile team or process (procurement, budgeting, discussions with other management, et al) can completely derail forward momentum.  Meetings can definitely be roadblocks to momentum.

If you have meetings that are unnecessary, or email strains (those pesky chains that generate much email for little worth and could probably be handled with a status elsewhere) that should be pruned or purged, consider recommending how to remedy the situation and freeing up some productive time for everyone on your team.

Elizabeth Bacon's Sundial Model

Elizabeth Bacon's Sundial Model:
My department recently (trending to not-so-recently) had a realignment. It would be more accurate to call it a reorganization. Reporting lines shifted en masse, so that's obviously what it was. The goal was to facilitate Agile development and how we interact with other teams in a vertical manner. While we had distinct objectives in mind, optimizing to Agile and vertical development are rather esoteric statements, and it's difficult to see how the realignment achieves this end without concrete examples. Here's one example, and how it ties to some theory. For the vertical development objective, our goal in reorganizing was to break down some of the specialization - what you see in Elizabeth Bacon's sundial model above as generally the bigger the company, the more those skills become defined as distinct roles (in our case it was code domains, not UX domains) - and code throughout the stack, bringing individuals with a breadth of experience to bear on technical questions so that design and architecture are as much a part of our daily work as development.

The issue with specialization, at least one of the issues, is that there is a premium, salary- and benefit-wise, paid by large companies for developers in order to hire people who willingly deal with an overabundance of process, don't mind the extensive roster of roles (role specialization, or at least the lack of generalization) that interferes with personal ownership, and flourish despite not working directly with customers. The premium isn't for the best developers (although that is a goal for any development team), but for developers who fit a set of criteria. Those criteria can be characterized as broken from some perspectives, particularly the Agile perspective, despite that they fit company needs. The flip side of this "corporate tax" is the idea of "golden handcuffs". It's a two-way street. While big companies shop for best of breed developers who still fit within their box. Best of breed developers who fit within the large corporate box shop for those companies to ensure stability, a premium on their salary, and a low-impact, mobility pressure valve that doesn't always come with a small shop.

Relating this to Alan Cooper's presentation, we can conjecture an interesting correlation between big company hiring practices, specialization, and offshoring. If the hiring goal is fulfill the above constraints, then the appeal of offshoring is, in part, that the company feels this developer persona can be offshored. What is headed abroad in many cases is not the job of a self-empowered, iterative, design-capable, agile knowledge worker - a craftsperson - but an extremely specialized, heavily process-focused, non-customer-informed, placeholder.

That seems harsh. As though I'm disparaging both onshore and offshore resources for large companies. But far from it. Large companies have specialization. They have process. They lack customer contact at certain levels. And to thrive in that environment is a skill, or set of skills, as is the reverse. And if we look at ShuHaRi, we realize that some of this work takes place in the lowest level of knowledge. But it serves as building blocks for moving to higher levels of knowledge and understanding. Onshore or offshore, the move toward craftsmanship (being a craftsperson) is inevitable in an educated base of developers. Consider the focus applied to process by new offshore groups. Then consider how, over time, the process evolves into something more. The natural progression, so it would seem, is to rise above the traditional big company premium restrictions. Moving the premium offshore simply delays an evolutionary change in how software is constructed or pushes the premium from offshore group to offshore group until the very last developer is empowered (a good place to argue Friedman's World is Flat).

The good news is there is space for the process-focused developer who is moving toward being a craftsperson, and for the developer who has already moved past that stage and is a craftsperson. It requires the former to allow the latter to stretch. But you have to acknowledge that you're the latter and put yourself in a structure that enables non-process focused, customer-oriented, iterative, generalized (ownership-focused) development. That might be Agile (in the strictest sense). Or it might be an organization rebuilt around the idea that these are positive goals to achieve and developers should be proactively enabled to drive at those ideals. Our department has started a journey toward Agile, and has come down strongly on restructuring to empower developers. We know we have a team of craftspeople and we're striving to allow them to actualize that reality despite, or perhaps by building upon the strengths of, the corporate tax.

Real World Agile User Experience Design - Jeff Patton (Part III)

I covered the first six patterns Jeff Patton says user experience designers picked up from Agile in Part II. Here we'll cover the last seven.

7. Schedule continuous user research in a separate track from development. You can picture this as an intersection of a few of the previous patterns: cultivating your user pool, chunking the design, and use parallel track development. The goal is to smooth out the design process so that it is stable and flowing into and out of development without being dependent on stages or waiting for a piece of functionality to complete. If developers decide, or their schedule dictates, when user research occurs, the natural breakpoints create a stop/start feel to design that interrupts the agile velocity (pacing) all groups should experience.

8. Leverage time with users for multiple activities - avoid thrashing your users by scheduling distinct meetings for distinct activities regardless of the time involved. Again, aim for creating a sense of continuous pace by having multiple goals for users to consider, including looking forward and backward as well as working within the current iteration.

9. Use RITE to iterate the UI (design) before development. Rapid Iterative Testing and Evaluation evaluates testing at the end of each day or after each participant, making changes to the interface almost immediately (if you need more information about RITE, this is a good slide show).

10. Design and prototype at the lowest fidelity possible. we've talked about the ease of use and portability of whiteboards before. Low fidelity means doing your design on a whiteboard as well, or some other easily portable, easily modifiable medium. Don't get carried away with using the latest tool, only to be trapped spending excessive time converting. From the tool to Visio. From Visio to Powerpoint. From Powerpoint to the wiki. Ad naseum. We've all done it. Instead, start simple and take a picture. Avoid formatting as an occupational time sink.

11. Treat the prototype as the specification. If you think you have a hard time with this, I suggest spending some time in my group at work (migration) and you'll realize there's a group more antithetical to this viewpoint than your own. But even within my group, we see places where this approach makes a certain amount of sense. Some of our projects are particularly heavy on design and proof of concept, and the POC drives subsequent development. It's not that simple, and invariably we find ourselves tracking backward to recreate the necessary documents and fit within the approved process flow - part of the tax of a large company - but the POC or prototype is still the heart of the project, and when we revisit requirements and design, it's that prototype we reexamine to determine the outflow.

12. Designer-developers iterate visual design outside the development timebox. Don't feel constrained to always finish up all cycles in all spaces simultaneously. After all, slavish devotion to aligning deadlines, despite the actual temp of productivity, is more characteristic of waterfall than Agile. Visual design is necessarily going to overlap development iterations as it captures the results of refactoring and attempts to anticipate new UI direction based on refinement of personas, interviews with customers, and reaction to new functionality (and customer feedback on that functionality).

13. Become a design facilitator. Patton's baker's dozen is rounded out with a bit of advice that applies to the previous twelve points. Learn some of the core skills of Agile: socialize, share, collaborate. Learn to communicate and increase communication touchpoints so that interactions are driving the betterment of your project. Patton offered some sayings/quotes to remember to keep that collaborative focus:

• "Design is not an artifact. It is a process."
• "Design is something that is done. It is not a role."
• and my favorite... "Design by community is not design by committee." (Leisa Reichert)

Rating as a Team

(My reviewer says I shouldn't xb this one. It seems harmless, but I think I'm going to listen to the advice and give it an xb so I can find it in conjunction with similar posts, but not actually cross-blog it. I pushed enough buttons this week that I should take a breather. So here's a story about annual reviews. Not necessarily about my company, but about something I've seen at big companies, having worked at a few).

If you're reading this for some Agile insight, I have to ask you to bear with me until nearer the end. It's a very roundabout dig into how I feel about a topic that's at odds with Agile based on some recent experiences. But it's a good dig, the kind that, if you work for a big company, they're not always comfortable with you addressing. So it needs to be addressed, because you have to work all the harder at a large company with significant inertia to change behaviors.

Every year or, more accurately, twice a year, we do reviews at my corporation. I've had direct reports on and off for several years now, which necessitates doing reviews, and I've always been asked to do plenty of non-direct report reviews because I have a reputation for putting some thought into them. Fortunately, I'm running a little lower than my heyday of twenty plus, but with a bevy of direct reports (up 700%), I'm sure to have more this year. What I try to get into a review is not just my impressions from the year, but a reevaluation of my own impressions, trying to ensure a.) I haven't told myself a story about someone that's coloring my perception. I try to give everyone a clean slate in the sense that I throw away the narrative I tell myself about them and let them recast their narrative for the next year. Part of each review is identifying the story that was built up over the year and what was concrete and what was interpolation. In some respects, I try to build a counter story for the next year, so they have to work at dispelling a positive impression I've put together, actively working to dissuade me of their innate need to succeed. And b.) that I haven't internalized someone else's story for the same reason. I find that to be even more important, as stories about employees are rife in a company with 5000+ individuals at a site, and they tend to stick for longer than you'd suspect. One of the most important things in working toward being a manager was to identify the stories being bandied about in regards to me and actively work to offset the negative ones. If you haven't picked up enough of my personality in previous blog posts, the bigs ones were 1.) not promoting myself enough because I wasn't interested in getting ahead (make noise, even if you're not interested in a job or an opportunity, you have to explain your perception of why it's not the right move), 2.) not being an advocate of "up or out" (I'm still not, but it's mandatory I have a story to explain my own version of up or out and how it fits into the corporate strategy), 3.) not looking like I feel entitled to promotion (this fits in with, I know better how to manage my career than those who are trying to manage it for me...it's an incredibly fine line, and there was a lot of misperception initially, much of it my own doing - see #1).

That would seem to be a post in its own right. But it's just the opening.

This year, I heard one of these stories being shopped around. A recursive review story if you like, because the story is "X is an easy rater." I'm instantly suspicious whenever I hear the same story coming from multiple managers, unless I've been the one to put the story out there in the first place. If someone is regurgitating my story, I see it as an opportunity to refine my message. If it's a story I'm unfamiliar with, I suspect someone else of pushing an agenda. To the best of my knowledge, there's no fact or statistics behind this particular story. It's just being adopted as gospel because it's convenient. I've argued the flip side in manager meetings with a variety of "tools", as my last manager referred to that set of skills. A bit of displacement: our rating system seems to be tougher overall this year. Manager A used to rate most of his team particularly high. If he had still been here, we'd have been 10% higher overall. We're lower than we should have expected. This leads to discussion and some humor, with full knowledge that it was statistically accurate that up to 60% of Manager A's team(s) used to get in the top 20-30% of ratings.

Wait a while, then add the confusion tool when meeting with other leads and managers, using it to extend the narrative and reinforce it beyond the initial review meeting. "But perhaps Manager A used to rate his team(s) so high because they were together so much and really brought each other up as a team." The inevitable follows, "But we still need to evaluate the individual against the whole. Is Q1 really more qualified than Q2? Did they produce the same amount of work? Did they make the most of their individual opportunities? Why are they where they're at after all this time?"

It's at that point that I drag in the whole ethos of the department, "Didn't we change our organization so that we'd take the focus off the individual and put it on the team? Isn't our new direction centered on verticals and Agile? Shouldn't we be rewarding teams that exemplify what we're organizing toward?"

Loop it back to the initial discussion. The initial story. "That reminds me of X's team. They were criticized earlier in the year for their lack of ownership Not as individuals, but as a team."

There's a bit of dissembling from the whomever I'm talking to, which I'm counting on. I immediately move to offset with, "It was my director who called them on it. We had a lot of discussions around ownership and that team and how to remedy the problem. I was in the followup and review meetings to discuss what was done well and what was not. Individuals were mentioned, but the concern was with the whole team and how to change the communal attitude."

I'm not saying Director R would be easy on ratings. I know better. But Director R would be looking at whether ownership improved with that team this year and how that was servicing the wider department. That improvement might be credited to the lead. But the team improvement would be the crux of any investigation. Director R wouldn't be as concerned with the ratings. They were secondary to Director R's goal of better teams, better ownership, and better communication. So I ask myself, is their ownership better? Is their team better?And the answer is, almost to a person. They've changed one of their internal stories and followed through on living it at work. It's almost too bad we carved them up with the reorg, as they seem indicative of what we're trying to capture going forward. Ownership. Team focus. Reinforcing each other. Living or dying as a team. There are exceptions. But our own rating system works against really calling out the poorest players, pushing everyone toward a central bell that is more than a standard deviation wide on each side. 75-80+% fall into the middle. Reviews don't recognize the individual. And they don't recognize the team. If our reorg was truly focused on Agile, it should strengthen, should reinforce, those internal connections that are hinted at by teams with elevated ratings, that indicate Agile teams where there's a desire not to let down your coworkers, even if the individual review process weakens what we're trying to create.

Can you mentally scrap our review system? Instead, picture what teams you would reward for working well together, despite the restrictions and roadblocks that are there, that we're attempting to eliminate. Are they the same teams the highest rated individuals are on this year, or are there teams that produced without star players? Maybe X's team, even if you don't know them well enough, falls into that paradigm. Maybe X believes that of them.

And here we get to a big slice of the issue. Malcolm Gladwell says in Blink that we adjust to our explanations. We adjust to our stories. And if our stories are about rating the individual, and not rating the team, then that's where we put our focus. And the biggest issue is that our vocabulary, how we cast and perceive how we talk about something, is limited to a shared vision. In this case, the individual, not the team. Gladwell talks about "jam idiots". People who know that something is wrong, but can't talk about it, because they don't have the vocabulary to explain why it is wrong. In the case of reviewing jam, you don't know to talk about taste, texture, berriness. In the case of reviews, you don't know that "team" is a possible category. Experts have a vocabulary. If your'e not an Agile expert, team is not necessarily an intrinsic part of your vocabulary.

We file patents as a team. We produce as a team. We work as teams. We review as individuals. If our goal, our drive, is to create high-quality teams of craftspeople who work well together, then the vocabulary has to change. The review process has to change. And the courage to address that process has to change. It can't be something that even higher level leaders are afraid to address in print. There has to be a better way. And there has to be a better story. About the team. Not about the individual.

Peeing on the Waterfall

One of the developers at work, on my recommendation, wrote an article for my work blog called, "Peeing on the Waterfall" about how Waterfall is a misinterpretation of something that was originally intended to be more iterative. It's surprising how much concern you have to put into a title like that, thinking about whether it matters for job longevity.

I might have said "no" if I had dropped that search into Google before approving the title, as the primary hits were:

• Someone actually peeing in a waterfall on MySpace.
• Lengthy stories about peeing in waterfall displays.
• And, most disturbing, the Urban Dictionary page related to Vagina Waterfalls. I quote from the section on Yiddish Waterfalls:

While a woman is peeing in the toilet you attempt to pee through her legs into the toilet. Of course this is nearly impossible thus you end up peeing on her urinating vagina thus causing a waterfall. Not typically done for wierd sexual pleasure. Only in the case that you both have to go and the house only has one head.

Oh shit there's only one bathroom at this fucking party !!! I guess we'll just have to Yiddish waterfall babe.

Really? This is something that needs a title/description? Just to be entirely above board, I once peed in the same porta-potty as a woman at a George Thorogood concert, but no Yiddish Waterfalls were involved, just a pleasant discussion about the concert, what we'd each been drinking, and pleasant introductions.

Real World Agile User Experience Design - Jeff Patton (Part II)

So what are User Experience designers learning from Agile now that the methodology has left its impact? Patton identifies thirteen patterns:

1. Drive: usability practitioners as part of the product team or as product owners. This is a good thing, but be careful about backseat driving.
2. Research modeling and design up front - this should happen, but only just enough. As (Alan) Cooper stated, there almost needs to be a Sprint Zero (0) or Iteration Zero (0) where product discovery can happen.
3. Chunk your design work - design work should, when possible, be handled in manageable chunks. We've all heard of sprints to investigate and dig into unknown (un-estimateable) pieces of functionality, but some digs can be too big to achieve in an iteration, particularly without an evolved basis for design decisions (understanding your decisions provides a context for future decisions...makes sense). It's important to know, Patton says, what's a napkin and what's higher level when it comes to design. To ensure these decisions can be evaluated accurately and chunked appropriately, some work can be done in advance (here we start to cross paths with Alan Cooper once again): a.) pragmatic personas can be developed, evolving from lightweight personas, usability sketches, and provisional personas; b.) backlogs can evolve into story maps and task analysis grids. Patton recommends The New Backlog is a Map as an evolutionary step; c.) start your usability investigations for Agile-centered design early, using tools like Sketchbook Pro (product). To give this point some relevance, think of internal projects, even Agile ones, that seemed to lose their way architecturally for a time. A lot of drift is expected in Agile, but it should be controlled drift, not the kind that comes from a loss of vision leading to meeting bloat and a feeling like the rudder has slipped the hand. A solid design should allow informed decision making and course correction rather than directionless floating in some Sargasso Sea.
4. Use parallel track development to work ahead and follow behind. What the product owner team is working on should apply to the previous, current, and upcoming iterations. Design and coded features should be passing back and forth between them and the development team.
5. Buy design time with complex engineering stories. Play a balancing game. Look in the story map and determine which stories are heavy on design and which are heavy on development. try to level by pushing lightweight design with heavy development to the front of an iteration (or even the whole project) to give developers something to do while they heavy design stories are researched. this plays hand-in-hand with chunking your design work so you know how the chunks fit on either side of your fulcrum.
6. Cultivate a pool of users for continuous user validation. Having to find new users each time a piece of functionality is considered can be a drain on a project and can delay design decisions. Identifying responsive users, ensuring a pool large enough to cover gaps (vacations, et al), and building a relationship and sense of pace with them results in more nimble design decisions.

Real World Agile User Experience Design - Jeff Patton (Part I)

I listened to Jeff Patton at Code Freeze 2010. He comes more from the user experience side than (Alan) Cooper, and he presented on the integration of design into day-to-day work. His core idea is that Agile, in eliminating the old BDUF (Big Design Up Front - I like BUFD, it sounds more like "buffed", implying some sort of dim, Jersey Shore, over-muscled, guy, which I can correlate to the slowness and excess of process often associated with Waterfall. By the way, you can get your own Jersey Shore nickname here. Mine is "Tan Jovi") process, has fundamentally altered how design is accomplished. Newer User Experience and Interaction experts are increasingly relying on lighter, more collaborative, practices that make design part of a holistic project approach.

Patton says that this history can be broken down into four parts. 1.) How User Experience (UX) was. 2.) How Agile wrecked everything. 3.) How User Experience design is in an Agile context. And 4.) What's next.

How User Experience/Interaction Design was...

Design followed an isolated phase model. That is, design was a separate precursor to other work, done by a designer or Business Analyst or business representative up front. It was characterized by fewer people, less collaboration, and more specialization. The emphasis was on information gathering, documentation, completeness, defensibility, and culpability. We all know the model or some variation on the model. Business needs >> user needs >> model the users >> high level design >> detail design >> specification >> develop software >> test (test, test, test...test, test, test) >> release >> maintenance.

The isolation of phases was obvious in the language gap (or syntactical overlap - choose your poison) between design and development and, later, between legacy design words and Agile vocabulary. Consider the difference between old school design and Agile when it comes to phrases and words like design, iteration (Agile builds it, Design sketches it), customer (Agile focuses on user story providers, Design focuses on the person who buys the product), user story (Agile focuses on what someone wants built, and Design focuses on a profile of a user), test-driven, and a "small bit of software" (Agile means "built in a few days". Design/UX means "something that seems small as a piece of user functionality. There's a enormous gap when you give that some study). The result when Agile, with its holistic, iterative, design/development/testing entered the scene, was to provoke in UX designers what Craig Villamor referred to as the five phases: denial, anger, bargaining, depression, acceptance.

Postpourri - Agile, Bananas, Breakfast, Beer, Memes

Been a while since I did a postpourri, but I had a few things queued up that I found enjoyable:

1.) How to open a banana at viral video. Perhaps Mean Mr. Mustard can benefit from knowing how to open those bananas he stores in his banana bunkers.

2.) Know Your Meme - in case there's an internet meme you don't understand or missed. You can't be expected to function in polite company if you don't know about Om Nom Nom Nom or the Keyboard Cat.

3.) Conner posts a link to the beer flow chart which advises you what to drink (hmm...this link might work better).

4.) Metro magazine reviews breakfast. I ordered a subscription to their magazine after reading their breakfast articles. They review the bacon independently. That's good journalism.

5.) How to turn your chest freezer into a chest fridge (why? because it saves you a lot of money when the cold stays in the fridge, and you can stop yelling at your kids, "QUIT STANDING AROUND WITH THE DOOR OPEN!")

6.) Boing Boing has a quote on their site from 8 years ago quoting Joel on Software talking about the MBA mind that I found highly amusing if you work with Agile at all:

"People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think "oh, gosh, how much harder could it be to make it actually work?"

The big risk here is that if you mock up the UI first, presumably so you can get some conversations going with the customer, then everybody's going to think you're almost done. And then when you spend the next year working "under the covers," so to speak, nobody will really see what you're doing and they'll think it's nothing.

What do Agile Managers Look Like?

What does an Agile manager look like? According to Alan Cooper at Code Freeze, you can't manage craftspeople. Instead, you have to facilitate. A good Agile manager will:

• Define and reiterate the overarching goal (focus on the quality line, not the deadline),
• promote standards,
• focus on what to avoid and potential obstacles,
• help everyone on the project focus,
• own the problems and eliminate roadblocks. [author's note: as a manager, I consider this to be paramount. Making sure developers can come to work, sit down, and start coding, is priority number one for a good manager, whether they be Agile, or traditional waterfall].

The factory has moved to the brain, and managers who continue to follow an outdated factory floor management paradigm are going to have an issue with that change. Don't think you can convince them. Just do the right thing and drag them along so they have to confront reality.

Sanjiv Augustine in "Managing Agile Projects" repeats this same criticism, "Managers trained in predictive, plan-driven project management techniques face a learning curve when entrusted with the management of agile development projects." (xvii)

Snowman Model

At Code Freeze, Jeff Patton referred to the "Snowman Model of Iterations" where the daily scrum feeds into larger iterations (Powerpoint of the snowman here). He scribbled a picture much like the one below. There was quite a bit of focus at Code Freeze on being able to draw some of the ideas that are involved in Agile or your design, so that they make a lasting impression on the many players in the project, particularly the product owners. This isn't just an Agile skill. Being able to create a lasting image in the mind of your audience is one of the best ways to foster change. If you're in my group at work, you may have seen "The Heart of Change" (John P. Kotter) on a manager's bookshelf, or you saw the video at the organizational realignment meetings where managers sported mullets and talked about how the web was just going to be a fad and CDs were the future. Kotter's book recommends making that visual leap that makes people feel rather than see, with images akin to Patton's snowman. If Agile is about harnessing change, then it's also about creating that indelible image for your audience that communicates that vision and creates a repository of shared imagery.

What do Agile Managers Look Like?

Alan Cooper was asked at Code Freeze 2010 "What do Agile Managers Look Like?" His response was, a manager can't manage craftspeople. Instead, they have to facilitate. A good Agile manager will [and I'd posit any manager should]:

1. Define and reiterate the overarcing goal (focus on the quality line, not the deadline),
2. Promote standards,
3. Focus on what to avoid and potential obstacles,
4. Help everyone on the project focus,
5. Own the problems and eliminate the roadblocks.

The factory has moved to the brain, and managers who continue to follow an outdated factory floor management paradigm are going to have an issue with that change. Don't think you can convince those managers. Just do the right thing and drag them along so they have to confront reality.

Alan Cooper - Insurgency of Quality

Alan Cooper's presentation at Code Freeze 2010 was on the intersection of Agile and interaction design (IxD, the study of devices with which a user can interact - http://en.wikipedia.org/wiki/Interaction_design). A big theme of Cooper's presentation was that a certain amount of design underpins even Agile

projects [e.g. up front, as opposed to within the iterations], although it's not always acknowledged and is overshadowed by the Agile practice that a project iterates toward a mutable goal and design, development, and testing often go hand in hand.

As a point of argument, Cooper noted that even Agile projects don't begin at scrum/iteration 0 (though perhaps they should, and he'd heard of groups who have). Yet, there's always some sort of dig or prep, and the length of that bricklaying, as Cooper called it, varies from project to project, even in the Agile space. While small, greenfield, uncomplicated projects might be capable of iterating from day one, larger projects are circumscribed by:

• The size of the code base
• Team inertia
• The history of the product

These factors, in turn, are constraints on the ability of the product owner or product team to give their full attention to the project. The problem then becomes that, without an appropriate amount of design up front, the product owner can be constrained in their ability to make or evaluate "battlefield decisions." These decisions, which increasingly become the mandate of the developer and not the Project Manager or Product Owner, who is otherwise engaged, can have an impact in the board room as they roll upward.

There is an interplay between Agile and design that is at odds with its

elf. Tactical decisions fit with design and can be timeboxed. Strategic and analytical decisions do not fit within Agile timeboxes. Yet the latter underpins the former, and without a solid foundation, tactical decisions can take the project further and further off course, beyond what's expected from the natural realignment with each iteration.

What does Cooper recommend to counteract unwanted drift and unhealthy battlefield decisions in Agile?

1. Get the product design out of the hands of the PM, BA, Code Librarian, C** and, in many cases, product owner/product team. They often do not have the big picture in mind, and their other responsibilities and job limitations can interfere with understanding the strategic design.
2. In the tradition of Peter Drucker, place decision making in the hands of craftspeople or practitioners. As Cooper calls them, "no collar" knowledge workers. Those closest to the design and those focused on interactive, agile, craft-based design, and not focused on process for the sake of process. Foster a "selfless insurgency" in skilled, trained interaction between craftspeople of equivalent level, targeting the quality of the product and the satisfaction of the customer.
3. Keep conceptual decisions frontloaded where they're cheapest and customer feedback has the most impact. As time increases, move from the leadership-heavy interaction design to development where everyone understands the impact of the early design decisions.
4. Ensure designers focus on funneling (as a metaphor), not seesawing. Make sure they align on a clarity of vision.

In the end, Cooper gave a metaphor for a successful project that embraced design and Agile. Think of a nursery full of children. All of them are yelling, "We want candy! We want ice cream!" If you truly understand the design leading into the project, you'll listen and decide, "They're hungry." Then you'll do the right thing, the responsible thing, and give them broccoli and liver.

Code Freeze - The Collective Groan

One of my favorite moments at Code Freeze 2010 was when a presenter noted that everyone pictured on a particular slide worked six different projects. At that pronouncement, a general groan arose from the audience.

Where I work, I currently keep a load of around half a dozen projects, although if you slice and dice them, or consider my space to overlap with that of the other manager who does the same work, the portfolio is considerably larger. Fortunately, I have smart leads, and they really handle the bulk of the lifting, allowing me to focus on wider issues. But to stress how many projects you can expect working in my area, one of the question sets on my lead hiring interview form is "Have you worked in a matrixed environment? On how many projects simultaneously? How do you handle the context switching and constant flow of information? Where do you put your focus when there are competing priorities?" I've dinged more than one interviewee for never having worked on multiple, large projects simultaneously. Despite the groan from the Code Freeze audience, the interview process turns up a significant number of developers who are allowed to maintain their focus.

In my last role, I think I maxed out at thirteen simultaneous projects, not including my generalized day-to-day role. One project, overseas, consumed about 50% of that time, and the others cycled up and down over days and weeks from zero to twenty hours. But all were partially active, somewhat different, and not predictably cyclical. It wasn't abnormal to have twenty hours of concrete work flow in over the course of a day. The goal was then to push it down as fast as possible because you couldn't be sure the downswing was coming immediately. Additionally, when you were on call, you might be fielding questions, requests, functionality assessments, architecture explanations (and changes), training, coding (yes, coding - I still touch code, even now), and more, for upwards of twenty simultaneous teams/projects (we called them "partners"). Handling half a dozen projects in my current role has been somewhat relaxing by comparison.

But I should append that it was my old manager who once took a look at my forty hour per week schedule and dumped an extra twenty hour per week partner on me, overloading me. She was the first person who ever concretely pointed out to me that I work more effectively when I've got a little too much to do. That sort of load compels me to find ways to streamline until I'm back down to forty, and the processes and code I put in place generally benefit everyone. It was a good call on her part, and I've always felt it's evidence she was really paying attention to me in her managerial role.

I guess I'm trying to say I wasn't one of the attendees who groaned - which is a bit suspicious, because as a developer I seem to thrive in a matrixed environment (I'll post a bit about big company hiring premiums later) - but knowing that each employee is different, I can empathize with those that did, particularly as agile recommends avoiding context switching, and find some humor in the general despair that it's often expected of those who thrive in a more focused environment.

The Downfall of Agile Hitler

I owe someone at work a big thank you for pointing at me this video. A warning, it's only really funny if you've had to talk Agile for any length of time. I was laughing out loud in a few places and I really wish I could put it on the Agile blog I admin at work, but I'm pretty sure that might be a career killer:

Agile Highway Construction

I noticed that the Highway 35E construction near 494 has a large sign board right next to the portapotty, decorated with various articles and details. Yes...they seem to have discovered Agile. They have a storyboard. It can't be for passersby, as you can't read it from your car, and there's no place to pull over. I picture the road construction individuals going over there and picking off individual work items for their next sprint, to peruse while they're doing their (other) business. Truly, Agile It.

Yesterday, before playing board games, I went geocaching around Lake Phalen. As I was pulling in to park, I noticed a lot of signs announcing that Waterfest was underway. I expected bikini-clad women bending over muscle cars, and acres of wet, white t-shirts. But mostly it looked like a lot of people just sitting in boats on the lake. Seriously disappointing. But while searching for the cache, I did find the nest of a homeless person, all tricked out in dirty clothes and empty 40 bottles. At least I don't think it was some geocacher who couldn't find the cache at first and decided to stay until they had.

During boardgaming day, I was given a gift. Porn. You see, I watched an episode of Attack of the Show! (G4) quite a while ago, and they listed their top 10 porn movies you'd want to have on a deserted island. #1 was "Porn Wars" - a Europorn spoof(?) of Star Wars. I think it was Sean who asked yesterday what made it "Euro", to which I replied, "no dice." (If you're a boardgamer, that is an incredibly witty, yet geeky, joke). I pointed out to my wife that we only had one single friend, and Porn Wars would be a hilarious gift. Unfortunately, it was hell to find, and I ended up ordering the trilogy (yep...trilogy) from Spain, which contacted a California shipping agency to forward it. As you might imagine, this left little room for a salutation. So when Kyle got it several months after I ordered it, even though I'd warned him I'd sent him a very unusual gift, he shipped it back. He seems to have felt at least a little surprised that he didn't attribute such a purchase to me, so he scoured eBay for a copy and gifted it to me on boardgaming day. I have yet to watch it, but when I do, I'll be sure to post a review. As Pete says, and I paraphrase, "I wonder if there's a Dickstar?"

And speaking of snail mail gone horribly wrong, I think I can comment on this now that it's been a few weeks. The only other piece of US Postal-related mail I've sent recently was a tattoo that Eryn and I found in a geocache. It was a Hawaii Pipefitters Union Something or Other tattoo, and I thought, "The only person I know who's been in Hawaii, and is in a union, is my friend Dan'l." So I asked Eryn if I could send it (what's she going to do with a Hawaiian Pipefitters tattoo) and dropped it in an envelope with a Honolulu return address. Seemed pretty innocent until Dan'l received it and thought it was something his Gulf I buddy had sent him, a buddy whose daughter, unknown to the rest of us (including his wife), was his goddaughter. He called the union in Hawaii and was wound up, until his wife thought to ask me if I'd sent it. On the one hand, I'm impressed that on some level I know Dan'l well enough to truly make such an egregious faux pax. On the other hand, I'm not sure how I could have avoided doing something boneheaded in the long run short of never sending him anything, which really isn't my style. I would have never thought to question the tattoo after sending him the heads of the Christian holy family in the mail with no consequences. My apologies nonetheless - not for the sending, I was bound to do something like that sooner or later - but for the resulting anguish. I can still feel bad about it, even if I couldn't have anticipated it.

So two friends, two bad mail experiences, in a short timeframe. Obviously I'm on a roll. So if you're a friend who's currently questioning something you received, call me before leaping to any conclusions about what you find in your p.o. box.

She Says asked me a follow up about the cement. It was going to cost us $600 to fix a few jutting slabs of cement, or $1200 to fix the whole sidewalk and some extraneous pieces (about 5x as much cement). So the math made sense, particularly given that the sidewalk had sunk over the years, or the yard had risen (more likely), and the whole thing was a great big ice slide every winter. As Jeremy the Renter noted, "The ice on the sidewalk only went out last week."

Yesterday, on the way to gaming, I was singing along to Finger Eleven's Paralyzer and realized that in the rearview mirror, I could see my mouth singing in my sunglasses, which really reminded me of Manfred Mann's Roaring Silence cover, as well as an advertisement I'd seen in a magazine which turned into a mouth as eyes photoshopping content at FreakingNews.com. Sorry Mean Mr. Mustard, I tried to find it at Worth1000 and had no luck.

Eryn, Pooteewheet and I placed a new tooth geobug for her today. She's lost three teeth so far, and the Tooth Fairy has brought her two tooth geobugs, and a shark geobug (he's toothy! I'll post his picture when we drop him off). We dropped it off today at Oak Terrace East Park in Burnsville, which is where I've been doing a lot of caching lately because it's just a bunch of great walks, and there are about 10 caches within .2 miles of each other. Still, a long walk when you have to go between them, because it's never a straight line. We've been turning each cache trip into a picnic and playground outing as well, so it's a family thing. Today I found a bunch of caches that Julie, a coworker of mine, had found back in January. Brrrrrrr.

The cache we didn't find today was this one. Very irritating, because I think it was a decoy. I looked around for a while because it was empty, but to no avail. But I'm about 99.8% convinced I should have looked harder, or thumped the bottom a bit more (the log, not Pooteewheet) to see if it was hiding there. This is why geocachers are annoying - they think they're all so smart and clever. Bastards. (Of course, I think I'm smart and clever when I actually find it, so it evens out in the long run). I also found my first puzzle cache today! It's actually my second, but the first one was pretty easy, the coordinates were in octal, and I didn't find the second stage, although I've retained the clue. This one I figured out by picking apart a James-Bond-esque set of clues on line. The last person there was almost six weeks ago, so I know it's a challenge.


Finally, Kyle, if you get this far...how was Adam after that last glass of Johnnie Walker Green? He seemed borderline (nonsensical folks, not borderline comatose - and in that way where you sort of have a well-informed, firm comment on everything, not in the way where you sound like you're speaking another language) going into it, although he was playing Cash n' Guns with some authority, so maybe it wasn't that bad.

MBA-Lite

I've been working lately on trying to pull together some MBA-like skills. Specifically, I have an urge to be a technical manager, at least somewhere down the line, after I finish up my new position working with the Japanese affiliate (for which I traded the Hong Kong affiliate and Australia/New Zealand affiliates. Don't assume it's a bad trade - Australia/New Zealand is currently a zero hour project, and Hong Kong not much more. Japan is high profile and 30-40% of my work week, and I support around ten-twelve projects, so it's big) and covering for a coworker who's leaving on maternity leave, doing her inhouse (and outhouse) training. Toward that end I've been looking at MBA programs in the Twin Cities. I had already been to the Carlson School of Management orientation, which seemed very reminiscent of my years at the U of MN. Recently, I went to the new MBA program at Hamline orientation. Their program is just getting off the ground and is the baby of a single, motivated man, "Poppa Bob". When Poppa Bob mentioned that his wife works in skin over at the U of MN (complexion skin, not pornography studies), I asked my mother if she knew him. She replied, "Talkative, kind of quirky Ukranian?" Yep. Spot on. But I'm not going to do that program either. Primarily because school just does not appeal to me, even with 80% coverage by my employer. It particularly doesn't appeal to me as a means to promotion.

I'll clarify that last point and do a bit of self-promotion by stating my belief that I'm already promotion worthy. I have good tech skills, an understanding of my field (tech, otherwise), an ongoing interest in my field, and what seem to be solid interpersonal habits (despite being a bit forward/confrontational at times - but that's a skill). I've had direct reports - seven at one time - done raises, done reviews, complained about the review skills of others, and run a project as both tech lead and team lead, on more than one occassion. My new position has been important to me as I picked it precisely because it would put me in front of aspects/groups in the company I did not previously interact with (the main product line, international groups, enterprise layers) and in front of job types I didn't previously interact extensively with: managers, directors, architects, project managers, business analysts, content experts. Given that I've spent an inordinate amount of time making sure I have experience (if not an understanding of) with all aspects of the company, if I don't feel like going back to school is the right decision, at least on a viceral level, why do it?

Ming said that you do it to meet people, particularly other MBAs - the people you forge connections with so that you can garner best practices (he didn't phrase it exactly that way - but he meant it). I asked him if he felt the other people in the room with us at Hamline were the sort of MBAs he wanted to meet and with whom he wanted to form lifelong professional friendships. He sheepishly admitted they were not.

So, in the interest of being able to talk and think like management, and in the interest of acquiring all the skills of a manager, even if I know that not all of them in my company have been through professional training (like an MBA/etc), I've decided to embark upon a self-directed study course, courtesy of The Personal MBA and a few add ons I feel are important, like a firm grounding in Agile and alternatives (yes...alternatives), tech, offshoring, ITIL, and whatever I find on the shelves of Directors and VPs. In order for me to retain something of what I learn out that huge mass of books (must read accounting, must read accounting), I'm going to be posting a few reviews now and then to help me clarify what I've been reading, relate it back to the other books I've read, and provide my insights for one or two others at my company who are pondering a similar course. Mac, already MBA-ed, and apparently in agreement about my decision not to use an MBA as a way to a promotion, can also chime in and correct my erroneous assumptions.

By the way, Mac. I am incredibly jealous that you're even hinting at getting published. I have a great big notebook full of about 50 short stories and 6 book ideas from the past year. You have inspired me to do something about those ideas other than leave them stubbed out for posterity.

Onward...the plan. I'll review a few of the books, generally in twos and threes so I can draw parallels. But I'm going to add the odd quote broken out here and there, not to draw attention to a particularly pithy observation, but to point out something I think is stupid or humorous. If you feel you're an expert on something business related, then at some point during your observations, you're going to say something horrible. It's just a given. I feel that you can't self-educate without maintaining your sense of humor - you've got to be watching for the surreal so that you're not taking everything you read too seriously.

"If I had learned what your book taught me sooner, I wouldn't be stuck inside
these walls today." - from an women's correctional facility inmate.

The first two books I read were self-discovery books, courtesy of the inter-library loan program. That means, I couldn't take the tests, because the goal is to make everyone buy a book and take the test. But I found that to be helpful. I really had to focus on how I felt about dropping myself into various personality buckets. The Personality Code focused on DISC, a yes/no examination of whether you were Dominant or Steady, and Interpersonal or Conscientious. The goal is to determine if your focus is on people or tasks, and active or reactive. Your preferences drop you into one of fourteen categories which are then expounded upon, for their own merits, as well as for how they interact with their anti-type. I have issues with a book that posits there are four dimensions to personality in the beginning, and then self-references within the rest of the book as though the original hypothesis is fact. Particularly given that Bradberry admits there are 123,000 possible configurations (p. 151) and he narrows it down to fourteen broad types. It doesn't seem like the issue is pinpointing your personality, but putting yourself in a generalized bucket so that you know how to react consistently in a situation, and given a particular type of foil. There's this unwritten (in the book) idea that leadership isn't bucketing yourself or others, but brushing yourself with broad strokes so that your reactions can be interpreted correctly and consistently, by you and by others. I find some value in that idea. If your motives and actions aren't transparent to subordinates and management, no matter how valid or altruistic, that can be an issue.

"Never threaten this person unless you are 100% ready to follow through." -
Strengthsfinder 2.0, p. 64

I found the appendix to The Personality Code to be much more interesting. It spelled out 26 emotional quotient (EQ) values and provided some research and ranking behind them. These are the things that, unlike basic personality traits, you can learn, change, and improve. Self-awareness, self-managment, social awareness, relationship management, credibility, courage, et al. Strengthsfinder 2.0 tackled these same EQ values, but with different names. I found less value in trying to peg myself to any one, or more, bucket (I believe I'm ideation, input or intellection, and responsbility, coupled with opportunist/expert) than in considering the themes and the value in recognizing all the EQ themes are abilities you should be able to access in an appropriate context. Which means, in the end, I walk away with, in addition to an annoyance about the focus on Rudy in Strengthsfinder 2.0, a very limited list of items that I feel were essential and common to both books:

1.) Know yourself. Know yourself well enough to act consistently and transparently.
2.) Know the personal and emotional tools at your disposal well enough to apply them situationally.

That last one. I think it almost spelled the end of a manager I know. That manager focused on the hard manager skills (tech, etc) to the exclusion of the people who were implementing the project. The rats-abandoning-the-ship that followed (not an accurate metaphor - perhaps, rats discovering nearby cheese with fewer traps is more accurate?) nearly shut that manager down.

"...cradle to cubicle..." - Strengthsfinder 2.0 (seriously, is there a more
horrifying phrase?)

Whoof. Were you expecting that much typing? I'm going to go one step further. Between these two books, my recent MBTI course, and a pile of developer/agile reading lately, I've been pondering a particular correspondence. Given Clay Shirkey's discussion about developers, software, and Bion, I wouldn't be the first to draw connections between psychology and software. What I've been pondering is whether what's considered great about agile development might not just be personality in the macro. What? I'll step back. I don't consider anything I've read about personality, or any class I've taken, to be useful in picking a team. You pick a team by interviewing and hiring good programmers and getting to know the people you hired and how to smooth out the bumps in making them work well together. Sounds like personality, but it's not an issue of looking at fourteen types and three dozen EQ themes. It's an issue of looking at all 123,000 possible permutations. Microanalyzing is no good. You have to look at MBTI in the large, situational leadership, and within your own judgement to create a matrix...a matrix that's no good unless you talk to your team and understand each of them as individual people (or hiring someone who's capable of fulfilling that role for you).

But in the macro, in a Hari Seldon fashion, I think there's something to be gained. Posit your business unit as a person. Posit your development group, as a whole, as a person. Developers seem to be intuitive rather than sensing. While it might seem like they should be sense-centric, all the facts ma'am, tell me all the discrete steps, I find that better developers, exactly the kind agile says are necessary for their process, are more intuition. They're focused on patterns, the future, and a big picture. They read books about patterns and objects and consider grandiose new ways to work with, and present data. A business unit, on the other hand, while professing to be about the big picture, is very sense-focused when scoped at a project level. Developer assurances about a new technology: css, themes, AJAX, agile itself, silverlight/flex - those don't mean much. It's too much. But a concrete, touchable, clickable prototype. That's gold. Those are the trees in the forest. And if you look at the groups that way, agile seems to be solidly entrenched in MBTI and information processing. We (and here I set myself as a developer, although the start of this post noted I want to be the business unit/management) get to tell stories. We pander to what could be and revel in inspiration. Inspiration. No one tells an agile story with an unhappy ending. That's fucked. It's not done. If you can't see the utopia at the end of your code: the Shangri-la or Keanu-resolved matrix - if you can't revel in the inspiration you feel your sprints and spikes will force upon people who don't even understand the underlying code - if you can't throw away that nasty technical documentation becuase it only fits one personality type, not the other thirteen, and certainly not your business unit - if you can't give your business unit the sensual information that best first their perceptual preference - than what the hell are you coding for. They're not the storytellers. You are. They're the readers. Real developers, agile developers, focus on what could be, and their business unit focuses on the touch and the taste. If they can touch it, sense it, feel it, then they can have a reaction to it and explain that reaction to the developers. A mutual need is fulfilled. And that's the focus of almost every personality exploration out there. At some point you and your foil have to meet on common ground. In the micro, that's a matter of two people talking it out, because there are so many personality points to consider. In the macro...in the macro maybe you can make some assumptions.