Here’s an example. Say the full build currently takes three days to complete. An incremental build takes at least 6 hours. You might create these user stories:

• As a developer, I want to be able to build the full system from my machine in under 30  minutes so I can see what the effects of my changes are to the whole system. (Yes, I know, you might want it shorter, but to go from 3 days to 30 minutes sounds impossible to these folks.)
• As a developer, I want to be able to do an incremental build from my machine in under 5 minutes so I can see the effects of some of my changes without having to do a full build. This will allow me to make progress faster on small chunks of work.

One senior manager asked, “How many full builds do you do per day now?” “We can only do one every three days, so none.” “How much will this save?”

The real key to savings is how long does it take for a developer to find and fix a defect. In this organization, it takes 3-7 days for a developer to find and fix defects, before the code is tested by anyone else. That means there is no such thing as a one-day task. The minimum duration task is 3 days.

Well, when the senior manager heard that, he said, “How long will it take to fix the build system?” “We think it’s 4-5 weeks of these 3 people.” That’s 12-15 person weeks to fix a problem that prevents 65 developers from finishing anything quickly. As the manager said, “No brainer. Fix the build system first, and tell me how did it get this way after you fix it. We want to prevent it from getting there again.”

If you’re having trouble getting your technical debt work into an iteration, consider using user stories and explaining the cost of the user story for each type of user vs. the cost of continuing to work the way you are. You might be pleasantly surprised.

Tweet This Post

This book is a must read for everyone involved in IT world, from junior developer ’till C-level executive.
As usual, Johanna Rothman uses a very simple language and she provides a lot of exahustive examples so that everyone can understand the goals and the principles behind a project portfolio management.

Thank you, Giordano!

Tweet This Post

Good for them. (I mean it. I am not being sarcastic. I’ll let you know when I am.)

Matt, in my conversation with him, and Lisa in her post, both mention open IRC chats. Some teams I’ve worked with have open Skype windows all the time. Matt says that people are supposed to answer their emails in 5 minutes–that’s the expectation about responsiveness.

Maybe I’m just too old for this. Maybe I have a short attention span. Maybe I have ADHD. I can ignore a low-pitched buzz of activity around me, as in a team room. I can’t ignore icons bouncing on my dock. I interrupt whatever I’m doing to service those interruptions. I would not be successful with the tools and operating agreements that Matt and Lisa discuss. (I didn’t talk to Abby either. Sorry, ladies.)

On the other hand, I don’t think I’m that unusual. I suspect a significant portion of the people in the field can’t deal with visual interruptions, even though they can filter out sound interruptions.

Aside from technology allowing people to work together across the space-time contiuum, what would have to be true for the team? What would the team look like? Here’s what I’ve seen (more on that later), and what Matt described:

1. A high degree of trust among the team members. Matt doesn’t even participate in iteration planning or estimation meetings.
2. A high degree of flexibility in how to complete work.
3. Agreement on what done means, for each task, user story, iteration, release.
4. Commitment to each other about the work. (Yes, I know this is vague. I don’t know how to be more specific yet.)
5. I am sure there other characteristics of the team and I don’t know what they are.

The reason it’s important to think about what characteristics of a team could make true geographically dispersed agile possible, is because it’s so difficult to do well. I worked with two teams. Their velocity was noticeably lower when they were remote, and remarkably higher when they worked together. Same people, same project, different outcomes when they worked together and when they worked apart. Looking back, they did not have strong enough commitments to each other when they were apart. They easily turned their attention to another task, when another team member had a request. Their most common complaint was “I can’t finish anything when I’m not at work.”

Maybe their stories were too big (probably). Maybe their estimates were too far off. Maybe they didn’t know how to work as several people swarming around a feature when they were remote. But I can tell you that their velocity was significantly lower when they were apart than when they were together.

So, for those of you who are considering an agile remote team, especially where everyone is remote, please think long and hard about whether you have the experience, the individual, and team capability to do this. I believe my commenters, when they said they made it work for them. And, I have hard data from clients (no, I can’t share it, that would be a violation of my NDAs) that they can’t make it work.

Tweet This Post

First, let me explain what a team bit is. A team bit is a person or a group of people grouped by geography and functional specialty. I see this most often where testers are remote from the developers. The worst occurrence is when there is a single tester separated by many time zones and understanding from the product developers (developers, product owner, business analysts, anyone who can explain how the product is supposed to work.) A team bit is always remote from the rest of the team. A team bit has no one to talk to on-site. A team bit is out of time sync with the rest of the team. There is no way for this bit to build trust with the rest of the team.

In my experience, team bits don’t work. They don’t work well for agile, although the problem becomes transparent. Team bits don’t work well for any other lifecycle, but you might not be able to tell. George Dinwiddie is collecting data at StudiesofColocation.

So, where does that leave us for telecommuters? If the people only telecommute one or two days a week and the iteration is at least two weeks long, and if everyone telecommutes on the same day, overall velocity will likely slow down, unless the team is ultra-high performing. Of course, if it’s just one day a week, you might not be able to tell. If it’s just two days a week, you might live with a slight velocity reduction in exchange for happier people.

If that’s what you mean by telecommuting, agile and telecommuting can work. But you have to limit the the number of days per iteration. Otherwise, the reduction in velocity is palpable.

The next post in this series will be about remote feature-based teams.

Tweet This Post

He still looked confused. I asked him, “When does the spec freeze now?” He smiled, and pointed to his “Design freeze” gate on his process picture. “I bet you a coffee that you can ask any developer here and that they cannot point to one spec that didn’t change after that or any spec that was right at the end of the project.” He took the bet.

Over the next two days, he asked every developer he encountered. Some of them laughed at the question. “The specs are never right. They freeze, but they should change.” One project manager said, “I can’t remember a project where we actually froze a spec for more than a day or two.”

The manager was chagrined. “How will people know what they have to do?” I replied, “They talk to each other. Sometimes loudly. Sometimes they disagree violently. Sometimes they don’t understand what the product owner wants, and the product owner has to walk them through the request a bunch of times, refining what done means as they walk through the request. But they will do what the product owner wants. But you don’t ever have a spec that’s out of date. You may not have a spec. You should have a bunch of tests that tell you how the feature is supposed to work. Would you rather have working software or a spec?”

My colleague wants working software. He’s just quite suspicious about how he’s going to get it. He’s never seen design by verbal contract; he’s only seen design by written contract. He’s concerned.

The reason he’s considering agile is that he doesn’t get software that works the way he wants. He thought he had specs, and now he realizes he doesn’t have them either. We’ll see how my simulation convinces the technical staff of how they can build and test in small chunks, so that they do get working software.

Tweet This Post

Tweet This Post

Tweet This Post

When you have “idiopathic idiopathic sensorineural hearing loss” (we don’t know why, it’s from the nerve, and you can’t hear), you get an MRI. I did. I have an unusual MRI now–some hemorrhage in my right ear, and a meningioma. Meningiomas are benign brain tumors. They do need to be watched to make sure they don’t screw your brain up. As the doctor said, “You don’t have MS or brain cancer.” Well, that’s a relief. (An aside: now that relatively healthy people are getting MRIs, they find things. I suspect I will die from something quite different We don’t know about the hemorrhage, and my doctor is talking with other docs who know about these things.

I have to learn to adapt. I’ll be buying a new alarm clock, both for home and travel (anyone use one with a light to wake you up?) I have to learn to be around people where there is lots of noise all around. It’s difficult to know where the noise is coming from and to filter the noise correctly. I have to be extra alert around my right side, because I can’t hear anything there. It’s amazing how many people walk next to me talking, and have no idea I can’t hear them. Oh, and don’t get me started on people who cover their mouths when they talk. Argh! I start on physical therapy for the vertigo in a couple of weeks.

I could have done without this And, I am ecstatic to be alive with no deadly disease. I would prefer to have not lost my hearing (there’s now about a 20% chance I can regain it or part of it), but as things go, that’s a small problem. It’s taken me a while to find my equilibrium. I don’t quite have it physically yet, but I’m a lot better emotionally. I can work, fly, drive, do almost everything except dance (for now), and work out too hard. The vertigo comes back with a vengeance if I push myself at the gym.

When I facilitate the Reinventing Yourself Bof this year at AYE, I’ll be thinking about my work. Am I doing work that gives me joy? That helps other people? That leaves me in a state of grace?

None of us know how life will unfold. We can only keep working on our equilibrium and grace. I’ll be back to normal blogging and tweeting soon.

Tweet This Post

In many cases, agile is too far a stretch for these people, unless they are willing to invest heavily in training and coaching for each team and each manager, including some training for senior management. But that doesn’t mean they can’t be more effective.

I suggested a staged delivery lifecycle for several of these clients (and potential clients), as in What Lifecycle? Selecting the Right Model for Your Project. For others, I suggested the iterative-followed-by-incremental lifecycle also in that article. For some other clients, I suggested they use timeboxes for each phase, and try to use continuous integration–those two changes were so foreign that I thought starting there would help everyone realize they had other options.

Each project has many options from which to choose. Lifecycles are the way you arrange your project. The practices are what you do. Anyone can use timeboxes and continuous integration. They are practices that might fit for your project. But using those practices doesn’t mean you’re agile.

I understand that agile is the new buzzword these days. I prefer to be effective, rather than buzzy. If agile doesn’t fit for you, don’t try to force it. Instead, start with what makes you most effective, realizing that effectiveness arises from delivering chunks of business value frequently. If it makes sense to use staged delivery or design to schedule so you can fit the beginning of the project into the way your organization funds projects, then do so. You can timebox feature development and have something that looks a little like “waterscrum”, where you start with waterfall, but move into timeboxes where you deliver completed features in timeboxes. Maybe the best thing you could do is pair people so you don’t have so many specialists (originally published as generalists). Maybe the best thing you could do is prototype some features to test that the architecture actually works.

But I really don’t understand why people don’t find a way of working that makes sense for them, rather than climbing on a bandwagon. Isn’t being more effective what we really need to do?

Tweet This Post

First, understand why your manager can’t hear no.

1. Is it because the business pressures are so great that the cost of saying no seems insurmountable? Managers are people too, and if the cost seems overwhelming, it may be that your manager can’t see how to make small steps that ease the problem.
2. Is it because your manager only thinks you and he/she are working when emergencies exist? If your work is invisible, use the project portfolio to make it visible.
3. Is it because no one else says no? Other people may not know how. You might be the first.
4. Is it because he/she does not believe you? Oh boy.

Once you understand why a manager can’t hear no, you can choose how to act. For the first three reasons, your manager may not know about how to or is not willing to manage the project portfolio. In that case, you can manage your project portfolio.

Gather all your work into your project portfolio. Break your tasks into small chunks, so you can complete something in a morning or an afternoon. If you finish some task, can you get to a wait state on that project, waiting for others to get back to you?

If so, you can repeat, ranking and reranking as you proceed. It’s better to have a one-on-one with your manager and make sure you are working on the most important work. If your manager cannot help you rank, don’t worry. Show your manager that it’s possible to make a decision, make some progress, and then re-evaluate that decision based on more data.

If your manager doesn’t believe you, you may have a different problem. Is it a case of Queen of Denial, or is it something more basic, such as lack of trust? If it’s the schedule game, eventually your manager will encounter reality. If it’s lack of trust, that’s another whole problem and another blog post.

Most managers can’t hear no if they literally cannot imagine how to work themselves out from under the pile of work. Show them.

Tweet This Post