Get our video course, "Improv Your Agile or Scrum Stand-up", for free when you subscribe to our mailing list!

You're viewing all posts tagged with agile

Why Yahoo Might Be Right to End Work From Home

Share/Bookmark Subscribe

http://www.flickr.com/photos/8583790@N04/6947146193/Yahoo! caused an uproar on the Internet recently, when a memo leaked revealing that they were planning on ending all existing work-from-home arrangements by June of this year.

This change in policy has caused no end of outrage from not only Yahoo! employees, but also from those on the Internet and in the media who see telecommuting as the future of work.

The responses seem to range from those who see it as a huge step backward from an industry they expect to be pushing for more telecommuting to those who feel it is an attempt by Yahoo! to micromanage and control their employees.

Almost all seem to predict the end result for Yahoo! will be a mass exodus of the best employees and no one wanting to work there.

I’m not sure I agree with that sentiment.

While it’s entirely possible that the effect will be exactly as predicted and that perhaps Yahoo! is looking to micromanage its employees and weed out slackers, I don’t get that from reading the memo that was released. While all HR memos tend to be sugar coated, I tend to take people at their word unless they give me a reason to suspect otherwise. Let’s look at some of the actual text from the memo.

To me, this is the key paragraph,

To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices. Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings. Speed and quality are often sacrificed when we work from home. We need to be one Yahoo!, and that starts with physically being together.

As someone who coaches Agile teams, the things they seem to be looking for are consistent with what makes Agile teams successful.

On Communication and Collaboration

The memo specifically calls out communication and collaboration. Let’s look at one of the values and a couple of the principles from the Agile Manifesto.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools


When most of your workers are working from home, you require more processes and more tools to make collaboration happen successfully. It also becomes more of a challenge for individuals to interact with each other.

Business people and developers must work
together daily throughout the project.

Again, it is possible to pull this off remotely with good tooling (and I’m not convinced that there are good enough tools out there or that those who are doing telecommuting are using them), but this principle is difficult to adhere to even when people are working in the same office, so why add the extra layer of complexity?

And finally,

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

The further we get away from face-to-face conversations, the more information is lost. Tone, body language, and other non-verbal queues are lost and worse, when only part of the team is remote, it’s easy for those remote team members to be inadvertently excluded from on-site discussions which increases the knowledge gap between team members.

It is also much easier to build trusting relationships face-to-face.

If you want to build a culture of collaboration, high communication, and trust, then it’s easiest to do that in person and it sounds like that might be what Yahoo! is going for here. [click to tweet]

On Speed and Quality

The next section specifically calls out speed and quality. This has drawn a lot of criticism from those who have been working from home who claim that they are more productive and can get more done when they are not being distracted by their co-workers.

While many people are more productive individuals when they work from home (and some indicate some Yahoo! workers were not), I don’t believe Yahoo! is referring to individual speed and quality, but overall speed and quality.

In Lean software development, we often refer to ‘optimizing the whole’. That is, the efficiency of a system cannot be improved simply by optimizing the efficiency of it’s individual components. In some cases doing so can actually be damaging to the overall system. [click to tweet]

What often kills productivity in organizations is not how fast individuals produce stuff or how much stuff they produce, but how long they are delayed. The time an item spends waiting to be worked on usually ends up being greater than the time it is actually worked on. [click to tweet]

If you need assistance on an item and can turn to me and get it immediately, we as a team are more productive, even if the interruption makes me less productive as an individual. So if instead of getting the answer immediately from me, you have to write and send an email, or open a ticket in a ticketing system, wait for it to be prioritized, etc. We as an organization become much slower. While it can be possible to get good response times when telecommuting, it’s much harder and can never be as fast as having the person right beside you.

In regards to quality, if a decision is made in a side conversation at the office, that information may take longer to reach a remote employee, if it makes it there at all. This can result in costly rework. So while a remote worker may be more productive and producing more stuff, this gap may mean that they are producing more of the wrong stuff.

Conclusions?

Many of the issues I’ve raised can be worked around in a telecommuting environment, but it’s hard and you will still likely have more issues than an equivalent fully co-located team, so in the end each organization will have to decide if it’s worth it for the type of culture they’re trying to create.

While I’m not convinced that this was the best approach Yahoo! could have taken to the situation, I can certainly see why Yahoo! might feel this is the right move for them. They could have taken a more gradual approach, but perhaps they felt that delaying any longer would have led to more catastrophic results.

It will be interesting to see how this plays out.

Today’s image by craigles75.

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!

Comments

Status Reports Are Demotivating

Share/Bookmark Subscribe


http://www.flickr.com/photos/soldiersmediacenter/3521607551/I’ve been thinking a lot lately about motivation, and why we should be focused on building organizations around employees first and customers second.

Now I’m not trying to say that customers aren’t important, they absolutely are. In fact, I believe that providing exceptional customer service is the biggest difference between organizations that are successful and those that fade into obscurity.

However, I also believe that the only way to create an organization that is capable of providing the level of customer service needed to excel today is to make sure that your employees are truly the biggest proponents for your organization. And the only way you can do that is to put your employees first.

So how do you get highly motivated employees? Step one, stop demotivating them!


if management stopped demotivating their employees then they wouldn’t have to worry so much about motivating them - W. Edwards Deming [click to tweet]

That’s easily one of my favourite Deming quotes and it’s bang on. And so, I’ve decided to look at one of things that I have always found demotivating. The status report.

Here’s the situation. You’re going about your day, doing your job, and out of the blue you get an email from your boss saying something like, “Hey, would you mind sending me a weekly status report of what’s been going on and what you’ve been up to? KTHXBAI”.

Boom! You’ve just been assigned the task of producing a weekly status report! Now, from the perspective of the sender, no big deal, right? “I’m just trying to get some visibility on what’s going on and I thought a weekly email would be useful”, but let’s look at it from the side of the person on the receiving end.

First off, the request for a status report looks more like this:

and second, you’re already busy enough as is, and now you’re being asked to add another thing to the list of things you do and to you that thing doesn’t provide any value and it probably provides very questionable value to your boss. After all, you don’t even know if your boss is going to read it or that your boss will be able to get enough of the context around it to do anything useful with it.

And if we’ve learned anything from the Agile Manifesto, it’s that we value “Individuals and interactions over stupid status reports”, right? [click to tweet]

Ok, that quote may not be 100% accurate, but the spirit is there.

Dan Pink talks about three things that motivate knowledge workers, autonomy, mastery, and purpose. Status reports strongly undermine autonomy.

Status reports say “I don’t care enough to have a conversation with you, but I don’t trust you enough to not keep tabs on you.” [click to tweet]

And unless you trust your employees, they can’t truly have autonomy. 

The other message sent is ”My time is worth more than your time”. And if you truly believe that that is true, don’t expect to be building a highly motivated work force any time soon.

Today’s image by The U.S. Army.

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!

Comments

Yes, and… Test!

Share/Bookmark Subscribe

http://www.flickr.com/photos/techyizu/7483831602/in/photostream/Heading in to Lean Startup Machine, one tip i’d love to give the teams participating is to use a “Yes, and… Test!” mindset. In fact, I’d love to see all teams embody the “Yes, and… Test!” mindset. [click to tweet].

The Improvisor in me loves to tell people about “Yes, and”. “Yes, and” is one of the founding principles of Improvisation. It’s the idea that you accept whatever offer your scene partner gives you and build on top of it. For example,

A: Let’s go to the mall!

B: Yes, and while we’re there we can buy some new shoes!

If you continue in this manner back and forth, you’ll have a scene that always seems to be moving forward. To continue,

A: Yes, and I’m going to buy shoes with roller skates in them!

B: Yes, and we can roller skate around the mall, while drinking smoothies!

By working in agreement, we continue to advance the story. Now, what would happen if we were to negate the first offer?

A: Let’s go to the mall!

B: No, the mall is closed.

A: …

Hmm we don’t seem to have anywhere to go from here, do we? Our only option is to throw more offers at our partner.

A: Ok, well let’s go to a baseball game.

B: No, our baseball team moved.

A: Hockey game?

B: No, they’re locked out.

By this time person A probably just wants to get out of the scene as soon as possible, since this scene is clearly not going to go anywhere.

In life outside of Improv, we see scenes like this all the time.

A: We should start doing x, it would really improve the way we work.

B: No, that won’t work here.

Sound familiar? Person B has killed the idea before it ever got a chance. Or perhaps you’ve seen this scenario,

A: We should do x, it rocks!

B: No! We should do y, it rocks!

A: x sucks!

B: y sucks!

A: I hate you and all those that like y!

B: Only idiots like x!

Ok, perhaps that’s a little bit simplified, but you get the idea. Politics, arguments, and usually an appeal to authority play out until someone wins and someone loses and in the end you still might have made the wrong decision. Great.

So what do you do instead? Say “Yes, and” to these ideas!

But what if you truly believe the idea won’t work?

Well, you don’t know an idea won’t work unless you’ve tested it and have the data to prove it. You have an assumption, and that assumption should be tested.

Also, the key to “Yes, and” is not that you go along and do whatever the person says, but that you accept that they believe what they are saying is true. For example,

A: Now that I’ve tied you to this chair, I’m going to beat you until you tell me what I want to hear.

B: No! I’ll never talk! When I get out of here, I’m going to foil your scheme!

Even though person B said no, they still accepted the fact that they were tied to the chair and going to be beaten by person A, so they still accepted the offer to be true (Yes) and then added something themselves (and). The opposite would have been something like this,

A: Now that I’ve tied you to this chair, I’m going to beat you until you tell me what I want to hear.

B: What are you talking about? I’m not tied to a chair. Stop playing around Billy, we’re going to be late for school.

Of course, it would have also been fine for person B to just start spilling their guts to person A, but having a negative reaction didn’t stop the scene from moving forward because their actions were still saying yes to the suggestion made by their scene partner.

To keep moving forward, we must believe that what the other person is saying is what they truly believe based on the information they currently have. [click to tweet]

Once we’ve accepted what they said to be true, we need to look at what assumptions are there and how we can test them. Now we can expand “Yes, and” to “Yes, and… test!”.

Let’s go back to our other examples,

A: We should start doing x, it would really improve the way we work.

B: Yes, let’s run a test to try it out. Here are some potential barriers I see with it working, if it passes these tests, then I think we should do it.  

and our second scenario,

A: We should do x, it rocks!

B: Yes, let’s test it out. I’m concerned that it can’t do some of the things y does, if we can test it to see if it does those things or if we have good ways of working around those things, I think we should do it, otherwise maybe we should go with y.

A: Yes, there are some things I like about x, that y doesn’t handle. Let’s test y as well and see if it can handle the things I like about x. If it can, let’s do that. We might also want to see what other options are out there.

In both of these scenarios we can now move forward in a more objective manner (the tests should be clear about what we’re measuring and what constitutes a pass or fail) and in the end, instead of just selecting one and hoping for the best, we are now in a position to make an informed choice instead of an opinionated one. The added benefit in this scenario is there is no winner or loser between A and B. Both got behind each idea and set the criteria that would get them fully on board, so neither loses any political capital.

Taking this approach greatly improves collaboration and the quality of decisions made in teams. This mindset is absolutely essential for teams at Lean Startup Machine. You have one weekend to learn as much as possible about what your customers want. Once you’ve done some interviews, the members of your team are likely to have many different opinions about what step to take next.

Too many teams waste time debating over different ideas. Save yourself some time, create a set of tests for each and go test them. [click to tweet]

You’ll have less stress between team members, you’ll learn more, and you’ll get better results.

Don’t believe me? Test it!

Today’s photo by TechYizu.

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!

Comments

Agile Tools Won’t Solve Your Problem Part 2

Share/Bookmark Subscribe

http://www.flickr.com/photos/buzzfarmers/7318395990/sizes/z/in/photostream/In Part 1, we looked at what happens when you use Agile tools at the beginning of your Agile journey. Today we’re going to look at what can happen later on.

So let’s fast-forward a little bit from our last conversation. Let’s say you’ve been applying everything you’ve learned about Agile for the last while and are having great success with it. You’ve got whiteboards and stickies everywhere, people are collaborating more than they ever were before and information radiators are everywhere.

There’s just one small problem, your backlog is a mess!

Since you’ve been doing such a great job, people have been pushing for new features left and right and your backlog has been growing and growing.

Well, now we need a better way to categorize, prioritize, organize, track, search, comment, review, keep history, graph, vote up, like, +1, share, and attach cat pictures to all these features! Time to get an Agile tool!

Once again, I’m going to ask you to slowly step away from the tool…

You really do have a problem managing your backlog, but not the one you think!

The problem isn’t that you don’t have a sophisticated backlog management tool that can handle large amounts of backlog items. The problem is that you have too many items in your backlog!

I’ll say it another way,

You don’t need a better backlog management tool, you need a smaller backlog [click to tweet]

A tool won’t help you keep your backlog small, in fact, it’s more likely to do the exact opposite. Once it’s easy enough to store and search through all these backlog items forever and all eternity, the hoarding bug is going to kick in and it’s going to kick in hard.

Agile backlog tools encourage hoarding. Don’t be a hoarder. [click to tweet]

I know what you’re thinking, “but what if that feature is the next million dollar idea?!?”, “what if I forget all the details and discussions we had around it, shouldn’t we have a place to track all that?”.

The hoarding bug has already taken hold…

Large tracking systems encourage us to become hoarders. We’re afraid to let go of what might be the next brilliant feature. We’re afraid to hurt someones feelings by telling them that their pet feature just isn’t important enough to get implemented. Or worse, we’re afraid of saying no because the person requesting the feature holds a position of power in the organization!

Last time we talked about one of the values from the Agile Manifesto, today I’m going to refer you to one of the Scrum values: focus.

One of the reasons Agile teams perform as well as they do is because they are able to focus. Whether that focus is achieved through focusing on only the items in the current Sprint or by limiting work in process (WiP), focus is vital to the success of any Agile organization. That means even the backlog itself must be focused and free of distractions.

Don’t worry, if it’s a really great feature it won’t be forgotten, it will keep coming up until something is done about it. Otherwise, let it go.

You’ll end up wasting more time constantly revisiting these low priority items, getting up to speed again on them and making sure that they’re all still current than you would spend implementing them.

I’ve seen organizations with thousands of items in their backlog tool, some many years old. I’ve seen them have meetings upon meetings debating whether they can get rid of some of these items. And after all that wasted time, they usually decide to keep most of the items, even though they will never get around to implementing them!

Of course, you could just work lots of overtime to get all those features implemented, there are no problems with that…

And what happens to all those information radiators? Where’s transparency and visibility when it’s all locked in a tool on a website that people have to actively seek out in order to find the information they don’t even know they’re looking for? And will they even have access to the tool (“licenses cost money, you know? Maybe everybody doesn’t need to have write access, or even read access…”)? How frequently will individuals interact when you can instead direct them to go read the tool?

As I said before, there are a lot of great companies that make tools for Agile, and one day you may decide to use one, but before you decide that you absolutely must have that shiny Agile tool, make sure you look at addressing the root cause of your pain and not just the symptom.

Now if you’ll excuse me, I’ve got a solarium I need to clean out…

Today’s image by buzzfarmers.

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!

Comments

Agile Tools Won’t Solve Your Problem Part 1

Share/Bookmark Subscribe

http://www.flickr.com/photos/fixersphotos/3199566032/sizes/z/in/photostream/Many organizations put off an Agile transformation until they’ve evaluated and found the right Agile or Scrum tool that they believe will solve all their problems.

Others start with whiteboards and stickies and then as their backlogs start to grow, they begin to look into electronic Agile tools to solve their backlog management issues.

If either of those are the reasons you’re currently evaluating tools in the Agile space, I want you to stop it.

Right now.

Put down the tool and take a step back.

If you’re in the first situation, and you haven’t even started with Agile, then looking for an Agile tool will only waste your time.

Ask yourself, “Am I only evaluating tools because I’m afraid to get started?”

"What does this tool provide that is a prerequisite to getting started with Agile?"

Let me help you out, the answer is nothing.

There is nothing an Agile tool provides that prevents you from getting started without it. [click to tweet]

Instead of wasting your time evaluating tools, I’d suggest starting with the Agile Manifesto. You might notice that the first value listed in the document is,

"Individuals and interactions over processes and tools"

So we value tools, but we happen to value individuals and interactions more. Ok, so how can we get started with some individuals and interactions instead?

Well, there’s coaching and training (disclaimer: I provide coaching and training services), there are books, plenty of blogs (disclaimer: I have a blog, you may have read it), there are local Agile community group meetings, conferences, mailing lists, other Agile companies you can talk to, and more. The key thing to keep in mind when getting started with Agile is this:

Start learning, start doing, keep learning, keep doing. It’s what Agile is about. [click to tweet]

You don’t need an Agile tool to do any of that.

Here’s the situation I’ve seen with companies that started with a tool first.

You choose a tool before you really know much about Agile or how you’ll end up working. You start using the tool and as you learn more about Agile you discover  that it doesn’t really work the way you’d like it to. Except, now you’ve got data in it, you paid a hefty fee for it, and you just convinced everyone that it’s exactly the tool you needed. Now you’re stuck. Do you step up, admit your mistake and eat crow? Or keep using the tool even though it’s not working out all that great for you?

Guess which option most organizations choose?

There are a lot of great companies that make tools for Agile. You don’t need them to get started.

In part 2, we’ll see if you’re really going to need that tool later on.

Today’s image by fixersphotos.

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!

Comments