A big part of why I love working with agile teams is because over time they find that work becomes fun again. Every sprint is a new journey, another chance for collaboration, another opportunity for leaders to emerge. Watching previously dysfunctional relationships turn into close group work is extremely motivating! Sure, there is discipline, too. But the discipline is just a facet of a group of professionals working together. Professionals can also have fun while they work hard. In fact, for many, it makes for a better, more enjoyable day.

Remember the days when you were a kid playing cops and robbers, or monopoly, or in my case "playing business" (I used to charge rent and write receipts to the kids next door, you know, for fun). But think about how you played: you threw yourself into it. You suspended all disbelief and BECAME the evil villain, the landlord, the t-rex. You ran around the yard dressed up in crazy costumes. You weren't afraid to talk in a different accent to play up your character, or wear a cowboy hat. You would chase your friends around the neighborhood on horses (um, bicycles) and play freeze tag until the last rays of the sun retracted beneath the horizon. Your parents had to water you down with a waterhose because at the end of the day you were too dirty to even come inside the house to get a bath, and this felt like they were washing off the fun. You were sad that the day was over! You slept so well, and woke up early just to do it all over again. When your neighbor friend was sick, you were sad, bored, kicked around the dust, wondered what to do with life. It was no fun not having someone to pretend with.

What happens to us between those long summer days of childhood and now, when we're all grown up? What changes? Bitterness of life, of experience? Disappointment of expectations? We grow older, we get stressed, we break down. We forget how to smile, how to laugh, how to throw ourselves into a situation with unabashed wonder and happiness. We become too self-critical, too self-aware, too self-absorbed, too stiff.  We forget how to poke our friends in the ribs and yell "You're it!" and dash off running. We play hide-and-seek in the business world, not for fun, but for survival.

I challenge each and every one of you to have fun today. Play freeze tag in the office. Step out for ice cream (with gummi worms) with your team. Go bowling. Go to the park for a picnic. Heck, play cops and robbers if you want. Lighten up. Have fun. Bring the enthusiasm of childhood, innocence and play into your daily work life. Stop taking everything so seriously. Make a business card that says "Expert Hide-and-Seeker" or "Terrifying T-rex of Technical Development". Put up yellow caution tape around your cube. Put a picture of your family on your taskboard. Say hello and MEAN IT when you're walking down the hall. Offer a candy bar to someone you've been struggling with lately. Wear a silly hat. Do a silly walk. If you're not having fun building new products, what are you DOING?

TAG: You're IT! 

I have had some really interesting experiences lately with managers. I have realized that they underestimate their power. For example, I taught a 15 person group in California a while ago. They started out interested in learning more about Scrum. Their manager then showed up two hours late to the training, threw open the laptop and yelled at me (while still reading email), "Who are you, how much experience do you have, and WHY are you here? [rolling her eyes]" That was my introduction. Lovely way to start the day.

From that point on, team members were clearly just as disrespectful. All the laptops opened up at one point or another. People were late, stepping in and out of our training. This made things really difficult because the course is so hands-on! From time to time, I observed disrespectful giggles and passing of notes. I'm surprised I didn't have a 'kick me' sign on my rear by the time I left that day. I went back to the hotel feeling defeated, exhausted, and not really looking forward to the second day.

The second day started just like the first day ended. It was so bad that the VP had to make an announcement that no laptops would be allowed in the room and that people needed to be on time. I had already made these announcements several times, but it was clear that the group had no respect for me and this was allowable because, well, their manager didn't respect either.  All in all the absolute worst training experience ever.

I see this in other scenarios as well. Just today I was observing a planning meeting in which a manager was involved. There were several Pune team members on the open conference call as they were an extended part of the team. When the team would play planning poker, the manager would strongly announce "We have a unanimous 5 over here in the US!". I started to realize that the Pune team would have "unanimous" points after awhile, too. This manager did not realize that his use of the word "unanimous" could have been pressuring the Pune team to pick a number. Picking a number is not the purpose of planning poker (well, ultimately it is) but the discussion had by observing differences in numbers is what is really important. Again, another manager influencing a team and not even realizing it.

Managers, be careful of the messages you give to your team members. Non-verbal cues are just as strong, if not stronger, than the words you say. Words are very important too. When trying to build a team that is self-managing and self-directed, remember that you serve as primary role model. Remember this and take responsibility for your actions so that they can take responsibility for their learning.

A ScrumMaster approached me a while ago about what to do with his team: The team felt like they were communicating just fine and did not need the daily scrum meeting. The ScrumMaster was convinced that the team wasn't really communicating all that well, that they just gossip from time to time and have ADD. I found this interesting.

The first question I have is Why? Why does the team feel like this meeting is not helping them? Turns out that the team feels like they already have their direction everyday and the daily scrum meeting seems like a waste of time. They see no value or impact from attending it and would rather put their heads down and just work.

I asked Why? again. Why does the team see no value? They said because they already know their tasks everyday because their Manager gives them their work. Aha! Now we've discovered some helpful information.

I asked Why? again, but to the Manager this time. Why do you feel like you need to be the taskmaster of the team? The Manager responded that he needs to keep the team on track? But Why? - again I asked. Because we're under pressure. Yes, and Why? - again I asked.  Because we were just bought out and we need to quickly merge our technology with our new parent company's. Aha!

My synopsis: Pressure by parent company forcing undue pressure on management who must then feel as if they need to revert to form (aka "micro-manage") to get anything done. Becoming TaskMaster means that team members don't have to think for themselves or own the work, so of course they feel like the Daily Scrum is useless.

When you need to get to the root of the problem, use one word posed as a question: "Why?" Otherwise, you could make assumptions that aren't necessarily true. For example, in this case the ScrumMaster thought that the team members had ADD or were not very focused on their work. Turns out that they were focused, but only at the direction of their manager. A ScrumMaster could also make a false assumption that the team members were just fighting Scrum. They weren't. Their manager was.

Click here to go to SixSigma's website that explains more about the Five Why's. Additionally, check out this description of Fishbone diagrams, another helpful tool to sort out various causes of behavior.

I ran the Philadelphia Blue Cross Broad Street Run this morning in 1:39:39 - my best run to date! I was so happy that I broke through the 10-minute mile I've been running steadily for some time now - it's great to be (barely) in the 9's - woo hoo!  It was a beautiful day - started out a little hazy and then the sun broke through right as I was at mile 9. There were over 20,000 people there, and I finished in the top 2/3 of my age class. Next year, I will do better. For now, I am nursing two toenails that are about to say au revoir to their respective toes. Disgusting, I know, but well-earned and I'm (freakishly) proud of them. ;-) Will post a pic once they're up (of me at the finish line - not my missing toenails). :-)

I have realized lately that many people are afraid of agile because they feel like it's a complete rip-out and replacement of what they currently know. In other words, the internal dialogue goes something like this: "I am learning agile. What does that mean for me? Oh I have to learn how to do agile engineering practices that seem strange and weird. I have to learn how to do release and iteration planning that involves everybody. I might need to pair with a peer to help me make better decisions, and you know, I really should deliver high quality product every sprint. Gee, I don't know how to do that."

What these folks don't realize is that they DO know how to do this. Are proper coding disciplines of stabilize before adding change really anything new? Is peer or code review any surprise that it works? Is it so strange to plan a 30-day sprint (or project phase) with a team following an agenda that you've carefully prepared? These are probably not new techniques for you.

What I encourage you to do is make a list of all the things that you currently do as a traditional manager or team member that brings you success. Is it the 25 years of experience you bring to the plate? Is it a keen sense of risk identification that sets you apart? Maybe it's your impeccable skills of persuasion. I urge you to identify what you're already good at and play up those skills. Likewise, identify the things that you know you need improvement upon and create S.M.A.R.T. goals to improve those skills. This list of improvement becomes your own personal improvement backlog.

Just because you're learning agile doesn't mean that you throw the baby out with the bath water. So much is about learning to apply what you already know in a different context or at different times and different depths.

Some ideas for your own personal improvement backlog: List your strong skills, rate them 1 to 10, have your team or peers rate you, identify SMART goals to increase your rating by 2 points, measure three months from now
List your areas of improvement, rate them 1 to 10, have your team or peers rate you, identify SMART goals to increase these areas by 3 points; measure three months from now

Keep measuring yourself every three months. Identify new areas of improvement as you go, and don't forget to reflect on the improvements you've made along the way! List out the steps you took to improve, as well as the measured results. I've always found it helpful to have a mentor as well.

Hello everyone, just thought I'd send a formal announcement that the Software Project Manager's Bridge to Agility has gone to print! Michele and I put our hearts into this book and hope that it is beneficial to project managers who wish to learn more about Agile methods. It is listed on Amazon.

Recession. Downward turn. Job cuts. Everywhere you turn there is a negative report on the economy. Don't get me started on the politics and crookedness behind all of this lunacy. What I'd like to focus on, instead, is the mental havoc this media storm is probably wreaking on your team members.

Maslow, in his five-stage hierarchy of needs, states that an individual must first have his biological, physiological and safety needs met first in order to climb the pyramid toward goals like esteem and self-actualization. It's gosh darn hard enough, even when times are good in an affluent economy, to help folks feel secure as agile team members - folks who are paid as the knowledge workers and technical thought leaders of their respective organizations. Often this is due to a mismatch in reward system vs. 'new' behavior that managers implementing agile are seeking. But now, even compounding the reward system is that person's internal thoughtstream that says "yeah, right. I'm not stepping out on a ledge when I might lose my job, or when someone else can be hired for half my salary. Guess I'm playin' it safe these days."

With the "R" word (and in some cases - even the "D" word) being thrown around every .002 seconds, it probably wouldn't surprise you if your teams shrink back into the corners, play it 'safe' by the rules and not take risks. Concern over the rising unemployment rate and deflation of the dollar's value is enough to make anybody wilt into a pile of goo.

Managers and leaders: reiterate the safety and security message to your team members . At a time when government regulation of business increases every day and stifles us, we have to remain steadfast in our ability to deliver on ideas that will take us into the next economic wave. Promote thinking of new ideas to continue to sell products in a weakened market; open up new opportunities for other segments and audiences, think small and rapid. See the previous blog for some other ideas.

It's difficult to pick up the newspaper these days, but to get through this, we have to stay creative. Press on. 

I know, I know. Agile teams are supposed to be, by definition, these microcosms of self-organization, collaboration and creativity. And I've seen some that are. Some. Most, however, either don't learn how to become self-managing or self-organizing and take all of their orders - including technical 'how' orders - from product management. There are a myriad of reasons for this, and most boil down to lack of management support or lack of team knowledge of 'how to' become innovative. Lee Devin and I collaborated on the following excerpt from what was supposed to become a published magazine article; however, I don't think it's going to make it in glossy print, so here goes as a blog. We'll eventually make this available as a whitepaper.

Part 1: What Management Can Do So That Teams Stay Innovative

We define innovation as a valuable new product, service, or idea, that results from the creative process of collaboration. Sometimes we see an innovation in the foreground: an agile backlog created out of a new idea; the backlog encapsulates steps that will realize the innovation, make it come to life. A new thing - an innovation - must create value if we’re going to invest in it; however, for a myriad reasons which we’ll explore, many good ideas don’t get to the table.  And another thing, how do we know something is an innovation until we see it? So doesn’t that entail investment in the exploration of the idea?

An innovation does more than improve something we already have or know about. An innovation breaks with the past, takes us into new territory. Polaroid cameras, an improvement in photography, sped up the chemistry that developed images on film. Digital cameras, an innovation, ignore chemistry to manipulate information.

Value, in general terms, means we can sell something for more than it costs to make it. Businesses have on hand marketing and sales positioning staffs who use past experience to determine the potential value of an idea. They consider the known knowns, so to speak. But what if the thing is truly new, a genuine innovation? Well, then we’re in the soup. If an outcome is truly new, the market can’t yet value it very well, so the marketing department certainly cannot; customers have a hard time knowing in advance that they’ll like something they haven’t yet seen. Accommodating to this new reality takes a huge conceptual leap that changes everything, from the way you do your work to the expectations you have for its outcomes. Often these really, truly new business-transforming ideas are discredited as weird, rejected as not within current portfolio budgets or strategic plans, or, worst case, ignored altogether.

The mystery of an innovation’s value also means that our traditional ways of making a thing, service, or idea need rethinking; additionally, we need to rethink our reactions to and acceptance of the new idea. Making something new will require new ways of making, new attitudes toward making, and new methods of managing makers. Beyond that we can say only two things for sure. First, if we truly collaborate, we will make something new. Secondly, we can’t immediately tell if the new thing will have value right away, in the future, or ever. So we need to have an organizational stage that can accept the ambiguities of creativity.

To innovate effectively we need to learn how to create and operate in a new environment: let’s call it a Creative Culture. To help us think about such a culture, we propose a set of considerations for the management and leadership to think creatively and to respond productively to the creative thinking of each other. The first step to realizing innovations is to accept that there is no such thing as failure in an innovative process. The only failure is not being receptive to new ideas. 

How Management Can Set the Stage for a Creative Culture

Management can help innovations bubble up to the top by seeking, identifying, and budgeting for them. Here are some opportunities within an agile framework that management can leverage in order to set the Creative stage.
 
•    Organizational ‘tude. What’s your organization’s attitude toward what some call a work ethic? Is it that heroes get special treatment? Bonuses based on the amount of time you put in? That slack time is unproductive? How open, really, is your organization to the new, the funky, the insane? If your organizational attitude is that of ‘justify every dollar spent with a product increment from the backlog’, we doubt that your teams are finding time to be creative.

•    R&D. Why is it only the ‘chosen few’ who get to be on the Research and Development team? Innovation knows know limits or boundaries, so why do we set up these artificial boundaries called R&D? Rather, how can we empower and inspire everyone to think creatively? Here’s an idea: provide a place to capture those random ideas (The Innovation Backlog). Give employees the chance to make a business case for funding consideration. Work these in cycles just like any other project or list of things to do. The customer is the funding board. Encourage creative thinking even in the mundane, planned backlog items: Lee and I consistently see higher energy in teams who are working on the new technology, the new widget, the new thingamajig. This is because there is a level of R&D involved here, and the entire team contributes, shares discoveries and builds upon those discoveries.

•    Iteration planning and execution. Agile teams plan for and commit to a reasonable amount of work from the product backlog. This ensures that the iteration timebox will be stuffed with work that the customer has pre-defined (“kanban”). Then, the looming deadline inhibits out-of-the-box thinking. To counteract this, have each team reserve four working days of a 30-day calendar iteration for creative work, to dream up new ideas or chase ideas from the Innovation Backlog. Additionally, coach your managers to inspire creative approaches even in the mundane predetermined work. Discourage product managers from telling the team how “we do that around here.”

•    Day to day interaction. Do you have time for pairing? Or does your company see this as a waste? Do you still encourage the expert resource to stick to his/her area of expertise and specialization in order to move faster? Encourage everyone to get involved and share expertise. Individuals will learn more, in the long run giving your organization more flexibility and innovation. Oh, you'll have to reward for this new behavior, especially amongst those who wish to protect their knowledge kingdoms for 'job security' purposes.

•    Balance structure and risk by adopting a venture capital model to fund innovation. The funding board can “invest” in a new idea, making time and money available for development. As the work proceeds, the board can establish benchmarks: when they’re met, and the idea still has legs, it invests more resources. This not only supports the individual project, but sends a message to everyone: “This outfit makes room for the new.”

•    Hiring. Instead of asking a potential hire, “What certifications and degrees do you have” ask, “What’s the most creative use of technology that you’ve implemented”? Get a sense for the person’s ability to think in creative ways, to chase ideas past reasonable limits. Can you feel a passion and excitement for making new things, or is IT/NPD simply a job that his college advisor told him pays well?

•    Educate customers on the need for experimentation. Remind them that creativity can sometimes take calendar time. Will your customers go to the cheapest bid or to the company/team that can produce unusual (and unusually useful) results?

•    Put current initiatives into the following categories: Run the business, Grow the business, and Transform the business. How do your initiatives stack up? We suggest 25% allocation to the Transform category. Here’s why:

Not every innovation is THE innovation, so we need to allow for more iterations. Let’s take one of Stacia’s favorite products: the Dyson bagless vacuum cleaner. Mr. Dyson mentions in a commercial that it took 5,000 prototypes to create the perfect bagless vacuum cleaner that never loses suction. And he goes on to say that it would have been easy to look at these prototypes as failures; instead, they viewed these early ideas as learning opportunities, as necessary steps on the way to success. The result: a vacuum that cleans up all of the dog’s hair and doesn’t require bags or a ton of maintenance. If Dyson had budgeted for only 100 prototypes (or 4,999 for that matter), the product wouldn’t be as good, or perhaps wouldn’t exist at all. And last time we checked, Dyson profits were up.

Embrace iterations as experiments - after all that's what they are. They apply the scientific method of building a hypothesis and an approach to the solution (iteration planning), testing it out (iteration work) and concluding with "was it right?" or "was it wrong?" (iteration acceptance).

Each iteration for each of your teams holds within it some new discovery. Managers can properly set the stage so that these ideas are chased as well as provide a mechanism for discoveries to percolate through the organizational froth.

Next week, we'll look at what individuals on a team can do to prepare themselves for creativity. 

I had the utmost pleasure of working with a great team in London this past weekend. They had given a great run at 29 sprints, and had some questions about how to proceed. The experience was wonderful – people there ‘get it’ and aren’t afraid to try new ideas.

After the first day of training, like proper Londoners, we headed to the pub for a pint. Somehow we began talking about back pain with the manager, who peppered his story with a hilarious quip: “Oooo, me back.” He said this several times, which had us all laughing and repeating it after him.  Good times. By the second day of Scrum training, this had morphed into “Oooo, me backlog”.

While lifting weights the other day, which is a luxury (?) I don’t get very often, I had the opportunity to say ‘ooo, me back’. The squats killed.

My back is weak because I haven’t worked out consistently in about, well, ever since I started that darn book. Anyway, lately I’ve chosen great Spanish food and wonderful French desserts in addition to the occasional English pub on my recent journeys, ignoring regular exercise and all things bland and boring and good for you. The most exercise I’ve had lately (besides the occasional run) is schlepping my laptop bag from airport to airport. The only ab workouts I get are putting on my shoes in the morning (you know, you kinda need to bend at the waist a little). So it’s no wonder my back is weak. I could feel it creaking as I lifted all of 75 pounds on the Smith machine, not much by most standards, even though my legs were doing most of the work (and their condition is another story). Yesterday I paid for it: I could barely sit, stand, and the ol’ sciatic is acting up again, causing left leg pain. Say it with me, “oooo, me back”.

A weak back is due to a weak core. Weakness causes injury, bench time, sickness. Just like a weak product backlog (there it is, the allusion to Scrum – you knew it was coming!), a weak back causes pain elsewhere. A weak, poorly written, poorly organized product backlog causes the team to suffer, causes nerve pain. A strong product backlog is a strong spine for the team and the organization to work together; a weak product backlog causes stiffness, soreness and pain.

How do you strengthen your backlog? Just like any weight training regime: consistency, repetition, and working on weak areas.  The product backlog is the spine of your Scrum team or organization. Keeping it in good shape takes discipline and lots of hard work.

Here are some exercises you can do for your product backlog to keep it healthy and in tip-top shape:

-    Put it on a diet. If product backlog items are too big near the top, the team will spend lots of time in planning trying to merely understand the work at hand. Put items near the top on a diet; make them small and easily estimated by the team. Big backlog items at the top overload the spine, makes it top heavy. It's OK if your product backlog is pear-shaped!
 
-    Regular exercise. Everyday, scan the backlog for changes, clarity. Help the team by having talks with them about backlog items. Plan estimation meetings mid-sprint if you're having trouble getting your product owner's time.

-    Think about the next workout. Scan the product backlog for the next items that you want in the upcoming sprint. Give the team the ability to have an early look at the PBIs so that they can start working on the problem.

-    Give it the right gear. Keep your backlog in a place that is easily accessible, maintainable, and visible to everyone. Just like a good pair of running shoes, or a neck stabilizer for a bar, the right gear make it easier to do the task at hand, and prevent injury. Make life easy on yourself and find a way to automate some of the heavy lifting in your backlog.

-    Work out with a friend. You have a team of people who can help you with the backlog – the Scrum team and users (if you’re not one yourself). Enlist these people to help you write user stories, understand technical alternatives, trade-offs, best practices, dependencies.

A strong backlog is evident; it supports, not hinders, the team. A strong product backlog takes practice, discussion, and diligence.

Keep the pain out of your back.... log!