Results tagged “agile project management”

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've been busy working on my startup for the last month, and as an agile-big-corp guy, many of you are probably wondering: how am I doing in the micro-team startup field?

Very well, actually.

Here's a brain dump of things I've learned over the last month. As always, take what you can use and leave the rest:

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.

I'm a startup junkie. I use my free time to see if I can form teams to make something useful for folks. As part of that, I was talking to some guys this week about a new opportunity and one of them suggested that I write a mock-up UI to better demonstrate what we were talking about.

So I thought I'd just whip out C# and make something easy in WinForms.

Ugh.

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?"

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 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?

Agile is a marketing term that describes best practices for iterative, incremental development of technology. In general, it emphasizes people over process; short feeedback loops; regular, quick delivery of business value to the customer; and a tightly integrated co-located, collaborative team working at peak performance. If you've wondered about how successful startups work, or how companies like Google or top-notch performance consulting teams operate, the answer is Agile.

But Agile is also a kind of movement. There are conferences, books, a manifesto, seminars, training, videos and all sorts of other things to help you out. Sometimes this help gets kind of silly, like in the recent conference where haiku was proposed as a way of bonding the team together better. Like anything that focuses on person-to-person interaction, there's no shortage of opinions. So because Agile focuses on the critical factors of technology development, communication and collaboration between humans, it has roots close to sales, negotiation, religion, psychology, politics, sensitivity, feelings, expectations -- all of that messy people stuff.

So what happens is that there are a lot of people who are very serious about developing software as efficiently as possible chasing a lot of stories and anecdotes about just how to do that. What can I say? Sometimes it feels like geek sensitivity training.

So as a public service to the agile community, I would like to offer the reasons why Agile Project Management is like teenage sex.

Last year I wrote an online agile project management system for a large corporation. I don't think you understand what's involved with a problem until you write the code for it and work with the users.

So in the spirit of sharing, I'd like to provide you with my list of features an online scrum tool would need to have.