Sprint is a bad metaphor...

Some people hear the scrum term "sprint" and get confused. They ask, how in the world do we run at full speed all the time and not get burned out? Well, you have to keep some history in mind. It's a term from Scrum, other agile flavors call it an iteration (thus it's not a blanket term). Also, when people do 30 day sprints, there's a tendency to hear that you should sprint for 28 days, do a review/planning/retrospective cycle for one day, and possibly have one day down time to work on "other" stuff (recognizing that it is hard to keep a heightened pace all the time).

The sprint metaphor is simply supposed to convey that your goal is so close and visible, that you are motivated to put extra energy into trying to reach it. It means that you don't come to work every day for 6 months and chip away at the goal. Instead, it conveys a heightened sense of awareness and focus allowing you to try and grasp at the goal right away.

It doesn't mean you are supposed to go as fast a possible... which is where the name fails. For most people, that is the definition of sprinting.

So, lets talk about the iteration a little bit. Imagine you are a distance runner working through a marathon. You can run the entire marathon without looking at your watch very often and just focus on getting there. If completion is your only goal, this might work for you.

But if you want to finish the race in a certain time, then you need to constantly check your pace. If you aren’t running a 5 min mile on the first mile, then you almost surely won’t have a 5 min mile avg over 20 miles. It’s very hard to make up lost ground.

Software works the same way.

Actually, many runners these days are buying heart rate monitors and other pace measurements so that they know by the second whether they are ahead or behind making their goal.

The real point of the sprint is to have a measurement cycle. If you don’t measure progress frequently, you can’t validate that your predictions are working out. By declaring you will take a measurement on a predefined cycle, you can't allow yourself to fall into a deep hole of trouble before realizing you need to dig yourself out of it.

That, in my opinion, is what the sprint concept is about.

How to explain Agile to a PMI certified person...

There are many situations where I find myself explaining what I do and what Agile or Scrum is. It's hard to do this with family members that don't understand software development, but it surprises me how it is sometimes just as hard to explain this to a PMBOK experienced PM in my same industry. After all, you can't respectfully explain it by saying why their way sucks and yours is better (elitism is not the answer).

Because agile is so much more than a process or methodology, but it redefines interactions, teams, and communication... it is hard to put into a perfect box and hand to someone.

So what do we do?

Mike Cottmeyer took a really good stab at this on the Agile Software Development blog. He takes the approach of pointing out what issues project managers face and then discusses how agile addresses them. Once you have their attention, then you can go into some of the deeper concepts behind agile.

Here is an excerpt from "How to Talk to Project Managers":

...ask them what happens after they communicate the project costs and delivery date of the project? I would bet money that their response will be somewhere along the lines of: we are given a date, we are given a budget, and then we start de-scoping the project.

...This is where you can explain that they are given the date and the budget because those were really the project constraints to begin with, not the requirements. We pretend the requirements are the constraint because, like most people, stakeholders hope that we will be able to get everything we want for what they are able to spend. Most of the time that is not the case.

...The reality is that by demanding ALL the scope, in the face of data that says otherwise, the business is making the implicit decision that their project will be late. You are generally not rewarded, or very popular with your stakeholders, if you bring this to their attention. Project managers are often incented to keep their heads down, do their best, and take their lumps when things are late.

Competitive parallel projects...

If I were to say that you should run the same project with two separate teams in parallel to insure against project failure, you would probably call me crazy. Pay twice for one thing? Yeah, right. Even when I remind you that 60% of software projects fail, you would still assume that doesn't justify the pay twice approach. (That's why we do agile, right? ... to avoid that failure!)

BUT, what if that failure normally happened in the first 20% of the timeline? Would that change your mind?

Peter Stevens wrote a great post about using competitive sprints to select a vendor. It's a pretty interesting read. It even suggests that just because a parallel team "loses" doesn't mean that parts of their work won't get incorporated into the winner. Check it out.

This is an agile focused topic, but I think you would very easily apply it to non-agile but iterative work of any type. I think I've even heard stories that Toyota or Mazda uses this process to create new car models. Different teams create concept cars and as they show with focus groups and auto shows, certain teams get disbanded and removed and the winner slowly emerges. Now that is a good way to bring a car to market that will have demand behind it.

Instead, we normally put all our eggs in one basket.

Don't work for jerks...

I tend to follow a few leaders outside the industry when I can. It keeps teaching me how to best bridge the technical community with the non-technical. One of those people is Seth Godin, a leading voice in the branding, marketing and communication field.

He recently put out a post about considering your choice of employment and how it affects you and your career. Here's an excerpt:

Work in a high stress place and you're likely to become a highly stressed person, and your interactions will display that. Work for a narcissist and you'll develop into someone who's good at shining a light on someone else, not into someone who can lead. Work for someone who plays the fads and you'll discover that instead of building a steadily improving brand, you're jumping from one thing to another, enduring layoffs in-between gold rushes. Work for a bully and be prepared to be bullied.

- Seth Godin

I got to thinking about this and reflected on my past jobs. I have to admit that whenever I work for a company where there is doom and gloom, I tend to get depressed. After surviving quite a few layoffs and bankrupt companies in the .com bust, I'm always keeping on top of the rumor-ville and pessimistic side of business so that I stay prepared. My experiences working with usability focused people after having a science degree make me very analytical, but yet creative. My time in the agile community has put extra power behind my feelings of integrity, respect, and the importance of team and transparency.

It is amazing to see how experiences wipe off on you and mold your personality.

If you are in the situation where you are considering future employment, you should be measuring the potential employer by this type of criteria. I dug up these notes from the Agile 2008 conference and think they are a good starting point for interviewing (full-time or contract) if you are looking for an agile-like environment:

1. Integrity is No. 1 and I look for this in the people I enter into business with. (Want to enjoy my work!)
2. I will not sacrifice/trade away building long-term relationships for short-term profits. (Want to build repeatable business!)
3. I will not sacrifice/trade away enjoyment in my work over generating dramatic profit growth. (Want to not burn out!)
4. I want to be intellectually and socially responsible to my customers, family, and community (Want to grow and learn!)
5. I look to enter into engagements with strong sponsorship and clear authority for me to execute. (Want to be able to do what I promise!)
6. I recognize individuals are the ultimate source of value and need environment where they can make a difference (I value people over process/tools)
7. I look to attract and mentor talent and partnerships that shares my objectives and values. (Want to work with good people!)
8. I look to engage customers through frequent interactions and process transparency – prefer customer collaborations vs. contract negotiations. (Want to earn and keep trust!)
9. I look to deliver simple eloquent working solutions over complex and unsustainable solutions (I want to deliver results!)
10. I look to enter engagements that leverage all my talents and grow my business reputation – innovate, solve the unsolved (SWAT), and deliver full-solutions where others won’t. (Want to build my niche!)
    

- Lynne Ralston

Think of the children...

Why should we think about finding something better than the old way of doing things?

So your little boy doesn't make a sign saying "My daddy doesn't have time for me anymore."

Enjoy your Friday!

Embrace Change != Schizophrenia

One of the most common misconceptions about Agile is that "embrace change" is a mantra that implies "do whatever you want". This is not true.

Instead of writing more about this, I'm just going to direct you to a great post I found this morning about the top five secrets to successfully implementing agile by braintrust software. Summarized, their points include:

• Ease Your Way Into It
• Be pragmatic in your approach
• Embrace Change
• Practice Servant Leadership
• Find the right customer for a pilot

It's a really good description (better than I can write) and I really like their 3rd and 4th points. So feel free to click through and check it out.

Nail, meet Hammer....

I've touched on the topic before:

• What do you do when you find bugs after the story is closed or the sprint is over?
• How do you split stories, and when is it cheating because you are simply using it to squeeze them inside sprint boundaries?

Well, Jeff Langr tackles a similar question. Complete Stories, not Iterations. Nail, hammer, bang. Repeat.

Figured it might make sense to hear it from someone else if you haven't gotten the message yet. If you have, then here's another source to use when explaining it to someone else.

What is Shu Ha Ri?

There are times when we try to communicate an idea to someone and we struggle to do so. My dad is a mechanic, so when he tries to explain the inner workings of a combustion engine to me, I'm lost. When I try to explain to him how software is built, he's lost. We have to recognize that as an expert on a certain domain, you can't talk to others as if they are too. This is where the concept of Shu Ha Ri comes into play. (For a more formal description of Shu Ha Ri, check out Martin Fowler's description.)

Shu Ha Ri is borrowed from martial arts. It defines 3 levels of learning-

Shu - Imitation. You do something by copying someone else. You don't question it. The teacher gives you a prescriptive solution to a problem that covers most of your needs. It may not be the most efficient or best solution, but it is simple to learn and covers most of the situations you encounter.

Ha - Understanding. You start to see the reason behind what the teacher taught you. You modify it to still fit the core philosophy, but streamline it for you. You also start to see that the solution doesn't solve every problem and therefore seek your teacher for new ideas and solutions, or you might even seek other teachers for solutions.

Ri - Mastery. You take everything you learn and apply it at will. You solve problems by blending solutions without even thinking. When someone asks what you just did is called, there is no name because you adapted a new solution on the fly. It just worked in that situation. Your own experiences outweigh your formal teachings.

(Literally translated: Shu-> Following | Ha-> Breaking Away | Ri-> Fluency -Cockburn 2007)

Important notes-

• a Shu level person can not teach. They are not prepared to guide a peer in the journey of making mistakes and adapting.
• a Ha level person benefits from multiple sources of teaching.
• a Ri level person thinks in a language that the Shu level person can't understand since it is not prescriptive.

Why is this important? When you are having trouble explaining a concept, it's worth taking a moment to understand the gap of knowledge and experience between the two of you. You might realize that you are speaking at a Ri level when the listener is seeking a Shu level answer. They don't want philosophy or meaning, they want an answer for their immediate solution. There is also the reverse of this... don't talk down to someone who already knows the concepts and needs help blending them together.

Finally, don't teach above your level. Masters learn from their students, but students posing as masters can be dangerous.

The problem with having a Ri understanding of any topic is that you don't realize it. You don't know why they aren't getting it because it is so obvious to you. Stop and remember how you got to this point and strive to help them down that journey also.

Don't mulch your backlog...

Jeff Patton tells a great story about his work with Gary at Mimi. It's a discussion about the typical approach to flattening product backlogs and how this is destructive to understanding the larger picture. Favorite section:

"We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details - the pieces of functionality we'd like to build. In my head a see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations."

"After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag - then cut down the tree."

"That's what a flat backlog is to me. A bag of context-free mulch."

I need that context in order for me to really tell a story about the system.

He goes on to discuss the problem further and also the approaches to solving the problem. Very good post. I'm adding it here for my own reference and in hope it helps you too.

How do I know if I'm Agile?

There are a lot of discussions around Agile and the minimal requirements. I agree that there are many in the industry slapping the agile name on their process because of the positive association. Of course, this only leads to the dilution of the term's value.

There are also many who are pushing back on this and taking too strict of a tone and painting a black and white line. To them, you are either in or out. Of course, these are the same people who will acknowledge it takes months for a team or organization to grow into agile... it's not an overnight transition.

Taking that into account, I typically look at it through one of these lenses:

• The organization is not agile, and does not care to be
• The organization is interested in agile, but does not know enough to pursue it yet
• The organization is going agile without knowing it due to internal coaches who dare not utter the word "agile" for fear of ruining the current momentum
  
• The organization is striving towards agile intentionally, but can not call itself agile yet because it has too many areas to still work on.
  
• The organization thinks it is agile, but this is limited to what it knows
• The organization is a leading example of agile, but now the burden is on them to keep pushing the envelope
• The organization states they are agile, but are lying.

Note how the last bullet accounts for the groups who jump right in without taking the journey down the path.

I've seen tests for agile before, like this nokia test for agility. But personally, if you are just trying to get a simple start to it, I prefer using Cockburn's Crystal test. My group has shifted points 1-6 to a positive position, and now needs to work heavily on #7 before saying we are almost agile.

The Platinum Rule...

If you know me personally, you know that there are a few specific agile leaders that have made a stronger impression on me than others. One of those is Alistair Cockburn. I believe he is slightly under-promoted in the community. People who know his work understand its value, but many people don't know about him or his Crystal concepts. He's a great presenter and he covers great ideas.

Just the other day I was going through my old agile notes to revive any dormant concepts I'd forgotten. One of those gems was Alistair's platinum or Adamantine Rule:

The Golden Rule is self-centric – it instructs us to impose our value system on other people and expect them to be happy that we are treating them well in our value system!

Instead, using ... the Adamantine Rule, the subtext instructs us to
learn the other person’s value system, and treat them well in their value system!

He expands on this slightly on his bliki.

Sprint Zero...

Many of us eventually learn about the sprint zero concept in Scrum. It arrives when a team is experienced in agile, but is starting something new and realizes that the end of the first sprint probably doesn't warrant a demonstrable / releasable product. There are a lot of ideas on this and it's not really that mind-bending of an idea, it's just one of those topics that you don't learn when sitting in the Agile 101 classroom.

I simply view sprint zero as an adjustment of who the customer really is. Instead of thinking of your end users, it might be managers in the company that haven't approved the project charter or budget yet.

If you are thinking about how to approach sprint zero when you need seed money or sponsorship of some form, then your first sprint should focus on how to spend the initial funding (or getting it).

If you are earlier in the process and working through a formal relationship with a customer that requires an RFP, this can be a different set of challenges. Peter Stevens talks through his personal experience on the topic of writing agile into an RFP.

Update: Peter Stevens continued on this RFP series and has links to all the pieces here.

The train game...

To follow up on a previous post about agile coaching games... today, Infoq posted an article about the session run by these guys at Agile 2008.

I'm happy to announce that a game I recently created and tried successfully in my own company was submitted and accepted by Don McGreal and Michael McCullough into the Tasty Cupcakes wiki.

If you would like to try the Train Game and have questions, feel free to contact me. I'd like to polish it up a bit and improve it based on other people's experiences since I have only run it once.

Update (10/27/2008) - another good post on agile coaching games.

How do testers fit into agile?

I'm a strong believer they must be part of the team.

If you have a testing organization within your company, then before agile was implemented you were probably used to pitching "completed" work over the wall and crossing your fingers. Then there was a period of quiet before the wave of bugs came flowing back over the wall.

Going agile is about decreasing the distance between these two points drastically. Actually, TDD (test driven development) is about removing that distance completely. With this philosophy, it is important for a team going through an agile transition to deal with this issue. Instead of the test team relationship being "us and them", you have to find a way to fold the test resources directly into your team. Resources should be slightly more dedicated and must participate in planning and sprint review. Even if they don't aid in prioritization, planning, and design, their presense in the room insures that testing is built into the DONE criteria for sprint work and the timelines are realistic. Their insight can catch issues early, especially those surrounding performance or mis-use of the system. They get a view of what is coming down the pipe so that they can get ahead of the curve and stop being behind the eight ball.

My best experiences with testers on a scrum team occurred when they attended the daily scrum. Also, if they sat with the team throughout the day, they could mentor the team on their unit and acceptance tests to insure the basic logic and validation was covered. They spent more of their time catching the "really hard to find" bugs. They could modify performance and load testing scripts before the work was complete so that system tests could be run almost immediately instead of always being a sprint behind.

The sooner you embrace non-developers into your agile team, the sooner you see these types of benefits. These same points would hold true for usability, user interface, or business analysts.

If you want to know more about testing in agile, I just read a great post by rfleming on whether testing is about uncovering defects or changes. It triggered me to write this because I like his points and they are insightful, but I believe the issue he discusses can be reduced if you strive towards the points I raise here.

Is the Product Owner part of the scrum team?

Michael James over at Danube picked up a discussion about whether the product owner should be considered part of the team. At first I thought he was saying no, but as I absorbed his points, I believe he was saying the PO is part of the team. Schwaber has come up with the term "scrum development team" to refer to the team without the PO. This point concerns me a bit... do we need other terms as well such as "scrum analyst team" and "scrum test team"? Why do we want to silo the team off?

The team is the team. It's everyone involved to deliver business value to the customer.

Not every member of the team is committed at the same level and the same way. How team members interact with their peers is important, and different people have different levels of authority when they speak. PO's have a stronger customer and market voice, usability and analyst roles have a stronger requirements and user voice, and developers have a stronger technical voice. But all voices impact each other so excluding any one from the group can be detrimental. Everyone on the team has to understand how to work as a team and not behave in ways that are harmful to the team. Just because a PO is a manager doesn't mean you should treat them that much differently when in the team circle.

What do you think?

Darth Vader was an agile coach too...

I swear I'll stop with the Star Wars references, but I'm not the one making these up and it is complete coincidence that they are back to back...

















Courtesy of Sebastian Bergmann on Flickr

Princess Leia was an agile coach...

Great article about managing, anxiety, stress, etc. Includes a Star Wars reference for the fanboys:

The problem is that the more we try to control, the more pressure we put on people, the less likely we are to get what we really want. Princess Leia said it best back in the 70's… "The more you tighten our grip Tarkin, the more star systems will slip through your fingers". The more we scream… the more we demand… the more we try to control… the less likely we are to get what we want.

Being anxious leads us to demand control. The more we try we try to control, the less likely we are to actually get the outcomes we desire.

It wasn't until after the fact I realized that Mike Cottmeyer wrote it. Met him at Agile 2008 and he's got some good ideas rolling around in that head of his.

It's Friday... I'm not going to add to this one, I'm just suggesting you go read it. It gave me some good food for thought, maybe it will for you also.

Don't create a terrorist...

Peter Stevens over at Scrum Breakfast had an interesting article about questions to ask your CEO about agile. The idea is in line with items I've pointed to previously around explaining agile, specifically Mike Cottmeyer's elevator speech used to grab a CEO's attention.

The item in his post that caught my attention though was around the topic of being "ambushed" which he described as:

... a peer (i.e. rival in the company) learned bad news about your project before you did and surprised you with it in meeting in front of all your peers. Very embarrassing. Operational staff often learns about an ambush through a very heated discussion with said top manager after the fact.

This reminded me greatly of something a prior (non-agile) mentor shared with me about being a good PM and dealing with a "terrorist".

A terrorist is someone who doesn't believe in the same side of a debate or cause as you. Typically it is cultural or political. They hide in the shadows. They wait to strike. (If we exclude the recent surge in suicide attacks, ) terrorism was originally an attack from someone that was in hiding to make a point (and hope to make it again and again until they win). Typically, a terrorist fought this way because they were in the minority in that situation and knew they might lose their cause if they fight out in the open.

You could easily imagine this general description of a terrorist as the group behind any number of bombs left outside any embassy... but you could also easily envision this terrorist as a co-worker that agrees with you in meetings with many peers but soon after seeks out a higher manager to undermine everything that has been said and done in that meeting.

Agile is a cultural change. On some level it requires a company to undergo political or organizational change. It's not uncommon to find people that can't fit within an agile culture. These people can quickly hide once they realize they are outnumbered by the peers around them that embrace agile with enthusiasm. You need to be aware of these people when you are driving agile coaching and transitions. One of my favorite quotes is from J.B. Rainsberger who says... "don't inflict change". Tying this to my other mentor, I believe that if you do inflict change, you are at risk for "creating a terrorist" in your organization. To Peter's point, this will lead to you being "ambushed".

My old mentor also said that once you create a terrorist, it takes a long time to overcome that problem. Sounds a lot like that Bin Laden problem, doesn't it.

Being a good diplomat and reaching out to build relationships with people that are least aligned with your intentions is a good way to create respect across areas of disagreement. I believe it is also imperative to dealing with the above issues. Whether you are driving agile changes, or any other changes... this is something I've found valuable to carry in the back of my mind.

Agile coaching help...

If you are looking for great coaching games within agile, check this wiki out.

I leveraged the balloon game and the coin game this week while running training in my company and it seemed to go well.

I saw a session with these guys at Agile 2008 and was impressed with what they are pulling together. Use and contribute!

Agile, where to start...

This is not the end-all-be-all silver bullet answer... but I answer this way because it is what others have shared, I have learned, and there is more support with these approaches.

If you are adopting Agile bottom-up from a tech team perspective... start with XP. If you are adopting agile top-down from a business perspective, start with Scrum.

And yes, at Agile 2008 in Toronto, during the keynote banquet Uncle Bob Martin basically declared that XP and Scrum need to unite and that they complement each other. I attribute this to the fact that XP focuses on engineering practices and Scrum focuses on PM approaches. Someone at ObjectMentor once told me that XP is the content and Scrum is the box it ships in.

Why is the previous in quotes? Because it was part of a discussion that I contributed to Peter Stevens description of what is agile after he attended an agile conference in London. I do agree with him that there might be too many flavors, many mis-applied labels, and that Lean is a great complement to the above.

Backlog Poker Prioritization...

Peter Stevens wrote a great post over at the Agile Software Development blog about how to tackle prioritizing your product backlog when starting a new project. He lists several approaches to this including:

Minimum Marketable Feature Set - the first pass to narrow the list of stories

Business Value First - Focus on High Value Functions

Bang For Buck - Go for easy wins

Technical Risk First - Do the hard things first

Defer Risk - Do the hard things later (or never)

Vote - Ask your users

He then provides an overview of each of these which I will let you read on your own there.

When he asked for other experiences, I mentioned the following:

We had a product where the backlog clearly could not be covered in the first release. Our customers were hospitals that didn't budge on "their needs".

We pulled our top 10 highest paying potential customers into one site and gave each one a bag of poker chips. They were asked to "pay" using their chips for certain features. They were told they could plop all their chips on one feature, or spread evenly across many.

As they saw each other "pay", they shifted their chips around. They didn't "waste" money where their peers didn't care, and they spread money to provide emphasis where peers needed help.

We walked away with a greatly pared down set of features that everyone was invested in (pun intended) and they felt like they were part of the process.

That's what we ended up building.

Waterfall is NOT dead...

SmoothProjectManager put up a short post about his disbelief on whether waterfall is dead or dying. You can hear his disgust between the lines about how strongly people are stating that waterfall is dead when, in fact, it is not.

I totally agree. Waterfall is not dead. BUT, those who have experienced successful Agile/Lean approaches have decided that they aren't turning back to waterfall because of their new level of job satisfaction.

Waterfall works well in projects where scope and deadline issues are minimal. The military uses PMI very well to build things like aircraft carriers. But, you also don't see them changing the length of the ship hull by 40 feet in the middle of the project like people change requirements on software projects. Change can't be tolerated in that type of project so the PMI/waterfall approach is very relevant.

A fundamental difference between the two is "fight change" vs. "embrace change".

Agile is growing much quicker than waterfall for many reasons including:
- when done properly... it works, and well
- it handles change much better than waterfall
- it reduces finger pointing which increases morale and job happiness

And unfortunately, it is a well-misunderstood buzzword that is being overused and misapplied (which shouldn't count as growth).

So, neither has won... and neither will conquer the other. As members of the agile community, we have to be careful about what we say to people in the non-agile world about our beliefs. If we come across as evangelists, we may turn people off from even listening to something that they might greatly benefit from.

Anyway, their are still people clinging to OS/2 warp machines somewhere out there... nothing ever dies in the tech community.

Agile Practices as a gateway drug...

The agile community needs to recognize that not everyone can jump in with both feet.

We seem to be going through an identity crisis where we are declaring what is agile and what isn't. This is very important because the agile label is getting slapped on many presentations when companies think it makes them look good when they are in fact, not agile. In doing so, they are also diluting the global understanding that agile is a cultural change as much as a process change. Not standing up for this means allowing agile to become the same thing as RUP, PMI, CMM, or any other silver bullet labels that have been mis-used to the point where they don't contain the strong value they did when they first arrived.

Having said this, we can't keep believing that everyone should either be full agile or no agile. I get the sense that many people post about what it means to be agile, and at the same time (reading between the lines) they are creating a "you aren't really one of us unless..." cultures.

Agile started as an inclusive community. We are all going down a path of growth and learning. We have to make sure that when we provide clarity on the true side of agile, we don't give the impression that there is no value in the separate pieces.

We WANT people to get ALL of it. But sometimes people have to get there in their own way. Is it okay for someone to add retrospectives and nothing else? Is it okay to implement sprints and nothing else? Yes, I believe it is. I believe that if people are reading about agile and like the ideals, but can't afford the whole cost (and immediately gain the whole value)... then they will continue to learn and read. Many of the agile practices are a gateway drug to wanting to achieve the whole thing.

Maybe that's an Agile 2009 presentation I'll consider giving: Using agile practices as a gateway drug to becoming agile.

Anyway... this thread was triggered by a blog post about incremental, iterative, and agile development by Mike Cottmeyer. He also makes some good points such as:

"... You can still get some mileage from delivering software in two or four week cycles, daily interactions between project members, and frequent project reviews. You can make use of loosely coupled requirements, prioritized backlogs, and rolling wave planning. There is value in understanding the definition of done and making sure that once you've delivered, you have really delivered. Managers can do product planning, release planning, and iteration planning without being particularly agile... "

Their military is agile...

I've always thought of the military as a command-and-control type of environment and therefore very un-agile. Funny thing is that 1187hunterwasser has a great personal experience where he connected military experiences with agile experiences. It was surprisingly interesting to find out that mission-type tactics and agile are similar.

I guess the glimmer of hope here is that it's not the organization type (military, research, etc) that defines the culture, it is the people.