Agile Mashup

How Big Is Your Bucket?

Mike Cottmeyer — Fri, 20 Aug 2010 15:49:00 +0000

A few posts back, I asked if an agile team should be expected to call their shots. In other words, should we expect that over time, an agile team should be able to accurately predict what they’ll be able to deliver at the end of the iteration? My assertion was that predictability at the iteration level is the only thing that separates an agile project from total chaos. Without the ability to make small commitments on a regular cadence, we have no ability to forecast what we can get done.

I’m working with one team right now that has gotten really good at calling their shots… but… people keep getting pulled in and out of the team. Having a stable velocity is predicated upon the team working together, staying together, and learning how to estimate and plan together. The constant churn at the team level is making it really tough to establish a consistent velocity iteration over iteration. While the team is great at calling their shots, they are still not able to really say what they can get done… and by when.

I’m a big believer that if we can’t get some idea of what we are going to deliver, and when we are going to deliver it… pretty quickly after spinning up a team… agile is almost a non-starter for most companies. Many of the companies I work with are not prepared to make an indefinite investment, with no idea of what they are going to get in return. Sure… agile teams fix time and cost, and vary scope to meet iteration objectives… but we have to have some ability to look ahead and manage the expectations of our customers. We have to have good data to help them make good decisions.

What I am really saying here, is that while calling your shots is essential, calling your shots isn’t really enough. You also have to get good at understanding the size of your bucket. What does that mean? It means that iteration over iteration, I need to establish some kind pattern for how much feature functionality I can deliver back to the business. Out of the gate, I don’t really care what the team delivers… or even how much they deliver… I want to know their delivery capacity over time. Not a hard fixed number, but a stable trend that I can base product decisions.

Over time, we will remove the teams blockers and help them deliver more effectively, but initially… they need to get good at calling their shots… and establishing the size of their bucket. So please… let me know what you think. Am I expecting too much from our agile teams? Should teams just be able to do what they can with no expectation of committed delivery? Even at the iteration level?

The Confusing Field of Coaching

Esther — Wed, 18 Aug 2010 14:04:52 +0000

I noticed at the recent agile conference that there were lots of people who billed themselves as agile coaches, and several sessions on coaching. Seemed like more of both than in past years.

I consider myself a coach, too, though not with a capital C. I usually coach managers or teams, and sometimes coaches. Mostly, I’m a consultant and coaching is part of the work I do in that role. But some people lay claim to “coach” as their job description. And some of those people have training from a coaching school.

All this, and a little story my friend Johanna told about an experience she had with a coach got me thinking about the different sorts of problems people bring to coaches, and the confusion that results when the coach is a “coaching process” type coach, and the problem is a skills-based problem (which requires content knowledge, in addition to process knowledge). Or a problem that calls not only for a coaching model, and a bunch of other models.

Back when she had a corporate job, my friend Johanna Rothman had the opportunity to work with a coach on a problem she was experiencing at work. It must have been an enlightened work place, because they employed Johanna AND coaches, whom they dispatched when a manager needed a bit of help. Johanna’s hope was the the coach could help her with the specific problem, which she hadn’t been able to figure out on her own.

Johanna explained the problem to the coach. The coach responded, “The answers are inside you.”

Johanna tried explaining the problem again. The coach answered, “The answers are inside you.”

The answers were not inside Johanna (at that time…I bet they are now). She needed specific information, direction and guidance to develop a new skill that would enable her to solve the problem. The response Johanna received to the problem she described was woo woo nonsense. It was no help at all. The coach was trying to be helpful, I’m sure. And she was acting out of a coaching model, just not one that fit the situation.

The Range of Coaching Practice

If we’re talking about a skill—whether it’s TDD, interpersonal feedback, or object oriented design, influencing change across the organization—the answer is not inside you. If you are shifting from a serial mental model of software development to a iterative/incremental mental model of software development, the answer is not inside you. Willingness to learn is inside you. The desire to maintain a good working relationships is inside you. The yearning for pride in work is inside you. The desire to see the organization improve is inside you.

The specific skill is not.

You need teaching, training, and direction, along with coaching and feedback. A coach in this situations needs to have task-specific (content) knowledge, in addition to coaching skills. And those coaching skills are likely different from the skills a life coach or goal coach brings to the table—unless they worked in the content field prior to studying a coach curriculum or taking up the coach label.

Life coaching—finding the answer in side you— is useful when you have a life problem; when you need a skill, you need skill coaching

Another friend, Don Gray, recently helped three people understand how an interaction blew up. As they unwound personalities and communication styles, two of them heard some information their default preference didn’t deal (well) with. He helped them recognize how their communication preference helped them, and hindered them. He helped them see additional options. To do this, he needed a coaching model(s), plus content knowledge on communication, human interaction, personality and cognition. Rare indeed. The answers may have been inside these people, but it took more than a coaching model to bring them out.

And of course, some times the answers are inside us.

Satir coaching assumes that each of us has the resources to be be happy and successful as a human—but may not be using all our resources to their full potential. Jerry Weinberg’s fab book, More Secrets of Consulting: The Consultants Tool Kit, is inspired by Satir’s self-esteem toolkit, and the book is tremendously helpful. I’ve studied the Satir model for many years, it informs much of the work I do with individuals and groups (and certainly how I live my life).

Likewise, the Solution-focused Coaching model assumes that the person being coached has some experience solving the problem for which they have sought coaching. This model assumes that the coachee has all the competencies needed to come to a solution. I had a little experience of this at the previous Retrospective Faciliator’s Gathering in Tisvilde, Denmark. Josef Scherer offered a session on Solution Focused Coaching, and since I a little stuck in my writing practice, I volunteered to be coached. It helped me a lot—the answer was inside me. But this sort of coaching wouldn’t have helped if my problem was that I didn’t know how to structure a coherent sentence.

There are other Coaching models: GROW, Achieve, and many more. More than you can shake a stick at (just google “coaching models”).

When someone is stuck, they may need a jiggle, in the form or a reframe, or a prompt to remember what they do know about solving the problem. When someone is struggling with an interpersonal issue or a life issue, they answer may lie within, and need a little help from inner resources to come out.

But sometimes, the person needs context, information, demonstration, a straight answer, or a skill.

Related: A Coaching Toolkit

© derby for Insights You Can Use, 2010. |
Permalink |
10 comments |
Add to
del.icio.us

Post tags: agile, coaches, Coaching, personal effectiveness, problem-solving

Feed enhanced by Better Feed from Ozh

In the Top 100

Esther — Tue, 17 Aug 2010 02:09:53 +0000

Jurgen Appelo, the wildly popular Dutch blogger, makes lists, among other things. His latest is the Top 100 Agile Books. He’s worked out a formula that takes into account reviews, average ratings, and continued interest. Not perfect, but I’m not going to complain, because I made the list–twice!

Behind Closed Doors: Secrets of Great Management (co-authored with Johanna Rothman)

Agile Retrospectives: Making Good Teams Great (co-authored with Diana Larsen), was also picked by Amazon.com’s editors as one of the Top 10 Tech Books the year it came out.

In case you are wondering, I’ve got two books in the works now. Team Traps (How to dig out if you are in one, and steer clear if you’re not) & an as-yet untitled book on shifting management out of command and control.

Feed enhanced by Better Feed from Ozh

My Agile Books Made a List of Top 100 Agile Books

Mike Cohn — Tue, 17 Aug 2010 01:20:50 +0000

My three books on agile made this list of “The Top 100 Agile Books” by Jurgen Appelo. He used an objective method of ranking books based on Amazon.com and GoodRead.com quality ratings and popularity. His blog explains the approach. Uncle Bob Martin and I were each fortunate enough to have two books in the top ten.

Just about all the books on the list are worth reading so pick up a few of them if you’re looking for something good to read.

On Winning the Gordon Pask Award at Agile2010

ehendrickson — Sun, 15 Aug 2010 22:36:10 +0000

On Friday August 13, I accepted the Agile Alliance’s Gordon Pask award at the Agile 2010 conference in Orlando.

I wasn’t even aware that I had been nominated, so when David Hussman called me at home shortly after 7:30AM on Tuesday August 10 to tell me that I had won, I was beyond surprised. Gobsmacked? Flummoxed? Yes, those words fit. Also grateful, honored, and delighted. I immediately made arrangements to go to Orlando to accept the award in person.

Even now I find it difficult to articulate what the award means to me. I am amazed to have been nominated. To have won? I am enormously pleased to have my work in the Agile community validated by such an honor. I think back to the prior winners and am ecstatic to be in their company. And I feel incredibly flattered to have been chosen alongside Liz Keogh who I respect and admire tremendously.

My inability to articulate my feelings led to near-paralysis in the days leading up to the official (short) ceremony. I had most of Tuesday and all of Wednesday and Thursday to organize my thoughts, but I made very little progress.

I thought about what to say during the long flight to Orlando on Thursday. When we landed in Orlando I had no more idea what I would say than when we left San Francisco.

Confessing my uncertainty about what to say to Matthew Barcomb during the banquet on Thursday night, I joked that I could use my time on stage to help him find his missing VGA adapter. “Thanks for the award!” I said, “Now, where is Matthew Barcomb. Yes, there you are. Stand up. OK, now who borrowed Matthew’s VGA adapter? Could you go over there and return it to him please?”

Matthew laughed. Brian Marick chimed in. “You could thank me,” he joked.

“OK,” I said. “What shall I thank you for?”

“For resigning from the Pask committee so that I’m no longer there to blackball women or testers.”

We laughed.

Then we drank some more. As a group we found our way to “Mexico” in Epcot Center where we hung with the Version One folks. Then we meandered over to “England” where Shane Hastie put some delicious but deadly concoction of a cocktail into my hands. We made our way to the Dance Hall on the boardwalk where we danced to pounding music and I lost track of my head.

Keenly aware that I had to be onstage between 9AM and 9:30, I switched to water at midnight and made my way back to my hotel at 1AM. Before going to sleep, I set two alarms, a primary for 7AM and a backup for 7:30AM. Then I fell asleep, blissfully unencumbered by any thoughts whatsoever.

Friday morning dawned.

The “strum” sound from my iPhone woke me with a start. It was my backup alarm. That meant it was 7:30AM. I shook away the cobwebs of a surreal dream involving Craftsman architecture and escaping cookie dough. Bleary-eyed, turned off the alarm. No time to hit Snooze.

I wondered why my primary alarm on my iPad, set for 7:00AM, hadn’t gone off. I looked over at the iPad. The display showed the alarm clock app prompting me to dismiss the alarm. Apparently it had gone off, but silently. Whoopsie. Good thing I always set two alarms. I turned off the alarm clock on the iPad and shuffled toward the coffee maker.

I took a mental inventory. I felt better than I had any right to given that I’d been in California less than 24 hours prior, had flown across country, and had been out partying until 1AM. I congratulated myself for not overindulging the night before, at least not too much, and for going to bed early enough to get 6 hours of sleep.

My mind turned to preparing for the day. 7:30AM. That left me an hour in which to make myself presentable, have some coffee, and reflect on what I would say on stage before I had to walk over to the Dolphin. I still needed to iron my shirt, but I would have plenty of time for that. And I could organize my acceptance speech in my head while I ironed.

Then my glance fell on the hotel room clock.

As a general rule, I don’t use hotel clocks. I find the alarms on my iPhone and iPad tend to be more reliable, and their time is usually more accurate.

But this time I wished that I had consulted the hotel room clock sooner.

It read 9:17AM.

If it really was 9:17… then I was due on stage RIGHT NOW. I could picture JB or Jim Newkirk calling my name, looking for me.

My mind raced. Which clock was right? I looked outside. Bright. Sunny. Of course. It’s Florida. Bright and sunny are normal. That didn’t mean much. I checked my own internal sense of time. Because I’d slept in 3 different time zones in the space of a week, my internal sense of time was completely broken.

My iPhone now read 7:33. I recalled my stop-over in Denver. I have had my iPhone get “stuck” on the wrong time zone before. And given that my iPad was another Apple product, it was possible that it could have the same issue.

Nagging doubts remained. If it was really that late why hadn’t someone called me? Surely someone would have called me. But maybe they couldn’t find me. I was staying at the Yacht Club because the Dolphin was full. And maybe they didn’t have my cell number. Another doubt surfaced. If the problem was that my iPhone and iPad were “stuck” on Denver time, why was it not an exact 2-hour difference? Why did my iPhone now say 7:34 and the hotel clock said 9:18?

But I had to admit to myself that it was entirely plausible that the hotel room clock was closer to correct than my own devices.

My stomach plummeted.

I quickly searched my address book for cell phone numbers of everyone I could think of. Phil Brock. Jessica Ambrose. JB Rainsberger. David Hussman. No luck. All my contact information was on my computer back in California. In an attempt to travel light I only had my iPad with me and it didn’t have all my contact info. So I had no way to contact anyone at the conference.

Full panic mode set in. I was seized with the notion that it was after 9AM. Despair and disbelief washed over me. I had flown all the way across the country just to accept the award. I felt so honored to have been selected. Then I stayed out too late and slept through my chance to say thank you. In doing so, I threw the honor back in the face of the committee. I’ve made mistakes before. I have disappointed people. But this would be among the worst of my screwups.

I threw on some clothes. Maybe, just maybe, if I got out the door fast enough and ran full tilt to the Dolphin, I could make it before 9:30. I would look like a disaster, but I would be there.

Grabbing my phone and room key I glanced at the mirror on my way out. It showed me an unforgiving image. I was a total mess. “What will people think?” I wondered. “How will they interpret my appearance?” Drunk, I decided. People would look at my hair and mismatched clothes and think I’m drunk from the night before. That’s the only reason someone would show up looking like this. My stomach sank lower.

I decided that showing up looking like a complete mess was preferable to not showing up at all. I raced out the door.

The nagging doubts resurfaced. The first thing to do, I decided, was to find out exactly what time it really is.

A hapless tourist wandered into my field of view. I raced up to him.

“WHAT TIME IS IT??!?” I demanded.

His gave me a look that plainly said he thought I was nuts. I privately agreed with his assessment. He checked his watch.

“About 7:48,” he reported.

The adrenaline that had fueled my scrambled exit from my hotel room abated. I shook with relief. My mind stopped racing. It would all be OK after all. I felt a sense of joyous reprieve. The sinking feeling reversed, roller-coasted into elation.

“THANK GOD! THANK YOU! I FEEL LIKE SCROOGE!” I shouted at the tourist with the watch. The bit about Scrooge made perfect sense in my head, but I suspect it served to confirm the tourist’s diagnosis of CRAZY.

I ran back into my room and spent the next 5 minutes just remembering how to breathe.

The remainder of my morning went as originally planned. In the next 40 minutes, I made myself presentable, had some coffee, and reflected on what to say on stage. And I laughed a little at my foolishness over the time confusion.

At 8:30AM (10:17AM HCT – Hotel Clock Time) I made my way from the Yacht Club to the Dolphin. I contemplated possible acceptance speeches as I walked, my heels thunking on the wood of the boardwalk.

I considered telling the story of my morning and the clock mixup, but decided it was too off-topic.

I considered doing an Oscars-style “Thank you to…” in which I would thank everyone I’d learned from in the Agile community, but decided that it was a massively long list, it would take too long, and no matter how careful I tried to be I would forget someone important.

I considered saying something about the past controversy around the award and the fact that two women had won this year when none had one before, but decided that was too divisive a message.

I considered gushing appreciations about the award and what it meant to me, but decided I’d probably end up babbling “Thank you I’m so honored!” over and over.

My mind was still churning even as the morning session began.

Mercifully, Liz was called up to the stage first. She spoke eloquently of community. I appreciated and agreed with her sentiments. But I knew that I could not get away with uttering, “Yeah. What Liz said!” I had to say something of my own.

Then it was my turn. As I walked up the steps I still did not really know what I would say.

But I had the germ of an idea. Brian had said I should thank him.

He had been joking. But he was right. I did need to thank him. Just not for the reason he suggested.

Brian is responsible for my starting down the path to learn about Agile, and he ushered me into the Agile community.

Brian started telling me about Extreme Programming sometime around 1999 or 2000. I ignored him for a couple years. Then at his urging, I went to see Kent Beck speak in 2001 and finally understood what Brian had been talking about. Set on the path to learning about Agile, I sought more sources of learning. I participated in one of Josh Kerievsky’s XP immersion classes. I finagled my way onto a Pivotal Labs project. I attended both XP Universe and the Agile Developer Conference (the forerunners to the Agile20XX conferences). Then Brian suggested that we do a session together at ADC2003 on Exploratory Testing in Agile. And so I started presenting at Agile conferences.

In short, if Brian had not introduced me to Agile concepts, principles, values, and the surrounding community, I wouldn’t be doing what I do today.

So, in my acceptance speech I said thank you to Brian. My words met with a few laughs, and I am still half expecting Brian to shoot me an email saying “WTF??!?”

But while I singled out Brian, I also want to thank members of the broader community. Fellow consultants and coaches. People I’ve worked with at my clients. Members of the AA-FTT community. Members of the BayXP and BayAPLN communities. Members of the local user groups that I’ve spoken to. The fine folks who work at Pivotal Labs, Atomic Object, CodeCentric, and Reaktor Innovations. Everyone who has come to Agilistry for events. Agile Alliance members.

All of you have been part of this journey. And I am immensely grateful to each and every one of you.

Communities take on a life of their own and deserve to be recognized and celebrated in their own right.

And I also wish to celebrate the individuals that make up the community.

So many, many thanks to all of you for being part of my Agile journey. I am honored. And grateful. And flattered. And extremely appreciative to be surrounded by a circle of such incredible individuals, part of an amazing community.

How to Import User Stories into PlanningPoker.com

Mike Cohn — Sun, 15 Aug 2010 03:01:29 +0000

I finally got around to something today that had been on my to do list for over a year: record a short video showing how to load user stories into www.PlanningPoker.com by copying them from Excel.

Here’s the video:

My thanks to my daughter, Savannah, who learned Camtasia for Mac while I was traveling last week and then helped me make this today.

How to Own a Really Big Complex Product #agile2010

Mike Cottmeyer — Thu, 12 Aug 2010 10:42:00 +0000

Hey folks… here is the deck I am doing this morning at Agile2010. I am pretty excited to do this talk… I finally feel like I’ve got the slide sequence and story right. It’s amazing what a good night sleep will do for you! My talk is in E-2 on the Ballroom level, hope to see you guys there!

How to own a really big complex product v3

View more presentations from Mike Cottmeyer.

One-on-Ones with Self-organizing Teams

Esther — Tue, 10 Aug 2010 10:18:40 +0000

I’m a big believer in 1:1 meetings on manager-led teams. It’s a way to connect with people, stay in touch with progress, learn about problems early, coach, work on career goals, offer feedback.

But if you are the manager for a self-organizing team, you need to adjust the way you do 1:1 meetings.

First, unless you are coaching someone on task accomplishment, do not ask about progress and status of tasks. On self-organizing teams, team members organize the work and make commitments to each other. If you as a manager insert yourself into this, you are communicating the the commitment is still to you, not to other team members. If you want to know about task progress, walk into the team room and look at the task wall or burn down chart.

You will probably have less visibility into the day-to-day workings of the team and team members. That means you are less likely to have useful feedback to offer on a regular basis. Ideally, much of the feedback on a team should be peer-to-peer. You need to get involved when the team has tried (using effective feedback techniques, not hints, not vague general statements), there hasn’t been a change, and the behavior is impeding the team. Getting in the middle of a feedback between team members when you don’t need to only creates problems and erodes trust on the team. When someone comes to you hoping you’ll carry a message for them, coach them on how to offer effective feedback, so the situation gets handled where it lives, between the team members.

Don’t meet every week, unless you are coaching on a specific issue (that you are qualified to coach on), or unless there’s a “get well plan” that you need to manage. You do need to stay connected to people; there are lots of informal ways to do this with out meeting every week. Meeting every week sends the message that you still want people to look to you for answers, help, and guidance. You may want that, but consider the effect on the team and their growth and capability.

You may still have a role in approving vacation (work on changing that, since it implies that the company doesn’t trust people very much). Keep that to a formal sign-off role. The first negotiation needs to be with in the team. I talked to a manager who approved a vacation request right after a team had committed to work for an iteration. (Who knows why the person didn’t mention it to the team, but he didn’t. That’s a separate problem.) The manager approved the vacation, then asked the team to cover the guy’s commitments while he was sunning himself on the beach. The team rightly refused, and insisted on renegotiated with the product manager to reflect the fact that they weren’t going to be able to accomplish as much with one team member gone for the entire iteration. The manager realized much later that he’d set the team back in mutual trust and accountability by not sending the guy back to work it out with the team.

Work on professional development, but remember that the team member you are mentoring needs to negotiate tasks and roles with the team. For example, if someone wants to learn more about project management, you don’t get to say “start managing the iteration as a project.” That breaks down the work the team has done to organize their work and erodes shared commitment.

Ask about impediments and blocks outside the team, those that need management action to fix. You can’t fix everything, but you can investigate, look for patterns of blocks mentioned by multiple team members. You can create an impediment backlog and post your burndown to the team.

Ask about HR concerns. For many agile teams, traditional job descriptions, career paths, and other personnel systems don’t fit agile work very well, so you want to know when there’s dissatisfaction and understand when and how policies are getting in the way of teamwork and team work.

Your job with a self-organizing team is to establish conditions for success, make sure the team has appropriate resources and appropriate boundaries, to remove impediments and improve the work system. It’s not to give task direction and hold individuals to account (except as noted above) . The team is responsible for organizing their work, tracking progress, and communicating to you when there’s a problem. You job is not to inflict help–that keeps the team from learning, and keeps them dependent on their manager.

Hierarchy acts as an amplifier, and manager’s actions are always under scrutiny. If you want the team to self-organize and reach their potential, don’t send them a confusing message that they still need to turn to you for day-to-day task guidance, status reporting, and problem-solving.

© derby for Insights You Can Use, 2010. |
Permalink |
10 comments |
Add to
del.icio.us

Post tags: agile, leadership, management, self-organizing, teams, trust, work system

Feed enhanced by Better Feed from Ozh

Rapid Feedback and the America’s Cup

Mike Cohn — Sun, 08 Aug 2010 01:45:46 +0000

It’s summer and I’ve been thinking about sailing. I didn’t get to do any this summer, but I can still think about it. Thinking about sailing reminded me of the 1995 America’s Cup race between the US and New Zealand. That race is a great illustration of the importance of both getting close to our customers and of rapid feedback.

To design their boat, Team New Zealand made use of software that would allow them to simulate the impact of various design changes on the speed of the boat. They evaluated thousands of design decisions. Each day the simulations were run on a small network that was located a few feet from the dock. To further evaluate designs, Team New Zealand made two boats and each day would alter one with a design change to be evaluated. The two boats then raced each other to assess the impact of the design change.

By contrast, the U.S. boat had been designed and tested using massive supercomputers. But they were located hundreds of miles from the dock. This created significant feedback delays. Feedback was also slowed because the team had only a single boat on which to test changes.

Getting close to their customer and using rapid feedback cycles led to Team New Zealand winning the America’s Cup for the first time. If you are not cycling ideas past your customers quickly enough to get rapid feedback, consider moving closer to the dock.

Interesting Post… 7/31/2010 through 8/7/2010

Mike Cottmeyer — Sun, 08 Aug 2010 01:23:00 +0000

Okay… we are going to do a Saturday evening edition of Interesting Post… Tomorrow I am going to get up early, do a little hike through the woods, bring home bagels for Kimi and the kids, toss the football with Noah, and then head to the airport for a week in sunny Orlando and the Agile 2010 conference. I’m totally geeked heading to Orlando as an independent agile coach. Did I say I’m geeked

There are so many people that I want to talk to and so many things I want to do and see while I am in town. I’m am looking forward to having one heck of a week. If you are going to be at the conference… give me a call, shoot me an email, or DM me and let’s find a few minutes to get together. I’m doing my talk on How To Own a Really Large Complex Product… so come see me there too!

Travel safe and I’ll see you in Orlando.

Interesting Post… Process: friend and foe http://dlvr.it/3WFjb

Interesting Post… Agile Conference – Speakers – Don Reinertsen http://dlvr.it/3VtlW

Interesting Post… What is Test-Driven Development? http://dlvr.it/3TsNz

Interesting Post… Kanban for Service Desks http://dlvr.it/3Tg81

Interesting Post… What’s next for the agile community? http://dlvr.it/3TZT9

Interesting Post… 30 Days of Getting Results the Agile Way http://dlvr.it/3S085

Interesting Post… Kanban Experience Complete – Thank You LSSC10 http://dlvr.it/3S084

Interesting Post… PMBOK and detailing leadership http://dlvr.it/3Ryvj

Interesting Post… Agile Rollout Warning Signs http://dlvr.it/3Ryvd

Interesting Post… One Size Does NOT Fit All! http://dlvr.it/3QcGN

Interesting Post… Creating an Agile Environment Fit for a Marketing Team http://dlvr.it/3QbCC

Interesting Post… I won’t be staying late with you http://dlvr.it/3QbCB

Interesting Post… Bob Payne and the Art of Agile Philanthropy http://dlvr.it/3QbC9

Interesting Post… Re-Think Transactions http://dlvr.it/3QbC8

Interesting Post… Yes You Kanban! http://dlvr.it/3QbC7

Interesting Post… What Should Done Mean? http://dlvr.it/3Pqf0

Interesting Post… Scrum Butt and the Nokia test http://dlvr.it/3PpVP

Interesting Post… Can Agile Work If Some Of My Development is Outsourced? http://dlvr.it/3PmsC

Interesting Post… Agile Software Requirements: We Have a Foreword and a Cover – Can a Book be Far Behind? http://dlvr.it/3PlnJ

Interesting Post… The Gordon Pask Award http://dlvr.it/3PlnG

Interesting Post… DZone RefCard Update http://dlvr.it/3PlnC

Interesting Post… The Difference between Lean and Agile http://dlvr.it/3M1XT

Interesting Post… Agile 2010 Talk: Agile Transitions- Cannonball and Stealth Approaches Exposed/Compared http://dlvr.it/3KWGb

Interesting Post… Minimum Concepts for Earned Value Management http://dlvr.it/3KTlL

From Leading Agile: On Leading Agile… Change… The Only Constant http://dlvr.it/3GLFX

Interesting Post… Top Excuses Why Automatic Builds Suddenly Fail http://dlvr.it/3GCc1

Interesting Post… Agile Communications http://dlvr.it/3FGZZ

Interesting Post… Project Management Definition – Part Three http://dlvr.it/3FCJs

Interesting Post… If your dev team jumped off an agile bridge, should your marketing team jump too? http://dlvr.it/3FCJt

Interesting Post… Keeping in Tune http://dlvr.it/3FCJv

Interesting Post… Good Agile software team looking for an agent to represent us! http://dlvr.it/3F6Zs

Interesting Post… If It’s Painful, Do It More Often http://dlvr.it/3F6Zj

Interesting Post… The painful reality of many meetings http://dlvr.it/3Dzpb

Interesting Post… Are We Agile Yet? http://dlvr.it/3DzpS

Interesting Post… Agile Coaches Gathering UK 2010 http://dlvr.it/3DzpR

Interesting Post… Getting unstuck: solving the perfect problem http://dlvr.it/3DzpN

Interesting Post… Ten Principles for Agile Testers http://dlvr.it/3DzpJ

Interesting Post… Design what you know http://dlvr.it/3Dzp9

Interesting Post… Fire everybody! How to start transitioning your marketing team. http://dlvr.it/3Dzp1

Interesting Post… Agile: It’s a Healthy Lifestyle Choice http://dlvr.it/3Dznw

Interesting Post… Every Team Must Be a Value Unit http://dlvr.it/3Dzns

Interesting Post… Do architects define the software development process? http://dlvr.it/3Dznm

Interesting Post… Traditional versus Agile — false war? http://dlvr.it/3Dzng

Interesting Post… A Pattern for Using Scrum and Kanban http://dlvr.it/3Dznf

Interesting Post… The Lean Product Backlog – Limit Variation and Prevent Overburden http://dlvr.it/3DznW