"10 Secret Unit Testing Tips" Webinar

Last week I had great time hosting a Typemock Webinar called “10 secret unit testing tips”. The fun thing was that I’ve discovered both in preparation and answering questions live that I have at least 20 tips in me for at least two more webinars. So prepare for “10 secret unit testing tips strike back” and “Revenge of the 10 secret unit testing tips” coming soon to a screen near you.

Probably will take less than 6 years, I don’t do all the special effects that George did.

In the meantime, here are the slides. You can view the video recording on the Webinars page.

The Real Value of a Non-Agile Plan

A couple of comments on my last post (the sad truth about agile planning) made me think: Maybe I was slamming agile planning too much.

Then I thought (after an elaborate discussion with myself) – I wasn’t doing that at all!

So let’s put some things in perspective: Can I make a plan for the next 3 years in the project? Absolutely.

Will it be real/correct/anywhere near that? Absolutely not. We can’t predict what will happen, no more than we can control if we’ll even be in the company in three years.

Then why bother? Two reasons.

Putting a plan in place requires thinking. I know, we don’t talk about much about thinking in agile too much, it’s not (air quote) part of the process . But much like TDD makes you think before you code, creating a plan makes you think about what you can and cannot control, what can happen, milestones, etc. It doesn’t mean what you planned will actually happen, but you know you’ve done some risk analysis just by thinking.

The 2nd reason is the cornerstone of any agile methodology: communication. You show this plan to the project sponsors, and convince them that you’ve actually thought about it. They know it’s not accurate, and that maybe the project will stop because of economic events that even don’t appear in the plan. But that gives them confidence. It raises trust.

In the past I didn’t understand that. I was sure the only way to gain (actually win back) trust was to show actual working software. It’s definitely a show of force when you’re delivering working software consistently. But you should do more . When you show a plan, you gain trust. When you communicate status on the plan you gain trust. And when you react to unforeseen events and communicate decisions, changing the plan on the way, you gain trust.

If you’ve already got this trust in place, you’ve got it made. And, you need to work at it to maintain it.

Projects succeeds when everyone communicates with each other, and trust each other. It’s up to us to build the trust on the business side. If we don’t? Let’s not be surprised that another unforseen event happened: the project got shot down.

The Sad Truth About Agile Planning

If you’ve read any basic agile stuff, you know that agile teams deliver value in a consistent frequency. The team works on what’s important first, giving the best value for money. When working in a consistent velocity, you can estimate very accurately when features are going to be delivered.

Prepare yourself for a shock.

It is true that when the team has gelled, had enough experience in estimation, and is moving in a constant velocity, life is good. But most people are not there. Chances are, that you’re struggling with inconsistent estimations, varying velocity, some turn over for good measure and enough unknowns to fill  multiple buffers in a Gantt chart.

There’s an old myth: There’s no planning in agile. You’ll find there’s a lot of planning, but if done “right” it’s mostly short term. There’s logic behind it: The bigger the task, a lot can change on the way. It makes much more sense to cut it down to smaller bites, estimate and deliver them, and move on to the next important feature.

However, most of the real world doesn’t work like that. In my former job, I managed software projects of medical instruments that needed to be ready for an expo, after FDA submission. The expo was on a deadline and the competition didn’t wait. The project sponsors needed to know everything would be ready in time, three years in advance.

You might be surprised to learn that answers like: “It will be ready when it’s ready” or “you’ll get what’s the best value every month” were not pleasing to the project sponsors’ ears. See, they needed to know what they’re getting and that it will be on time. Couldn’t face reality, the old geezers – they wanted actual long term plans.

Well, these are the guys who put the money into the project. They may have unreasonable demands, like wanting to know exactly where the project is, but the expo is not moving, is it?

Pure agile may work, but business people are so tired from earlier failures, they don’t trust the team anymore. And they are looking for reassurance or control, by demanding more information. And I’m sorry to say, they are right.

They need answers, so they can make better decisions.

So what can you do when presented with the unreasonable question: “When will it be done?”

You plan, even for the next 6 months, and stand behind your plan. This would be a rough plan, but will present you’re working on the correct features. When progressing, update the plan, and communicate your status. And apart from that, you present working software, showing continuous improvement in the product.

Sounds like the old waterfall world calling you back?

Well, that’s the real world. It requires balance between the long term and the short term. Agile planning is not enough.

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More