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.

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.

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.

Code Freeze 2010

Remember, if you see xb in the label, it may be cross blogged, and it's definitely about Agile or some aspect of development. Feel free to avoid it, although you will be missing out on a little deeper dig into some of what I do day to day.

Last Thursday, the day of the icy streets here in the Twin Cities, I attended Code Freeze 2010 at the University of Minnesota. In the past, topics have included Maximizing Developer Value, Innovation, and Global Systems/Global Development. This year's theme was Redesigning Agility.

After hearing Ming wasn't going and learning from him which developer was (apparently there was more than one from our department who went, but that information didn't make it down to everyone who was participating), I contacted Jonathan, determined he lived in Eagan, and arranged to be the designated driver. Considering it took 35 minutes to travel 35E from Lone Oak to the Minnesota River (a few miles) on the way to the conference, and an hour and forty-five minutes to get back to Eagan from the U of MN Alumni building, it was a good choice to carpool as it gave me someone to talk to for most of three hours of iced interstate driving. Maybe Jonathan disagrees. Maybe we didn't talk. Maybe he just got talked at. I seem to remember monopolizing the conversation.

The Symposium was great and I'll post some follow up on the presentations by Alan Cooper, Jeff Patton, David Hussman, and Tim Andersen. I appreciated that as a conference focusing on Agile, Interaction, and Design, and where the intersection of those activities is headed, the presenters felt there was space to disagree. Too often when I've gone to an Agile event, it feels as if all the presenters are lock step in their approach. That seems to be acknowledged by others as well, as there's plenty to read about whether Agile is a methodology or a belief system. Code Freeze had none of that feel.

A few non-Agile, conference-related items reminded me I live in Minnesota:

• When I had to go back to the parking ramp for my blackberry, I had windburn on my face before I'd even made it off the Alumni Building sidewalk.
• The steeply slanted windows on the Alumni Building pick up the snow in waves that flow down the windows in a cascading series of white akin to what you see when you shake an etch-a-sketch. It looks like you would expect the dune-building process at White Sands to look if you could accelerate time.
• So many people are bundled up that you can see bits of down floating on the air current inside, dancing in the sunlight. Minnesotans molt in the winter, just like geese. It's probably one of the reasons I sneeze so much, and my eyes water, at random times (that aren't so random if you listen for the blower).
• Despite those arctic-related anecdotes, there's still a constant stream of bicyclists passing by the window. Some without a hat or a jacket.

Code Freeze and Cross Posting

I once had a director who gave me this advice, "Stay away from low-visibility, long-term chores." Fairly succinct and useful advice. But what do you do when the low-visibility, long-term chore finds you and you can't avoid it? You can delegate, which seems rude unless what's low-visibility for you is high-visibility for someone else. Or, you can try to expand the visibility.

I bring it up, because I do writing for other blogs and communication tools, some of which are at work where the audience is limited by the scope of who's interested within a much smaller community behind the firewall. I hate leaving what I write behind the firewall. I want to hear comments from people who aren't at my company so I can correlate them to what I see internally. It doesn't help that I'm generally writing content on my own time and then dropping it there where fewer people see it. So I'm going to do a bit of cross-pollinating. Some posts that I could put in both places, I just will, after I've stripped out anything blatantly work-specific, like names, departments, and organizational details.

But I suspect some of you won't find my extended posting on Agile and Code Freeze and coding to be that interesting. So I'm giving you an out. If you see a label/tag that says xb, that means "potentially cross blog" (I don't guarantee I posted it elsewhere. I just thought about it.), and you can safely avoid that content. Unless you're interested, then by all means, please comment.