Results tagged “methodology”

As a project manager, architect, developer, and coach, I've worked on a lot of agile teams. As part of that experience, it's always fun to ask folks: "What does the word agile mean?"

While on vacation, I pinged a few friends of mine to ask them if they'd give me a LinkedIn recommendation. I'm hearing that people are using LinkedIn as a replacement for resumes, so it seemed like a good idea.

Imagine my surprise when one of my "friends" declined!

Bob -- let's call him that -- is a nice enough guy. Very enthusiastic about software methodology X. Bob was a rabble-rousing advocate of X at my last big client. Bob and I didn't see eye-to-eye -- this isn't my first rodeo and there are lots of solutions to complex problems -- but we got along okay. Sometimes Bob would stand up and espouse X at length, telling us all the world would be better if we all used it. At these times I usually mildly pointed out to Bob that changing the entire world might be a little ambitious for a 12-person team. Sometimes I had poorly performing teams that I was unable to help improve, but Bob never said anything about it. As far as I knew, Bob and I were friends who just had different opinions about software development. After all, we were on an agile team and experts in agile methodologies: if Bob had problems with me or my performance, it shouldn't be a mystery to either one of us.

That was until Bob got elected to chairman of the board of the X Alliance. I'm not sure if that did it for him, but something obviously got him into a snit. The reply I got was "...I'm inclined to decline your request, Daniel. If you care to visit more, call me..."

WTF?

So now I'm on my vacation wondering what the heck is wrong with Bob. But I guess that will have to wait. I honestly don't know what interests me more, why Bob doesn't want to recommend me or why I thought Bob would recommend me when he won't. I think the second question has a lot more potential than the first!

But it got me thinking of the folks I've met who don't like me very much. I've been doing this twenty years. There aren't a lot -- most people could care less about me one way or the other -- but some folks actively dislike me. For each of these folks I've thought long and hard about what our problem was together. Maybe you can get something out of my mistakes.

Ever do the retrospective dance? You know the one, where at the end of the sprint everybody plays all the retrospective games: start-stop-continue, timeline, word-pong, or sprint-painting -- and then nothing in your team actually changes? Maybe somebody takes notes, there's an "action list", you create new stories, or whatever, but the next sprint there you are with the same items all over again?

That's a fun game, right?

Teams do this all the time. They're really good at going through the motions of doing a retrospective -- after all, everybody knows retrospectives are the most important part of agile -- but they suck wind when it comes to actually improving themselves.

Makes you wonder: are these teams really agile?

There are all sorts of tests out there to tell if a team is "really" agile -- the Nokia Test comes to mind as a popular example. Based on my experience, I have one simple rule for whether you're an agile team or not: you have to be constantly improving through the use of an efficient feedback cycle.

If you are constantly improving, you can start with nothing and end up with a hyperperforming team. It might take a while, but it'll happen. If you are not constantly improving, no matter how many of the rituals and behaviors you do, you're never going to amount to anything.

Which gets us back to the retrospective dance.

I teach a lot of project and program managers in my business. And I've been there, done that -- I've ran a lot of projects and programs. One of the things that fascinates me most is the difference between theory and practice.

In theory, you have this value structure from the organization -- what's important to it, what the plans are for next year, what fires need to be put out. In theory you simply define and prioritize these things, create and allocate a strategy, and end up with a list, matrix, GANTT chart, or something similar that gives you the next things to do. In theory, by having a value tree and using SWOT and a bunch of other stuff, like QFT, you end up with the next chunk of work for the next time frame. In theory it's even better than that, because by comparing your structure with your results, you can create metrics that show when you're not doing what you want to do.

In practice I have yet to see this work from top-to-bottom in anything but the minds of the creators. This doesn't mean I consider these things valueless -- far from it. A lightweight, cyclical system of work prioritization, allocation, and measurement is absolutely necessary for large organizations to survive.

But in practice, things get messy quickly.

In practice, you have multiple competing priorities that block one another yet each must be done first. In practice, you don't have enough time to put out the last fire before the next one pops up. In practice, department X wants you to do things one way while department Y requires an exactly opposite way. In practice, you have no support and you're on your own. In practice, the business can't make the decisions required of it in a timely fashion. In practice, Congresspeople ring up any time they like and it's a fire drill until they are made happy. In practice, you have no idea what the market will like and you're lucky to have some idea of how the next week is going to play out.

Practice is much different than theory.

It used to be the answer was simple -- blame the practitioners! And still see this from people from all corners of the development world. I had a TDD proponent tell me last month that the reason developers weren't adopting TDD was that they were lazy. A friend that creates process models for organizations confided that things would be a lot better "if management would just crack down on those knuckleheads"

I'm not saying that everybody is perfect, and sometimes "cracking down" or "bucking up" or whatever is exactly what's called for. Sometimes, of course, it's not. But what I AM saying is that a good set of measurements to take is the perceived problems the teams are having with getting their jobs done. Perhaps by looking at the things that are preventing the teams from getting what they want, you can get what you want too.

It's good for me. It's good for you. It's not the dawning of the Age of Aquarius, and we all don't have to start singing Kumbaya and wearing tie-dyed shirts , but it's at least a few steps forward in having a productive conversation about what to fix.

Sounds great but very nebulous, Daniel. What's it actually look like?

Lately there has been a lot of ink spilled over how to measure technology teams. Small startup teams are reaching the point where they want some kind of metrics, and big-company teams are using so many metrics that they desperately need to cut back to something that makes more sense.

Managers would also like to know what to do once they read metrics. Is more training required? Tougher management? Longer hours? Shorter hours? More people? Less people? We're nerds. We're really good at creating lots of charts, tables, and reports. What we're not so good at is using them for something useful.

I've been living in all of these worlds for a long time, and here are my rules for metrics:

We've all heard of continuous integration -- where the code is checked in and builds constantly. There is no time in which you don't have a compiling, running system.

C.I. sounds strange to folks who have never used it, but once you try it you're hooked.

Today I heard something that sounds even stranger: Continuous Project Planning.

Estimating Projects give people the fits. On one hand, you have to know when things are going to get done and how much they are going to cost. On the other hand, estimating projects looks a lot like magic from the outside.

I've been successfully estimating and teaching people how to estimate projects for a long time, and if you've read part 1 in this series, you're ready for some tips and tricks of estimating.

I recently had a team that was under-performing by any standards. They were all nice people: smart, capable, positive attitudes, competent in their work. But they just weren't producing that much.

So management told them: produce or die. Basically either finish up your work in the next sprint or we'll just throw away the entire project and start over with a different team.

It was amazing. People started working harder, using and creating effective information radiators. The team's stand-ups became laser-focused on the work. Everybody was looking for obstacles and getting them out of the way before they could affect progress. The team innovated several new ways of getting things done faster. They had a six-fold increase in productivity.

So what drives innovation, anyway? What makes one team create the next Google and the next team struggle to create a simple report?

One of the first questions we get when implementing and training agility in organizations is about accounting. So much of what happens in an organization revolves around the numbers -- risk/reward, investment/return, burn-rate, etc. Many times developers and technology management gets wrapped up in all the goodness of change and then we forget to bring the accounting folks along.

In a lot of organizations, you can get away with glossing over some accounting principles because the project has a charter and a budget that is independent of the way the project is ran. However, it's totally natural for accountants to want to see inside the project as much as possible. And once you start running multiple projects in a program a lot of this hidden detail raises it's ugly head.

We wrote an agile project-tracking tool last year as part of an effort to provide some answers to these questions for a large corporation that was looking to have more control and insight. While it's not publicly available, we did learn several lessons that might be useful to others.

So if you're trying to figure out how accounting concepts apply, here are some terms and their meanings in accounting terms:

But I don't argue with him that much...

So a while back I was exposed to two agile teams that were building their own product owner robots. You know how it is, you need a product owner, of course, and sometimes there just isn't one around.

One of these teams I think is going to succeed, while another will struggle. I'll describe both teams and you can see if you make the same call. Then some commentary.

Who is looking at whom?

It never fails. As soon as I explain the 20-40 rule (teams can only really process and work 20-40 items at a time -- whether those items are user stories, business rules, domain classes, whatever) I get the same question.

"But what if my team has a lot to do? Surely every team can't work just with a list of 20-40 items. That's crazy. How about building the Space Shuttle? Or fixing all the bugs in Windows Vista? This 20-40 rule once-and-for-all shows that you're just talking academically and not practically."

So let's take it a step at a time. How can the team control the amount of stories/domain classes/supplemental items to an arbitrary limit of 40 or so?

First I'm going to explain how, then I'm going to change the way you think. (Hopefully)

Having seen scads of projects that are agile over the years, quite frankly I'm sick of talking about agile. Who's more agile than whom? Is there such a thing as agile maturity? If so, does it mean something useful? Can I be agile if I like using Microsoft Project?

How about this -- here are the seven factors I have found that make agile teams run faster. They may or may not make you more agile, but they'll definitely let you get your work done faster. So when you're done early, you can talk to the other teams about who is more agile than whom.

I'm an Agile Coach. And as a coach, I'm supposed to be, well, agile. And coach-like.

So I get a whistle and say things like "one more remark like that, Jones, and you'll be running laps this afternoon"

For some reason, this tactic is not effective coaching, at least for software developers. Most software developers would be lucky if they could run one lap, and while they did, they would be plotting to cripple the system with a virus when they got back.

Not exactly the desired behavior.

But the agile part is a little easier. Basically its common sense, but what with all the marketing and hero worship and all, people tend to get it all mixed up.

Take for instance the Agile Manifesto.

I had a chance yesterday to present principles around the MAT to some people from a large organization.

It was fun. I hadn't had the MAT material out in a long while, so I was almost as fresh to the topic as the team was. The neat part was preparing -- very easy to prepare for something in which you built a business plan, filed for a patent, and spent a year trying to market!

In fact, it's a bit of an anniversary. I started this blog 3 years ago with the partial intention of using it to help market the MAT. (If you don't know what the MAT is, it's a way for teams to self-assess what is going right and wrong and report that information up to the enterprise level so it can be fixed. It's real-world agile metrics.)

So it was a blast. My presentation (I thought) was quick, to the point, and not as boring as the old ones. I gave up trying to sell the MAT a wihle back -- it just seemed like I didn't move in the right circles to help it get moving. Plus my direct software sales skills just aren't what they need to be. So I'm just happy to have invented the thing and to be able to share the ideas with friends.

Interestingly enough, I think being away from a topic -- especially one you have invested so much time, money, and emotion in -- helps you be a better presenter than when you're swimming around in it. At least from my personal experience, I tend to get defensive when I think people are calling my baby ugly. I think that's one more reason to have more than one founder if possible.

If you're interested in seeing the new material, drop me an email and I'll send over the Powerpoint.

I spend a lot of time talking to teams about what to do to become more agile. I also see a lot of teams that never make it to their potential.

Instead of giving you a bunch of "do this" instructions, how about let's talk for a minute about the stuff you shouldn't be doing?

Here are the Seven Deadly Sins of Agile Teams.

So there are few things that make me crazy.

Okay -- maybe there are a lot of things that make me crazy.

Heck -- maybe I'm crazy already, but that's a blog for another day.

One of those things is people who have legitimate concerns in meetings but don't speak up.

I've been spending a lot of time lately thinking about whether a checklist makes sense for Agile or not.

As we all know, agile is not a very checklist-friendly methodology. In fact, it's probably a fair thing to say that Agile was created in response to overly-heavy, checklist-intensive methodologies.

So why in heck would you want a checklist for Agile teams?

I had a really great experience happen to me in an agile team the other day -- I was wrong.

I guess most people would think being wrong is a bad thing, but I look at the ability to be wrong to be a key indicator of a healthy team.

Do Agile teams need experts? If an expert says "We need to have a structured conversation that looks like this" -- is that continuing self-directed emergent behavior? Shouldn't we value having really smart people over having a really open and emergent process? After all, would an agile team of bus drivers be able to build a spaceship?

On the other hand, isn't the point of agile all about putting the process of team discovery and organization above the individual? Aren't we all tired of the days where cloistered groups of experts created perfect requirements, test, and other docs and then handed them off to one another? Less smart people can accomplish more in an agile environment because the team is always adapting the product to the needs of the business owner. Agile processes are always providing feedback, enabling organic growth. Agile teams beat smart teams with too much structure easily, right? Experts and rigid expert ways of doing things are most times too rigid for optimal success, right?

This is an argument that has a long pedigree. It touches philosophy and politics, and -- you know me -- let's take a look at part of the discussion.

Ludwig Wittgenstein
Couldn't there just once be a bikini model who was also a philosopher?
Seems like we always get guys like this.

Things are never what you think they are.

Take developing software. We call it that because -- duh! -- at the end of the day software is supposed to come out. When we work with teams, we always talk about our goals in terms of how the software is supposed to make the user's life easier.

But that's just a lie.