Results tagged “Agile”

In the Beginning was the Project
And then came the Assumptions
And the Assumptions were without form and void
And the customer conversation was completely without substance
and the darkness was upon the face of the workers
and they spoke among themselves, saying
"It is a crock of shit and it stinketh."
And the workers went unto their Supervisors and sayeth,
"It is a pail of dung and none may abide the odour thereof",
And the Supervisors went unto their Managers and sayeth unto them,
"It is a container of excrement and it is very strong,
Such that none may abide by it."
And the Managers went unto their Directors and sayeth,
"It is a vessel of fertilizer, and none may abide its strength."
And the Directors spoke amongst themselves, saying one to another,
"It contains that which aids plant growth, and it is very strong."
And the Directors went unto the Vice Presidents and sayeth unto them,
"It promotes growth and is very powerful."
And the Vice Presents went unto the President and sayeth unto him,
"This new project will actively promote the growth and efficiency
of this Organization, and in these areas in particular."
And the President looked upon The Project,
And saw that it was good, and The Project continued many generations, and many were overpowered at the size, ineptness and illogic of it
And this is why you are here

This is my first shot at collaborative blogging -- where you, the user, have just as much control over the blog as I do.

I'll ask the question and you guys respond, both by voting, giving options, and commenting. As things progress, you can send links to other people to join the conversation, add in text, images, video, video conferencing, IM, mindmaps, embed the results in your own blog, or whatever. Whatever you think is appropriate for the topic.

Then you can monitor the changes as other people add their thoughts effortlessly -- using the web.

We're using Google Wave, so if you don't have it and would like it visit the site or ask for an invite. It's all web-based (works best in Chrome) and it's probably the future of something-or-another. That's kind of what we're trying to figure out. Not sure, but I think you're going to need a high-speed connection for this.

One of the questions I commonly face as an agile smart-ass/wonk/nerd goes something like this: "We have a year's worth of work to do and 3 months to do it in. Agile is going to make it happen, right?"

Well yes, and no.

I'm building a new startup -- it allows people to collect and share quotes from books and web articles. As you add each quote, you tag it. When people vote up or down your quote (or comment on it), the system trains itself to learn which tags each user likes. I may like quotes from American History. You may never want to see any quotes about politics. Over time, the system learns this and acts accordingly. That way you can have a broad range of subjects with a large user base and the app still has the feel of a private forum.

A while back, Paul Graham wrote a language called Arc. After he wrote it, he challenged other languages to create a simple set of web pages in as few tokens as possible. In Paul's philosophy, the fewer tokens a language has (or needs) the more robust it is. Therefore the more likely it is to last a hundred years

I've been thinking about Paul's assertion for over a year now. I've programmed in lots of languages -- to me they're just tools. Old friends. I can't say I am crazy about one language or another, no matter how many tokens it has.

As I and others pointed out, you can make a computer language do almost anything in as few tokens as you like as long as you've set up a DSL (Domain-Specific Language) for the problem domain.

Since I'm building my product almost from scratch, I thought I would take you through a quick tour of how you end up with powerful "languages" that have maximum expressiveness and minimum tokens, no matter what tools you are using. For this discussion, we'll stick to a (mostly) .NET stack, with some major modifications, but the stack is really not important.

I was reading John Graham-Cumming today -- he makes the case that amateurs have a long tradition of helping scientists. He uses several examples, including his own discovery of a data error in some climate data -- an error that was promptly acknowledge and fixed by the scientists involved.

Others have made the case that as science gets more and more complex, the amateur really has little to offer professional scientists. There's simply too much complexity nowadays.

I don't buy that, and here's why:

People often ask me if I eat my own cooking. I thought this picture should prove that once and for all.

First, from the size of me you can obviously tell I've been eating somebody's cooking. Secondly, as you can see, pair programming is alive and well here. My partner and I work long hours making sure the code is exactly right.

I don't want to get into any kind of personality dispute, but my partner has a tendency to lose interest and fall on the floor quite a bit. He's obviously the brains of the operation -- the strong silent type. I figure after all these years of being both a high-level consultant and a code monkey, it was time to join forces with my logical ally, sock monkey.

And you can't beat the swank evening work area we have -- couch, TV, music, munchies, and pillows. Sock monkey doesn't talk a lot, but I can tell from the way he looks that he is really liking our coding crib.

A friend yesterday twittered and posted into FaceBook a status update about Kanban and programming teams:

"list of electronic tools for lean and kanban teams http://bit.ly/6WW8cS #kanban"

(Kanban is a way of doing work where you use a board to show a "flow" of work and limit the number of activities in any one stage to a certain number)

To which a friend of his replied:

"Yeah, the whole idea of managing the pipeline in a structured way makes a lot of sense. In fact, strange as it sounds, I can see how you could apply the principles to a larger enterprise waterfall of iterative project[s]. You could use it to focus the team on the immediate pipeline...

Yikes!

I was reading a technology forum the other day when somebody asked a question that kind of went like this: "I am a programmer. I've noticed lately that my attention span is getting shorter and shorter. Could you guys provide me with quick advice on how to make my attention span longer?"

I suppose something in the form of a XKCD comic or a couple of sentences might not be too much?

On one hand, I really feel for the guy, as evidenced by my own struggles with distractions. But on the other hand, something's out of whack.

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.

Over the last few years I've been collecting some really cool dashboards, gadgets, and gizmos that teams have self-developed as they apply agile. One of the neat things i get to do is to share them here.

People say agile projects don't have financials
In fact they have much better financials than traditional projects
[Picture is in higher resolution than shown. Download to see in greater detail]

Here we have a little bit of everything a controller would want to know: How much is this thing costing me? When do you think you're going to be done? How much do you think it will cost? Is the team getting more performance each cycle, or are they getting worse? Are they going to need to ask for more money? If so, how much? When are they going to need it?

And it's very simple -- one piece of paper.

Note that this financial dashboard is updated from live team data -- no extra team input is required. It's also updated every week or two, so it's constantly getting more and more accurate.

Can you say that about the system you're using currently?

If you work IT long enough, you go meta. That is, at some point you're not doing the thing, you're doing the thing about the thing.

Here's an example I shared with my audience today about what happens when you coach teams that coach.

Many times, the coaching team is brought in under a Statement of Work, or SOW. The whole purpose of a SOW is to describe exactly what the team will be doing. And most every time you will have a contact that will prioritize work and define "done". So you have a backlog, a budget, a Product Owner, and a highly-skilled team (after all, this is a coaching team -- these guys know what the heck they're doing!) What could go wrong?

I think people think that having a great team means having really smart people work on a clear list of things with somebody telling them when they're "done enough" is all they need -- but that's not true. For instance, lots of startups who are funded by VCs do a lot of activity and yet get nothing done. Activity does not equal progress! You can have structural problems with your list of things to do that can't be overcome by any degree of technology or smarts.

Activity does not equal value.

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.

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.

In theory, practice and theory are the same. In practice they aren't. -- Yogi Berra

There are two kinds of teams and developers in the world: those that are heavily into knowledge and those that are heavily into practice. Both lead to poor performance.

The first kind has read all of the books. Perhaps they've attended some seminars or conferences. They're excited about various ideas they've heard and want to try them out. Discussions about how practical something might be are regarded as counter-productive, or foot-dragging. These teams are knowledge-heavy. Outsiders really admire how smart these people are, but secretly are afraid of letting them around sharp objects, i.e., they don't really trust them.

The second kind isn't much into book-reading. They're just there to execute -- to deliver something. They're focused on the end-results and getting there as quickly as possible. Discussions around new ways of doing things are regarded as frivolous. These teams are practice-heavy. Outsiders are really excited over all the results these people get, but secretly are afraid that the mess and compromises that are being made that are going to cause a lot of problems later, i.e., they don't really trust them.

So -- how to balance knowledge and practice? I apply these principles in order:

When coaching for agile project management, I have led a lot of teams estimating and delivering technology. in addition, I've been asked by several clients to advise them on how to estimate a project. Plus as a hands-on guy, I've had to create estimates and live (or die) by them in real-world teams. Estimation seems like magic to some people. How can you know how big the project is before you even start?

As part of this work, I get asked the same questions over and over again. Here they are, with my answers:

I'm finishing up working for a large client next week, and I'm also playing around with the new SnagIt version screen capture widget, so I thought it would be neat to combine the two together and capture what my current work area looks like.

Note: you need Flash to be able to see this correctly.

Since this is my first shot at this, if you're having problems with the display please let me know. Hey -- works fine on my machine.

So what's your workspace look like?