Results tagged “process”

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.

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.

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:

Right now I've got about 16 teams that I am coaching to some degree. Some I attend weekly meetings. Some I watch the team emails. Some I attend showcases. Some I am helping get started and setting up a backlog.

As part of my coaching job, I also do daily stand-ups with the other coaches and listen in on how another 50 or so teams are doing with adopting Agile.

I've been doing this for a year or two.

So what lessons have I learned over that time?

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.

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.

I'm an Agile Coach. That means I help teams adopt agile practices to make time-to-market shorter. I love agile with a little "a" But I have a confession to make: as much as I love the concepts in Agile and XP, the literature out there sucks. Here are the common faults that drive me nuts.

I am continually amazed at how a form of hero-worship exists in IT.

Just a few months ago, I was fortunate enough to apply for funding at Y-Combinator. It's like a boot camp for startups. It was formed in part by a guy named Paul Graham, who wrote a book called "Hackers and Painters"

I was turned on to the book by a employee for one of my clients. "You have to read this book. It's all about programming. Paul Graham is great!" I was told.