Category Archives: MAT

How to Really Measure Software Teams 3

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.

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

How to Really Measure Software Teams 2

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?

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

How to Really Measure Software Teams

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:

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Conference Fun

Daniel Markham and David Fox sitting at a restaurant smiling
It’s good to see people you haven’t seen in a while

One of the most interesting parts of conferences are the social aspects of them. I’ve always been an autodidact — I learn things on my own. So I read voraciously. Conferences never made much sense to me, mainly because I’d rather read exhaustively what thought leaders had to say rather than hearing them for an hour. Plus there’s a certain gateway process that happens with publishing: most editors are going to give authors a really good once over before publishing. The bar for speaking at conferences is not as high.

But what I didn’t expect was the awesome social nature of conferences. People go to meet each other and make friends and talk about similar problems they have. I don’t know that many people, but I must have seen a dozen people today that I knew. It was a great feeling seeing everybody! I have missed that by not going to conferences over the years — and it was unexpected.

David Fox and I went out for drinks and dinner this evening to a place called “Dick’s Last Resort” in Chicago. The waiters there abuse you and call you names. So it’s just like being at home except you pay for it.

We had a blast.

But there were a couple of sessions that didn’t work out so great for me today.

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

A Process Blast From the Past

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.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Speck on a Whale

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.

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

It’s not the Code, Stupid (Part 2)

Ludwig Wittgenstein
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.

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

It’s not the Code, Stupid

Programming is not about programming.

I came to this realization after reviewing my XP and Agile books as part of an engagement for a large client. I must confess that each time I start on my XP books I have a hard time because I start laughing when I compare the books to reality. I think I finally can explain why.

It’s not that I don’t buy into Agile and XP — heck, I was doing a lot of that stuff long before those books were ever published. It’s just basic performance-based project management. I guess I always felt that in the theory and applied theory department, some of the XP and agile software authors either didn’t know what they were doing or just making it up as they went along. I especially found funny their skewed view of “heavyweight” systems like RUP, CMM, CMMI, etc. The authors told horror stories about these other systems and then pointed out how much better their tactics were. After working with people who helped write the CMM and RUP, I found most of these guys don’t want onerous paperwork systems — these paperwork monstrosities are created by the practitioners, not the inventors. Then there was the whole cult of personality in the Agile/XP space that I found non-productive. To top it off, the XP books in particular felt more like political statements than serious tools for figuring out what software construction was all about. They were the kind of book to sell to frustrated programmers laboring under a huge paperwork beast and saying “We’ve got it all wrong!” Power to the people, man!

Understanding how Agile/XP ran off the rails will help you to understand why software development is not about developing software.

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Who me? Worry?


Coming soon is the big day where Y-Combinator chooses its Winter teams. Over on the news.yc board, there’s a lot of angst and tension.I applied too (for the first time), but I have absolutely no worries at all about my application. Why? Do I have some secret connection into YC? Am I Paul Graham’s illegitimate love-child? Have I hacked into the YC computers?

Nope.

Because I have context.

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Ares 1 Won’t Make it to the Moon

Ares I, also known as the Crew Launch Vehicle, the flagship of the new Vision for Space Exploration (VSE) is already maxing out weight requirements and is several metric tons short of taking anything useful to the moon. For the time being, NASA is “re-focusing” the Ares I mission at ISS support.

There goes the moon.

One commenter said, “I was also told Griffin has put the word out that for now it is retire the shuttle and support ISS and wait to see what the next administration wants to do about the moon.”

In-freaking-credible. This news has really gotten under my skin.

Continue reading

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.